Archive for June, 2013

Some gameplay tweaks and additions

Tuesday, June 25th, 2013

I’m almost done with the current milestone. I’ve been able to complete most of the tasks, although I had to push a few things off to future milestones. I also made a few tweaks to some of the gameplay concepts described in the previous post.

Portals no longer share specific technology to destination portals. I wanted to streamline the technology process since I think there would have been too much micromanagement with choosing tech to share. It was also tough to separate types of technology that would be shared from bonuses that would not be shared.

Instead, I now just increase the progress of the technology being upgraded at the destination fortress. Each friendly source portal connected to a destination portal will add a “tick” of progress equal to that of the local fortress. For example, one source portal with continuous zealots will double the technology progress, two will triple it, etc. This design is more consistent too since any enemy portals will have the opposite effect where the progress will be disrupted by that same amount.

In addition, portals no longer summon any troop type.  Each fortification is responsible for a specific troop that can be summoned from the portal when it is built. The fortification has upgrades that are related to that troop, where the available upgrades are limited according to the tier of the portal. As the portals are upgraded, more options become available for those fortifications. The same fortification can be built multiple times at a fortress. There are 4 fortification slots total.

I will allow players to queue summoning troops. I also plan to tie the summoning to the fortifications so 4 troops can be summoned simultaneously at each fortress. I will have a fortress options bar that has all available troop types and zealot actions for the selected fortress. This fortress bar will always be displayed even when not selected, changing when a fortification or portal is selected at a different fortress. The selected structure will show upgrade options in a different options bar. I will make sure that the GUI is streamlined to make the fortress management easy for players.

I have some basic upgrades in place, but most will be added over time. I am aiming to have 6 unique troop types for each leader, as well as a unique flying guardian and zealot type for each. There will be 6 fortification types to match the available troops. Portals will have 3 types to show the current upgrade tier. With 3 different leader types, the artwork requirements will add up quickly. I hope the variety of troops and structures help make the game fun and interesting.

Finally, I added some code to upgrade a portal so it has a guardian protecting it. Right now, it’s just a simple attack that is powerful and can be used while the portal is invulnerable to attack. Eventually, I will add a cool effect of a guardian that looks like a shimmering image, protecting the fortress from harm. Also, players will be able to research a zealot ability to send the guardian to a destination fortress. If the guardian makes it to the destination, it will attack enemy portals and dump remaining health as prestige to friendly portals or those not owned by any player. This means a guardian could destroy an enemy fortress and then automatically claim it if enough prestige remains to meet the requirement.

I’m going to finish a few gameplay tasks before completing this milestone. I want to increase power yield for upgraded portals and add some basic upgrades for zealots. I might add some basic fortification upgrades too. I only have a simple health increase option at the moment for testing. Maybe I will add the troop queueing and multiple summoning too. Some more computer AI for upgrading would be useful to test the effectiveness of upgrades. I will see how much gameplay I can get into the game during this last week. The next phase is mainly for artwork, so I want to finish as much gameplay as I can before I start that phase.

Pulse events

Sunday, June 2nd, 2013

I just finished the gameplay for a concept that I’m calling a pulse event. Every 2 seconds the world experiences a pulse event, where the magic crystals generate their power. Players now gain their power from all owned portals during this pulse event — all at the same time. In addition, source and destination portals with continuous zealots (no gaps) between them, process their pulse events during this time. The non-continuous zealots don’t produce any benefit, although certain types can still do reactive damage when killed.

If the target portal is active, prestige is gained for the source portal. Friendly portals can share technology, where the target portal gains a “pulse tick” of progress. This pulse tick can be accumulated from multiple sources at once, even while the target portal works on that same tech locally. That would be an unlikely scenario since it would be inefficient, but it would be possible if a player wanted to really speed-up the research of a particular active ability.

On the other hand, if the target portal is an enemy, the pulse event will disrupt the upgrade progress for the entire fortress. Under the hood, the game will add time to the upgrade timer in the amount of the pulse time (2 seconds). This is done for every enemy source portal that is generating a pulse event for that target portal. The maximum amount of upgrade time is currently 30 seconds, which is the same refresh time when a fortification is destroyed (to prevent instantly recreating destroyed fortifications).

Adding upgrade time essentially halts progression for the fortress, which prevents rebuilding fortifications and locally researching technology. Players can use this strategy to effectively lay seige to a fortress by cutting off “supplies” from friendly zealots while halting progression of a fortress. This enables the player’s troops to destroy the fortress.

Once destroyed, the player’s zealots will add prestige to the target fortress. The first player to add the required prestige will repair the portal and gain owneship. At some point, I will track damage done to the portal during the seige so I can give the tie-breaker to the player that did the most damage. Otherwise, other players could be vultures and just swoop in for the portal after another player did all of the work.

I’ve been testing these features, mainly by watching the computer AI play against each other. I think the flow of the game is really fun and interesting even at this stage. The interactions with the zealots allows for some unique gameplay. In the near future, I will add some additional components to the zealots to expand upon that gameplay.

The zealot at the front of a continuous line for a source portal will hold a banner to make it obvious. Right now I just make it partially transparent for debugging. This banner zealot will be a focal point for the gameplay. Leaders will gain rage during the pulse event when standing near a banner zealot and those marching zealots are not ”connected” to the destination portal. The leaders can gain up to 4 rage pulses and they start to decrease when a pulse event is missed until none exists.

This rage resource is required for the most powerful abilities. It will allow leaders to devastate enemy fortresses as well as gain the upperhand along the zealot paths. I envision intense battles happening along these lines as players struggle to push forward to an enemy fortress. Leaders can summon towers, blast enemies with abilities, and command their elite troops to destroy the enemies in an area.

I will give some special abilities for each leader class too. For example, the shadow mage might be able to teleport to a banner zealot in a surprise attack. Maybe the shadow knight can resurrect a fallen zealot to reconnect the zealot path, while the shadow stalker summons a swarm of beetles from a banner zealot to attack nearby enemies. I will work hard to create many interesting options for the zealot abilities.

My next step is to work on the guardians while I add the abilities and upgrade paths. I have many of the tech ideas on paper, but I need to implement them and figure out a logical way to divide those abilities/upgrades for multiple tech trees. Check back later to read about those details :)