Birth of Shadows - Greenlight

July 12th, 2015

It’s been a while since I updated this blog. I have been busy working on a major update for Birth of Shadows. I released it on July 3rd, 2015. The version 1.9.9.1 update focuses on new artwork for a lot of scenery and the terrain, using the design from Pursuit of Power 2. I also added the code for smoother path-finding, improved visual effects, and lots of other polish. You can find the full list of updates linked to the information page for Birth of Shadows.

After the update, I launched a Greenlight campaign to get Birth of Shadows on Steam. Please help spread the word. Every vote counts! :)

Birth of Shadows - Greenlight

Pursuit of Power 2 - Kickstarter on 4/21/2015

April 21st, 2015

My Kickstarter pitch for Pursuit of Power 2 was launched today! You can view the Kickstarter page here.

I took a bit of a risk and explained the gameplay as part of my video pitch. I tried to sound more “peppy” but it is a lot harder than you might think. Plus I don’t really sleep anymore, so that didn’t help :)

If you have any questions, please feel free to post them on the forum. Thanks! :)

First internal alpha release

March 24th, 2015

The screenshot below shows the structures for the Shadow Knight, which are currently being used for all 3 leaders until those sets have been completed. The fortification towers have a gargoyle at the top, which opens its wings during an attack. The portal stronghold continuously animates while it is active. Both have frames for being partially destroyed too. The bone tower is the basic tier 1  combat tower. The guillotine is the tier 2 tower that generates prestige when it kills enemy zealots. I added a dark treant to show the scale since that is the largest troop.

Pursuit of Power 2 SK Fortress

As for my progress, I made so many changes this past month that I don’t know where to begin. The game is in great shape. I just sent out a test build for the alpha version to a few friends. I want to start getting early feedback so I know if the game has any major issues. I also want to get an idea of what direction I should take the game, based on what aspects are the most fun.

I tweaked a bunch of stuff. The user interface is further along. Multiplayer had a few issues fixed. I moved all structures and magic sources to the final design layout. That allowed me to add the new artwork. I also made some changes to the design for the guardian.

For now, the guardian upgrade can be purchased after the fortress reaches max level. It costs both power and a lot of prestige. Once upgraded, fortification towers and banner zealots for that fortress gain an additional AoE ability. Those abilities refresh using the same timer that automatically levels those structures. That also means the refresh timers can be sped up by friendly zealots that reach the fortress. They can be halted too by enemy banner zealots.

In addition, a guardian buff becomes available that costs power and prestige. It adds a buff that lasts for 30 seconds. While active, those guardian attacks are greatly amplified. Enemies can be devastated with careful timing of that buff. Leaders can also use their zealot sacrifice ability to directly trigger the banner AoE in the middle of a group of enemies.

I’m going to update the web site this week. I hope to finally add a page that describes the units and other gameplay features. I’m completing the final alpha milestone in a few weeks. Then I will create a video that shows the main game features. I’ll also use the core part of that video for my Kickstarter campaign, which I plan to start on April 16th. More on that soon… thanks for reading! :)

Treants and Avatar

February 18th, 2015

The screenshot below shows different angles of the Stalker’s Treant troop. That is the siege unit, which has a special ability called Murder of Crows. When activated, the crows sitting in its twisted branches carry sharp barbs to friendly troops to provide a damage shield. I also included each player color so you can see all of the variations. As a reminder, gold is used for your troops, blue is used for allies, and red is used for enemies.

Pursuit of Power 2 Treants

I also added an avatar image to the game interface. Right now it is a rough draft, but it already looks cool. The current version shows the head and shoulders of a hooded figure with a hidden face. Spikes stick out of its shoulders. I display the current number of enemy banner zealots that are attacking your fortresses using red text under the avatar. I plan to make many improvements to the design, including animating the avatar. I also want to add voice overs to give situation awareness.

In addition to that interface change, I made several other tweaks. I added a divine bar on the right to mirror the avatar bar on the left. The avatar bar is used to activate the avatar abilities mentioned in the previous blog update. The new divine bar is focused around divine abilities (zealots and guardian). That includes the option to select a banner zealot destination, teleport leader to banner zealot, and two more powerful abilities.

The guardian of the fortress can be summoned to cast a powerful breath weapon at a chosen location. I still need to implement that breath weapon, but the general idea is that it will cause a lot of damage and include some special effects. It will probably have a longer recast that is affected by the fortress timer (influenced by banner connections).

The other ability buffs the banner zealot and will also be tied to the same timer and recast mechanism. I’m planning to modify the current banner AoE to only happen when this buff exists. Also, I will probably only trigger the AoE when the leader uses its sacrifice ability on a connected zealot while the buff is active. Both of those abilities will most likely cost prestige in addition to power.

I mentioned previously that all 4 avatar abilities also cost prestige. At the time I just had a few of those abilities implemented. I now have all avatar abilities implemented with some kind of useful effect. Most will be modified further, especially the ones that are generic. I just want something in place so I can test them out. It will also help when I play my first Internet game with a friend in about 3 weeks.

Besides that stuff, I created the design layout for the fortress and tower animations. I have the layout done for the crystal animation too. The structures are taller than even the siege units to they create some scale to the game. Fortresses will show a pulse effect that matches the crystal pulse before the fortress is summoned over it. The fortification towers will have a simple attack animation. Both have a frame for when they are destroyed. The detached towers will have a more intricate attack. The initial version of the fortresses for all 3 leaders have been created already. It will be great to have the completed artwork for them in game. I have been using the placeholder art for a few years now.

So I’m continuing to add new artwork to the game. I will be sure to always include a screenshot in each new blog post, at least for a while. I’m also adding more details such as shadows to trees. Plus I’m tweaking the multiplayer. All of these efforts will help prepare the game for outside testing as well as my Kickstarter (early April). Thanks for your time! :)

Prestige is back (and more)!

January 27th, 2015

Before I start my update, I want to show the 3 leader classes as promised. They are the Shadow Knight, Mage, and Stalker classes from left to right.

Pursuit of Power 2 Leaders

A few weeks ago, I started thinking about ways to encourage (reward) aggression in the game. I think that is a good goal because it encourages battles and a path to ending the game. Otherwise I will just play Monopoly if I want a really long game :)

So I decided to add prestige back to the game, but done in a different way than previously envisioned. The most prestige is gained when your banner zealots reach an enemy fortress. You also gain some prestige when your “sacrificial tower” kills enemy zealots. The amount of prestige earned scales to the level of your tower, which increases over time. That way players can’t just drop a tower in a good spot and immediately gain a lot of prestige. The other player could counter the new tower by attacking it before max level is reached.

The prestige can then be used to cast some new avatar abilities I created. They are tied to the avatar presence that will be providing situational awareness in game, such as to warn of attacks. As a reminder, your avatar is the connection to your god from whom you derive your powers. The abilities are very powerful buffs and therefore have longer refresh timers than leader abilities. There are 4 total and they affect different aspects of the game (leader, troops, towers, zealots).

For example, the avatar ability of the Mage that affects leaders might alter an ability. It could modify the Meteor Shower ability that only affects troops so that it has an Aftershock component that also damages towers. That would be the only ability that players can cast to directly damage towers. In addition, the mage leader troop could be buffed in some way that gives a big advantage while the buff is active. That gives more value since the Meteor Shower ability could only be cast 3 times total while the avatar ability is active.

I’m pretty excited about the possibilities of the avatar abilities. I think the prestige will add some fun too. Right now avatar abilities will require prestige in addition to power. I could add prestige as a cost to other things in game, but I don’t want it to be the main focus. I just want to augment the current gameplay with it. I also think the concept of sacrificial towers is cool. I’m envisioning a Shadow Knight tower that is a guillotine with simultaneous long-range and short-range attacks. I have ideas for the other classes too, which I will reveal later.

I made another change to tower concept. I’m just going with 2 types for now. One is the tier 1 basic tower that will probably be affected by avatar abilities. The tier 2 tower is the sacrificial one. I’m keeping the unit pools separate between troops and towers. But, I’m limiting the towers to 50 max focus while the troops will be limited to 100 max focus. That should still give some strategy to unit selection.

I also made a bunch of fixes to the game setup for various situations. There were a few actions that could crash the game. The client and host could get out of sync too. Plus a bunch of other random stuff.

I’m continuing to work on the GUI layout. I am making room for the avatar, probably at the center of the menu bar. I’m tweaking the other information too. I should have the Dark Treant siege troop in game soon. It looks very cool. I’m planning to play my first net game over the Internet (as opposed to LAN) in about 3 weeks. More to follow… thanks for reading! :)

ALPHA 3 Milestone Completed!

January 4th, 2015

I just completed the ALPHA 3 Milestone for Pursuit of Power 2. Only one more ALPHA milestone until I officially start working on BETA releases. That will mean I am mainly working on content, gameplay tweaks, and polish. Until then, I will continue to implement the remaining major components while fixing bugs that I find.

I improved the pulse event for multiplayer so zealot projectiles are shown if source or target is visible. That is a similar design to the previous update for player units. Sometimes the zealot pulse wouldn’t show on the client due to order of events. Now it works very well.

I streamlined my entity classes in order to consolidate some of the design for units. That made it easier to allow towers to be stealth, which will be used for at least one Stalker tower. It will be sort of like a trap. I also increased the towers to 3 per leader class. Each one is a separate tier to match the troops. They use focus too.

The additional towers will give me some more gameplay options. Right now I am probably using the previous tower as the tier 1 unit. It will have some basic abilities and provide a solid defense when it upgrades to max level. Tier 2 will involve some kind of buff or debuff AoE. Tier 3 will be a strong tower that is intended to control a key point on the map. It will most likely have multiple abilities that fire at the same time, including AoE zealot damage. That will help control an area and demand attention from enemy players.

I will continue to refine the tower design. I have some other ideas such as triggering AoE abilities when hit by leader abilities and possibly troops too. That mechanic could add some interesting gameplay options. Maybe zealots interact with them too. I definitely want to explore more ideas with the towers, zealots, and fortresses. I think the defensive capabilities of the fortress are too strong right now. Some more options are needed to improve offensive capabilities, which should always be greater than defense to ensure no stalemates.

I reduced troops per leader so now there are 5 total. That allows me to focus on more concrete roles. Plus I can move some of the abilities to the new towers. I’m considering a combined focus pool for summoning all units. Currently, I have separate troop and building focus to control the limits better. But I do like the idea of placing more importance on strategy with summoning units. I think that becomes more interesting with a combined unit focus.

I will be getting some outside feedback soon on those types of gameplay considerations. Every month I feel like I have more of the gameplay solidified. There are still some decisions to be made, but I feel good about the direction of the game. I look forward to showing some gameplay video in 1-2 months. I also have all 3 leaders completed, so I will show a screenshot of them in my next blog update. Oh yah… Happy New Year! :)

Lots of tasks completed for PoP2

December 14th, 2014

I spent the past month working on a lot of different tasks. This is part of my push to get the game ready for Internet testing within the next few weeks. Finishing-up all of the loose ends always seems to take longer than expected.

I finally decided that most of the shadows in game would be done as a separate pass instead of being baked into the artwork. Removing the shadows from the artwork means I no longer need to use 32-bit textures with an alpha component. So I can reduce the graphics memory almost in half, which is a big advantage. I also have some more control over how the shadows are displayed. I am currently using a simple oval graphic that takes color from the vertex data, which right now is just black. I’m satisfied with the way it looks. Right now I just have troops using that method, but eventually I will use it for other assets too.

I also needed better control of where my projectiles start and when, in order to match the new troop attacks. This is especially important with animations such as a bow. I will further tweak the design to allow sync with actual attack frame. Right now I just have an x/y offset and a delay value, which is better, but could still use some improvement.

I fixed a glitch with rendering my zealots too. I was rendering them in the wrong order, so the z-buffer was removing some pixels, which made them look weird. Now they look correct. I might have to make a few adjustments with some effects that seem to be in front of certain entities. Not quite sure why that is happening when other effects look good. Hopefully that will be a quick fix.

I have been wanting to show the banner refresh timer on the selection icon for a while now. That timer tells the player how long until a new banner location can be selected (to march zealots to that location). The current refresh value is 60 seconds, so that is important to know or it would be annoying to keep guessing wrong. Displaying on the local computer was easy, but getting that information to the client was a bit of a pain.

I had to add some core code to sync pulse events between server and client. I spent some time to get it right, because I will use that mechanism for other timers in the future. Once I completed that code, I sent the banner ticks to the client and handled a few edge cases. Now players can see the banner refresh timer for single player and multiplayer games.

When I finished that multiplayer code, I realized I needed to work on some other related improvements. I made the client more robust for certain cases when entities are removed. I streamlined a lot of the update code to reduce complexity, which should make it less prone to mistakes. I fixed a few possible crash conditions too.

I  also finally tackled a limitation of the client update for certain attack conditions. There was a problem when a client player observed a visible enemy attacking a non-visible enemy. I used to only send the entity data for the visible enemy, so the attacks to the non-visible and from it, would not work correctly. So I introduced the concept of an indirectly visible entity, which would just send data for its type, position, and optionally an attack. That way I still only send minimal data to the client for visible or indirectly visible entities, while supporting the required state information to allow those attack conditions. It took a while to get it completely right due to many edge cases, but it works great now.

Then I fixed a few other sync issues. One was related to a rare bug with the leader teleporting that depended on the order of the index value. I actually remove the leader where it teleported and then create it with a new instance and matching health of previous instance. That way projectiles fire at the correct leader if it teleported while being attacked. The order was preventing an update for the new instance. It is now fixed.

I also resolved a really nasty issue when zealots were removed. The pointer was incremented incorrectly and it was really subtle. In fact, it worked most of the time so I had some trouble finding the bug. I had to actually add sync values after each data section, incrementing each time and adding some other signature values. Then I compared expected to actual value. It took longer to write that code than to find the problem. I fixed a few other multiplayer issues and now everything seems to be working well, even  after some burn-in testing with other sync checks.

Then I noticed death effects weren’t working for fortresses. I totally forgot I never sent that data over to the client. I had to increase the size of the fortress header and reorganize the bits. I decided to tweak that area while I was at it. Now the fortress death effects are displaying on the client.

Finally, I smoothed the troop movement by introducing a constant delay on the client. That allows the next update to arrive before the troop reaches its destination. Now the lag and jitter of the network don’t affect troop movement (up to 80 milliseconds).

So, you can see I have been busy! I will continue working on those types of details to get the game ready for Internet testing. I’m definitely looking forward to that milestone. The mage leader animation is almost done. I will post a picture of all 3 leaders when the mage artwork is completed. Fortress and tower assets will probably follow, then back to troops.

I promise to start posting screenshots regularly once I get to that point. Same thing with the new video. My prototype video is really old and I’m anxious to show the current state of the game! Thanks for reading this long post :)

Animation layout, effects, and time flies!

November 13th, 2014

I really meant to post an update a few weeks ago. I don’t know where the time went these past 5 weeks. I had less time than usual to work on game dev. Our 9 month old son was teething and has also started waking up a lot during the night. That means late nights and being really sleepy. It’s still great, but man it has been rough! :)

The main accomplishments since my last update involve animations and effects. I had to make a bunch of changes to the animation layout for the new troops. I also need to maintain support for the old layout until I have all new assets. That required some new code and it took a bit longer than I had hoped. But now I have the Shadow Knight and Shadow Stalker both in game. They look cool.

The Stalker has a bow for her attacks. That also made me realize I will need to add an arrow particle effect as well as control over where it is fired. That way I can line it up with the center of the bow for each direction. I can use that for all of the other troop attacks too so that should look more accurate when I’m done with it.

I started making some changes to leader effects too. I decided to make the particle systems more flexible so I now have 10 emitters for the leaders. The troops only have 3 emitters, which cover projectile, AoE at target, and a death effect. For the leader abilities, I display a projectile and then cover the area with randomly emitted particles for each of the 9 tiles. Then I display the ability icon over each troop that was affected by it. That way players get useful feedback on what was hit by their abilities. Eventually I will create more intricate effects for each ability, but this works for now.

I also had to send the targets from server to client. So I added some code to track those targets, send the ones in line-of-sight for the player to the client, validate them, and display after all update data received. The code seems to be working properly after some quick testing. I pushed back the Internet multiplayer test to December. That’s when I will start to get a better idea of the state of multiplayer, but I’m not expecting any serious issues.

I will also show new screenshots after I get some structures in game. I’m tempted to show the new leader animations, but I would really like to show them next to a new fortress. I have some new terrain too, but need some more tweaks. Once I get all that stuff together, I will show screenshots again. At some point, I will regularly update with new ones as I get new assets. I’m not quite there yet. Same thing for a new gameplay video. But, I am definitely anxious to show new stuff :)

A while back I think I mentioned some ideas for guardians. I wanted to share some more possibilities for them. To refresh your memory, fortresses can be upgraded with a guardian once they reach tier 3. It costs power and takes time to summon the guardian. Once it inhabits the fortress, new options become available, such as attacks for the zealots when the banner is destroyed or sacrificed. I have some other ideas that I think could be fun.

I was thinking that the fortress could actually morph into the guardian. So the fortifications could change to creature limbs and the portal keep could become the body/head. Then it starts to resemble a boss fight where limbs might each have a different combat ability… sort of like the Quarm fight for anyone that raided in EverQuest. Maybe even players can control some aspects of the fight when defending against attackers?

I can think of lots of potentially fun mechanics for that kind of approach. It will really depend on budget (for artwork) and time (for gamplay coding). I will definitely be looking for player input on gameplay ideas like the guardians. Hopefully I can build a community with my future Kickstarter and Greenlight campaigns. I pushed those off to the end of February 2015 to give me some more time to flesh out a few ideas and add more artwork.

I will try to update more often. Thanks for stopping by! :)

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! :)