Letting the gameplay unfold

October 5th, 2014

I’ve learned that sometimes you let the gameplay unfold as part of the process. One simple design decision can eventually lead to a new gameplay idea that becomes an important feature of the game. I trusted that process when I was working on the multiplayer code a few months ago.

I had to sync the zealots between server and client with some new code since the requirements were different from my normal entities. I don’t like sending any data to clients that they can’t see in order to prevent cheating. However, I decided to break that rule initially in order to simplify the design. I didn’t want to waste time implementing a more complicated and time consuming design when the gameplay could change, negating the need for it.

As mentioned in my previous blog post, I was able to test the zealot code between server and client by making another change. I made all zealots visible to make sure they were sync’d correctly. I was able to do that since I send all zealot data (using an efficient design). I then decided to keep that change because it made the game feel more alive.

Recently, I began to streamline the user interface. It made sense to help players determine when those zealots were attacking their fortresses. After all, they could see them and the code has that information. That led to some additional code to track self, ally, and enemy banners for each fortress. So you could click on a fortress and see what banners are attempting to reach it. Furthermore, I total those stats for each player so you can get a representation of current threat level.

For example, you might see that 5 enemy fortresses are targeting your own fortresses. Then you could determine where the attack is heading and identify those zealots on screen. That gives you some time to manage your own fortresses, possibly reconfiguring your banners while adding towers and troops. But it would also be cool to convey that information in a more creative way than just displaying numbers. That’s what led me to a new gameplay concept that I have started to design.

I will add a game avatar that is part of the user interface. For instance, it could be a skull that changes in appearance depending on the current game state. It could talk to you - “the enemy marches to our gates!” I would have a lot of “flavor” voice overs for various game events, such as effective use of leader abilities, allies coming to your aid, etc. I can also change the music tempo according to what is happening in the game.

I think that will add a fun element while also being an effective way to convey situational awareness to players. It is inspired by games I used to play such as Fantasy Empires. It is also a good example of how a simple design decision for multiplayer code can lead to a new feature involving a game avatar. And I’m sure I will continue to evolve that feature as well.

Besides that stuff, I made a lot of other progress, which I will quickly summarize. The damage for leader abilities is more consistent, which allowed me to make them more potent. The computer AI is now more effective when attacking.  The leaders of computer players will flee more reliably before dying. They can defend fortresses too instead of just being offensive with their abilities. Gaining ownership of an unprotected portal is also more fair due to processing all banners before deciding the “winner”. Previously the first one to process could gain ownership with less banners.

The user interface was revamped so last selected owned fortress is always displayed. That makes it very easy to summon troops to a rally point while remaining focused on the current battle. Fortresses can be “tabbed” to select next. Leader abilities are always shown too. The selected entities will determine the center interface bar, such as moving troops. I will move some information to interface icons (like troop count) instead of text. Plus many more enhancements.

In addition, the first pixel art animation for troops is almost done. It is an armored shadow knight with a sweet looking axe. I will start adding screenshots soon to show the new pixel art and interface changes. I expect to start Internet multiplayer testing mid November. My Kickstarter should be around the end of the year. I’m really happy with how Pursuit of Power 2 is progressing :)

Two big milestones today

September 14th, 2014

One year ago from today, I married my beautiful wife, Katherina. It was an amazing day and this past year has been the best of my life. I look forward to celebrating many more anniversaries with her :)

I also finished my second ALPHA milestone today. This is probably the most important milestone for the game since I now have multiplayer fully working. It was a bit more challenging than I was expecting.

The zealots were tough to sync between server and client. I distribute the zealot updates evenly over the process cycles so I don’t stall the game during a spike. That adds another level of complexity for multiplayer since I lose some control over when I update the zealots remotely. That means I need to handle updates coming before and after the current processing on the client. The actual update process on the client runs independently so it runs smoothly.

That constraint made it really difficult to catch all of the edge cases. I wanted to automatically update the banner zealots according to the current game state, rather than sending that data. Every time I thought I had all of those cases covered, I would see a sync problem. I ran my server and a client next to each other to discover those issues. I made a lot of fixes during the past month. Now the multiplayer is running smoothly and with no known bugs.

I made a pretty big change based on the multiplayer testing. I was thinking about always showing all zealots even when you don’t see them with your troops. The leaders would sense them due to their innate connection to the power resource. I tried it out at first so I could verify the zealots were working for multiplayer. I really liked how it looked, so now it is a feature. The game feels much more alive with them always being visible. It also gives an opportunity to guess what is happening in the fog of war.

Next, I will make some improvements to the computer AI when it selects attack targets. There are times when the computer player will pick a target that is just behind another fortress. Then the zealots will never have a chance to reach the target fortress, so the troops get crushed without that support. You normally must send at least one line of zealots to defeat a fortress. More are required if the fortress has strong defenses or its own supporting zealot lines. Essentially, you need to at least have 1 more zealot line linking to the enemy fortress to neutralize the rebuilding and upgrading.

I’m going to also make some more changes to the upgrades so there is more depth. I will reveal those details later, as well as some new artwork. Thanks for reading! :)

Multiplayer code almost done for PoP2

July 27th, 2014

I haven’t written a post in a while because I have been really busy. Our son is almost 6 months old. He is great. I sneak-in about 2 hours every night of coding. So some of my multiplayer tasks for Pursuit of Power 2 have taken longer than planned.

The good news is that I am almost done with the multiplayer coding. I have just a few more items to sync-up between server and client. Then I start some LAN testing to work through the initial bugs. I want to fix the major issues before moving to testing over the Internet. I hope to have the multiplayer game working within about 2 weeks. That would put me on track to create my first official ALPHA release by the end of August.

That’s probably the most important milestone since the game will contain most of the major components. There will still be a lot of work to do, but the majority of remaining tasks will be pretty well-defined. I expect to start the Internet multiplayer testing a few weeks after the initial ALPHA release. That will give me time to work through some bugs and get a few more tasks completed.

I want to improve the computer AI when selecting nearest attack targets. I want to normalize the AoE damage for leader abilities so they are more consistent. Those AoE effects could use another pass. Plus the interface needs some tweaks.

I will post an update when the multiplayer is working. I’m hoping the rest of that work goes smoothly. Thanks for reading! :)

Switching to Multiplayer

June 1st, 2014

I just finished my remaining tasks that I wanted to complete before switching to multiplayer code. The game is in a very good state so it is time to finish the rest of my multiplayer code. I did a bunch of preliminary work a few years ago before creating my prototype. That’s because most of the code is a combination of Pursuit of Power 1 and my RPG “Birth of Shadows.” The main differences involve the fortresses and zealots, with a few challenging components. I will explain the details in a future post. Now onto the things I just finished…

I finally combined all of my resource code with spawn points. I can optionally set any resource to be a spawn point. The number of spawn points determines the maximum number of simultaneous players for that board (up to 10 max). Those available spawn points are randomized for players at the start of a new game. The editor has a bunch of ways to interact with the resources and spawn points. I added a list that shows all resources on the map along with their spawn point status.

Leaders now regenerate health when not attacking. This is important since I want to encourage players to use their leaders for attacks on enemy fortresses. Leaders can teleport to safety when low on health. I added code to the computer AI to flee (teleport) before dying if enough power exists. This was necessary since I also added code to teleport to the first attacking banner zealot that reaches the enemy fortress. This should mean that the attack is successful and therefore a good time to exploit the advantage.

In order for the leader to be effective, I had to add code that is able to find good targets for AoE abilities. I came up with a pretty flexible design that can find the best AoE location for each goal. For example, a goal could be to find the area with the most enemies for damage abilities. I can then determine the best goal, although right now I use a fixed priority of damage, debuff, and cure. I will add more intelligence and additional goals to this scheme in the future. The leader is definitely very capable now during attacks.

While playing with the leader abilities, I determined that I should make the target areas more obvious. Therefore, I added a box around the target area to clearly show which units are hit by the ability. I increase the duration of the visual effect too. The target box fades over 2 seconds. I use this same box for human players when an ability is selected. I make it semi-transparent and only show the target box for valid locations. This really helps with targeting. Once selected, the original target box is replaced by the AoE box, so it goes from faded to fully opaque, before fading out. It looks pretty good.

I created a new target graphic using beveled corners and made it white. This way I can use the vertex color to make it whatever I want. So local players are gold, enemies red, and allies blue like I do for tier icons, units, and other effects. It looks much better in my opinion. I decided to always show a semi-transparent selection box under all troops to make it easier to determine friend from foe. I switch the local player to orange when selected, just like it has always been. With all of those changes, it is much easier to tell what is happening during a battle.

Other than that, I just made some various tweaks. Computer players now use the number of portals they own to determine how many banner zealots to send to their current attack target. That helps press their advantage during a game. I also added a display bar to banner zealots to show the refresh for guardian abilities. I will add some more status icons to them in the future once I decide how I am going to implement those abilities (e.g. possibly upgrades). Plus other random stuff.

Once again, next up is the remaining multiplayer coding so I can play some network games with friends. That’s when I really start getting a feel for the game. I will play test a new 2-player skirmish board that I made today. I want to see how good the computer player is after my recent changes. In addition, I will be adding new artwork within the next few weeks. Lot’s more to discuss… please visit again to see my progress :)

Zealots go BOOM and other stuff

May 12th, 2014

Players have the option to summon a guardian for each portal that reaches tier 3. Once summoned, the timer refresh switches to banner effect. When the timer reaches zero, the banner zealot gains a combat effect. Each leader has a different ability, which is taken from a combination of troop abilities. For example, Shadow Knights have a fear and plague combo effect for their banner zealots. Eventually, I might allow players to pick and choose the active effects as upgrades.

When the banner zealots are killed, they trigger an area effect. It is pretty powerful, so enemies can take significant damage and also become incapacitated. This means players need to be aware of enemy zealots that are near them. This is especially true when an enemy leader is around, since that leader can sacrifice its own zealot to trigger the effect when active. I think that adds a fun element to the game.

I also added some additional power states to portals. Magic sources transition to portals with full power when first summoned. When a portal is partially destroyed and then captured, it transitions to a portal with half power. Another capture moves to no power generated. Finally, the next capture destroys the portal. The power generation is basically halved each time, while all other functionality is the same. So banner zealots are still very useful even for portals that don’t generate any power.

Furthermore, each source portal generates power independently of its banner connection. The amount of power yielded by the connection is determined by the destination portal. For example, a portal with no power could send zealots to a destination portal with full power. Without the connection, the source portal would not generate any power. With the connection, the source portal would generate power of that destination portal. If both were full power portals, then that source portal plus the connection would essentially produce double the normal power for that pair.

Power is only generated for the banner connection if the destination is a friendly portal. That way players can’t exploit an enemy portal by keeping it around just to take the power at a higher amount. In addition, the rate of power per pulse event is capped at a max value. The maximum amount of power that can be accumulated at a given time is also capped. Those caps are based on the total portals owned by a player as well as an overall maximum amount.

The idea is to keep the game action flowing while preventing it from becoming overwhelming with too much power generation. I will continue to tweak those types of mechanics to ensure that the game feels fun. I will try to always make sure that decisions are made with the goal of making the game as much fun as possible.

I will probably spend the next 2 weeks finishing various tasks I have had on my list for a while. I will add an editor option to select which magic sources can be spawn points. That way I can control how close players spawn next to each other. I will make a new board that has a better layout. I will add some additional AI code to make computer players more challenging when attacking fortresses. Plus, I will continue to add new artwork to the game.

After those items are completed, I will focus on getting the multiplayer fully working. That is the last major hurdle to accomplish. When I have that code in place, I will create my first official Alpha release. Then I can start multiplayer testing and make gameplay changes based on those experiences. That’s when things really start to accelerate. I can’t wait to play my first multiplayer game of Pursuit of Power 2! Thanks for taking the time to learn about my game :)

Completed first pass of troop and leader abilities

April 28th, 2014

It took almost 2 weeks to complete the remaining troop and leader abilities. I think I have a good base to build upon. The general idea is that the troops form the foundation of a battle. Then it’s up to the player to find opportunities to effectively use the leader abilities. They are very powerful when used in combination with various battle states. The skill factor focuses on identifying those opportunities, which involve certain troop types, rage levels, debuffs, etc.

Each player has an ability that is used to help control the battle. Shadow Knights can put a debuff on enemies that reflects half that damage back to them. Shadow Stalkers can root enemies and debuff their damage. Shadow Mages can pacify enemies so they no longer gain rage unless immobilized. These 3 abilities are useful when enemies have accumulated a significant amount of rage. Otherwise, those enemies will deal a great amount of damage due to their high rage levels. Only one of those ability states can exist at a time. The active debuff will have a visual effect associated with it.

Currently, player abilities have a 25 second cooldown for each ability. The global cooldown is 5 seconds, which means one ability can be used every 5 seconds if enough power exists. The previously mentioned debuffs last for 20 seconds, so there is a gap between uses. Most of the individual troop abilities last about 8 seconds. I’m sure I will tweak those values before the final release. But, they are a good starting point.

Each leader class has a unique way to generate rage for its troops. For instance, the Lizardman Executioner of the Shadow Stalker class has a rage debuff that it places on enemies. Any damage done to that debuffed troop will generate rage for the attacker. It is a really powerful ability that can quickly build rage for troops in the area. Shadow Mages have a player ability called Meteor Shower that damages troops with a bonus when debuffed by Wave of Vengeance. In addition, if it hits friendly Swirling Vortex troops, it generates AoE rage for each one. Shadow Knights can cast Blessing of Hate on friendly units, and generate 1 level of rage for each debuff cured. These are just a few examples of how each leader class can generate rage, besides simply taking damage from enemies.

Another aspect of combat involves the immobilization states of fear, stun, and mez. They all function the same way as far as the immobilization effect is concerned. However, there are unique procs for each effect when broken by an enemy. Fear will give the attacker a buff called Vampric Embrace, which is a lifetap bonus for each hit on an enemy with decay debuff. Stun will generate rage for the attacker when broken. Likewise, Mez will proc a heal for the attacker, which means a group of mezzed enemies will essentially give an AoE heal to the attacker if hit by AoE damage.

I changed the buffs to make them unique too. The siege unit for Shadow Knights casts Wrath, which is a buff that gives bonus damage versus structures. The siege unit for Shadow Stalkers casts a Damage Shield that causes damage for each hit by an enemy, which adds up over time. The tank unit of Shadow Mages use Harm Shield to mitigate 25% of damage to troops protected by it. There are other buffs too. I tried to make sure all of the combat abilities are varied while remaining balanced. I will have a better idea if I accomplished that goal in a few months when I start multiplayer testing.

In the meantime, I will be switching to zealot abilities next. I am planning to have 3 buffs that each banner zealot can have active at once. They will be unique for each leader class. For example, one buff could be massive damage to a structure that kills the banner zealot. Another could be an AoE heal that is cast when killed. Furthermore, each leader class will share 1 ability that sacrifices a zealot. This allows players to essentially kill their own zealot to unleash the buffs at a chosen location. This could be useful when zealot lines are running through a battle. Each zealot buff will have a recast that is tied to the fortress timer. Players will probably need to summon a Guardian after the portal reaches tier 3, before gaining access to those zealot buffs.

When I get close to the Alpha release in June, I will begin adding new information to the web site. I have been slacking big time with updating the info, which has not been changed in over a year. I hope to revamp my site so I can display the gameplay information in a way that is easy to navigate. I want to list every troop and ability to clarify the gameplay concepts. My priority is to get the Alpha release done. I can’t wait to update my prototype video too. Pursuit of Power 2 has come a long way over these past 21 months :)

Debuff icons and troop focus cost

April 14th, 2014

In a previous update, I mentioned that troops can be affected by combat debuffs. I also stated the importance of identifying those debuffs since they are used for powerful combos. I now display the active debuffs for each troop as a row of icons under the rage tier icons. I use a consistent position within the row to help identify the type of debuff. It works pretty well and I will continue to tweak the icons.

In addition, I changed the way troops are counted towards the max amount. The troops have been placed in tiers that determine their relative combat effectiveness. Higher tier troops cost more power and cost more troop focus, which is a new concept I added to the game. Instead of just using the max troop counter, I now use max troop focus. The same 100 max value is used, which would equate to the 100 max troops in game, if they are all tier 1 troops. Each tier costs that amount of troop focus (1, 2, or 3 troop focus).

This separation should encourage different army combinations and allow for more powerful units. Without the troop focus, I would not be able to balance the units if some were stronger. I have also always liked having some really strong units that can take on a group of weaker ones. It makes the combat more fun too.

I had to modify the computer AI to work with the troop focus cost. The attack triggers assumed max troop count. I added some code to use the current troop focus instead when calculating the triggers so they work properly. Otherwise, the armies just build up and never attack anything. The fights look pretty balanced.

Right now the fortresses are probably too strong, but that is good. I haven’t added additional zealot connections yet, which will help tip the balance. Plus, the leaders are purely defensive now, just building towers around the fortresses. When I start to teleport them to the attack targets, I will be able to use the combat abilities to break the defenses. That will be fun to code and even more fun to see in action :)

Currently, I am working on the next pass for troop abilities. I left some of them essentially blank, until I had time to implement them. I am going to spend extra time working on the combo abilities since they are very important. The leader abilities will add a dynamic component to combat, emphasizing the skill of the player. I definitely want to ensure that the gameplay has room for good players to differentiate themselves. I don’t want it to be just a zerg-fest. Leader abilities and banner zealots will be focal points in that regard.

Check back in a week or so, to see if I keep-up my weekly update streak :)

Computer AI : sending zealots to attack target

April 6th, 2014

I added some more intelligence to the computer players. The AI will now send zealots to attack targets, which is pretty much required to defeat a fortress. Previously, I just sent zealots to unprotected portals after the fortress was destroyed. This worked OK before I started to balance the gameplay. Once I added the tiers and modified the combat values, fortresses became much more difficult to defeat.

The computer player will send zealots to its current main attack target. They usually start to head over before the attack, which helps since they are slower than normal troop units. This way the attack troops sync up better with the zealots at the fortress destination.

In addition, I have a counter that allows repeating attacks instead of just moving to the next target if defeated at the current fortress. This tweak takes advantage of the damage done during the previous attack. I plan to add a lot more intelligence to the attack logic. Right now I just want to make sure that the computer player has a reasonable chance to defeat a fortress. That allows me to continue adding gameplay while balancing the combat values.

Next, I will probably implement the tiers for troop types. Each leader class has 6 main troop types, which will be separated into tiers (basic, heroic, elite). The higher tiers are stronger and also cost more power to summon. Each tier requires another concentration slot too, which limits the total number of troops that can be summoned at a time.

For example, basic troops might cost 500 power and take 1 concentration slot. Heroic might cost 1000 power and take 2 slots, while elite cost 1500 power and take 3 slots. This helps balance the game while allowing for powerful units.

At some point, I will add unit information to the web site to give a better idea of the combat gameplay. I’m trying to make more time for blog updates too. Thanks for stopping by :)

More artwork and gameplay changes

March 31st, 2014

I have made more progress with the artwork since my last blog update. The image below was taken from the map editor in game. It shows an early version of the grass terrain, details, oak trees, and rock formations. There are actually 2 styles of the oak tree, which will be changed to the pixel art style for the final version. There are also no shadows yet and that will change soon. Basically, this is just an early version of the assets to give an idea of the art style. I hope you can see the potential like I do :)

Early version of the grass terrain, details, oak trees, and rock formations

I made progress with the gameplay too. I tweaked the combat effects in several ways. First, I combined the three leader abilities for crowd control into one state so only one can be active at a time. These leader abilities can be used to help control enemies when they break fear/stun/mez and have built-up rage. Enemies will have a visual effect associated with both incapacitation and leader crowd control abilities.

Furthermore, each leader class will have a unit that debuffs, which will all stack and be displayed as small icons under the rage tier bar. These debuffs will have powerful results when combined with player and heroic unit damage abilities. The icons will help players identify good targets for those abilities during battles. Finally, the remaining combat effects will include various buffs that have visual effects to indicate when they are cast.

In addition, I added many of the unit abilities and continued to define the roles. Each leader class has a unit for every role, but the combat abilities are unique. I think that this approach will ensure the leader classes are balanced while making the gameplay different. I have concepts related to each class type too. The units of each leader class will borrow from their arch types of knight, stalker, and mage. Those concepts will be explained in detail later.

Fortresses are setup to upgrade structures automatically. The speed of upgrading depends on the banner zealot connections. Therefore, players indirectly control the upgrades through those connections. There are other upgrades that players can choose and those will also be affected by the banner zealots. I want a high-level upgrade process to reduce micromanagement and hopefully give a fun alternative for upgrading. Higher tier structures are stronger and do more damage. Likewise, troops with higher rage tiers do more damage too.

I have a lot more to say about the gameplay. I will start updating the web site soon so it reflects the current design. I also plan to give a thorough explanation from the start of the game to the end when I have some free time. Right now I am focusing on my main gameplay tasks as well as changes required for the new artwork. This will be a busy month! Thanks for reading :)

Combat mechanics

March 9th, 2014

I finished most of the unit design for troops and structures. I also implemented a lot of the core design for the combat mechanics of those units. That meant replacing my old combat effects with a new combat state concept. The new design contains the current rage level, immobilization state, and up to 12 active combat effects (e.g. buffs and debuffs). I use this structure to efficiently update network clients for state changes. Part of the design works for local games too.

The immobilization state reflects whether a troop is feared, stunned, mezzed, or not immobilized.  Each leader class has an elite troop type with one of those effects for its special ability. Only one can be active at a time. Immobilization prevents moving or attacking. There is an additional effect when the immobilized unit is hit by an enemy. For instance, a feared troop might generate a lifetap for the attacker, replenishing some health.

While immobilized, a troop will gain rage instead of decreasing over time. When a troop reaches the max tier 3 rage level, it will break the immobilization. All troops are immune to immobilization effects at tier 3. Leaders and the troops that cast the immobilization effects are permanently immune from it.

The effect is essentially used for crowd control, where a group of enemies can be incapacitated to turn the tide of a battle. The downside is that higher rage levels mean more damage by those troops. Therefore, it is important to kill immobilized troops quickly. That also goes for battles where damage done to enemy troops increases their rage.

I played a few games with some of the initial combat mechanics and it was really encouraging. The gameplay is coming along great. I was able to repel a large attack by carefully using my zealots to reduce time to rebuild my fortifications. I upgraded the portals to generate more power when I had a breather. I made use of my rally points and sent reinforcements while I counter-attacked my enemies. Also, the new assets are looking good, especially with all of the combat action taking place.

I will continue adding the gameplay elements I have on my task list. I’m hoping to have a lot of the gameplay done within the next few weeks. Hopefully I will have the next batch of artwork soon too. I can’t wait to see how everything looks a few months from now! Until next time… :)