next »

[JoeCool]

The pitch:


Wizard Towers (working title) is a simplified fantasy RTS with powerful wizards controlling hundreds of minions, fighting vast battles.


Game Description:

The gameplay is similar to node based strategy games like Auralux, Mushroom Wars and  NeoWars, which I developed last year.

Instead of just sending armies with a single click to another node, the player can control different kind of units (squads) to attack other nodes/towers. Each player additionally controls one wizard, which can teleport from tower to tower, buff troops, repair towers and prevent enemies from taking towers using powerful spells.


The game is 6 month into development now. A itch.io demo version is planned in about a month, it will also include an ingame editor. The following video shows the current state of the game. The devlog is a little behind, but I hope to catch up as soon as the demo version is ready.

_______________________________________________________________________

Start of devlog



Hi there,  

I am working on a new game for about a month now. I am developing the game on my own in Unity, fulltime. Only parts of the current progress is revealed in this devlog.

The gameplay is similar to node based strategy games like Auralux, Mushroom Wars and obviously NeoWars, which I developed last year. I have written a devblog for NeoWars also in this forum.  This time I am starting out a little earlier with my devlog and hope to get some useful feeback. Thanks .


Here is a scribble of what I have in mind for the gameplay.




While those node based strategy games have generally no resources, I have decided to add 2 resource types, gold and mana.

As I want to develop a slightly more complex and strategic game than NeoWars I decided to use resources as they make the decision which node to attack/conquer much more interesting.

As resources are automatically harvested by a nearby nodes/tower, it’s only a slight complexity increase, but there is more to it. Harvesting is semi- automatic. The player has to put the tower into “harvest” mode. The different tower modes are explained later in this post.

Gold is vital, as it is used for building, upgrading and recruiting troops, but Mana will be one of the deciding factors for winning a battle.

Terrain

Inbetween tower nodes are going to be trees, water, lava, traps and also blocking  obstacles which are currently not shown in the scribble. The obstacles can slow down, harm or block troops when trying to reach another node/tower.

In NeoWars I had only blocking and later in the game timed barriers. The new system adds a lot of interesting depth to the game without making it too complex. This time the player is able to build, destroy or influence obstacles using the wizard.

As I am using voxel art, I am not yet sure how I am modelling the terrain at all. I have thought about using a similar tile system as Warcraft 2 did, I would model every single tile in voxel just add a little more depth and variation and create a level editor which can handle the voxel tiles.


This is something I will care about more, when the core gameplay works well enough.


The Wizard

The mana is needed by a powerful wizard! Each player has only one wizard to control.
The wizard can be called on top of each tower. Once called he can heal troops, cast fireballs, burn down nearby forests, repair the tower etc.

If used right he can destroy hundreds of enemy units and can turn the tide even in a desperate situation.

The problem with this approach is: The player has now an additional complex unit to care about which can be easily forgotten in the heat of the combat. To solve that, I plan to reduce the pace quite a bit compared to e.g. Mushroom Wars or other games in that genre.

The wizard is going to be very powerful. In the first few levels the player just needs to teleport him to the right tower to make a difference. As soon as he arrives, the troops of the tower will have improved stats. Also the tower will harvest, produce or have a better defense value depending on its mode.

Spells:

Currently only 3 spells are in the prototype. A fireball, a tower repair and a troop heal, but I have planned to add much more spells in the final game.

The player will not be able to use them all in one battle, but has to decide which he want’s to learn (skilltree). I am currently planning white and black magic, but might add more magic schools later on.

The spell system has yet to be fleshed out. When I started out, I was not sure if the wizard is a good idea at all, but I am now more confident, that he will play a qiuite big role in the whole game. The wizard is also going to be the main hook for the story telling.


The Tower

Towers can be build on each node of the battle field, if the player has enough resources. They can only built when a node is conquered.
The following gif is an example how to conquer a node.  (The first two weeks, I have worked only with cylinders, spheres and cubes to speed up the development process)




The following gif is a very simplyfied level with nodes and two towers. You can also see the resources gold and mana. The battlefields later on will be bigger, but for testing purposes this was good enough.



Tower Modes

Each tower can switch to 3 different modes. Switching mode has a cool down, to make the decision a little bit more interesting.

The towers might change shape or spawn some addons to make sure the player realizes immediately in which mode the tower currently is. I will go into detail in another blog post about this.

Produce:

This is the standard mode, the tower will transport units to the battle field. As I don’t want to make it look like the tower is “producing units” it’s actually opening a portal and teleports soldiers from an unknown location to the battlefield. This costs some gold and mana for each soldier teleported.

Harvest:

Towers can only switch to that mode if resources are nearby. Depending on its level, it harvests gold and/or mana from nearby resource pools. There is no need for workers. The harvesting is done with wizard powers obviously!.

Defend:

As soon as the tower is switched to defend mode, it gets additional armor and archer/cannons spawn on the top. The tower can now withstand a much bigger force.

Tower Upgrades

Towers will be upgradeable during a battle. I haven’t yet decided how this is going to work exactly. Probably only defense, production and harvesting can be upgraded while battling. There will definitely be a skill tree where the player can decide which part of the tower should get stronger.

Battles:

Controlling big armies is always very satisfying for RTS players. I haven’t heard anybody complaining about that ever .

It was actually not planned in my first concept, to have hundres of units on the battle field. After adding more and more units to the game, it felt so good, that I decided to give it a try.

I am not yet sure how big the battles are going to be, but I think several hundred units on the whole battle field will probably be quite normal. This was a first small test which felt quite promising, but I was facing lots of garbage collector spikes even though everthing was pooled. I solved those and other problems already but that’s another story.




It will be quite a challenge to make this a good experience for every player, especially on older computers, so I have to plan carefully as I am the only one working on this game.


Squads:

After playing a lot of other RTS games, I have decided to try a squad approach to get rid of micromanaging single units. Single units will still have a “brain” but act more in the interest of the squad. My hope is also to be able to display more units using squads as some of the decision processes can be done inside the squad.

Another good thing is, that I can get rid of a lot of healthbars and introduce a leveling system, which adds more depth again but does not necessarily make the game more complex.



That’s it for today. Thanks so much reading!

[Pixel Noise]

From my RTS experience, I think choosing the "Squad" control/behavior over too many individual units is a good one. This looks very promising - following! 

[JoeCool]

Hi there! 

I have been busy working on art ideas. I am still not too happy with the current outcome. My first time I am doing the game art myself. This is only a very short update to my devlog. More in depth stuff will follow in the upcoming week.


Animation

I created very simple pixel art like animations with Magica Voxel and importing them into Unity with "VoxelImporter" Asset. The importer is optimizing the meshes and bakes one texture for all the imported meshes, which is really helpful. The archer has not yet made it into the game.



Animations and fight testing

I have made a bunch of animations for the sword fighter and tried a bigger fight. Due using an instance shader my drawcalls are pretty much stable not matter how much units get deployed. Even though different meshes for the animations are used, performance did not really go down. The wizard on top does not yet have any animations.

I have also added a pushback, some blood decals and some more sublte effects like the slash, bleeding, walking dust etc. It's probably a little too much going on atm. Have to see how I am going to solve this.



Tower Modes

I have tried to visualize the different modes for the tower.
- The wall around the tower shows the defense mode.
- When in harvesting mode the gold and mana resources are getting a lightning effect as well as the tower has some gold and mana growing on its walls
- "Production" mode open the portal and spawns new soldiers



I am happy with the animation workflow and doing art in Magica Voxel is satisfying and fast enough for the stuff I am planning to do. I have still to figure out how to do the terrain/tile system. I have started a few tiles for testing, but it's not ready to show off.

[gantt]

Actually, this looks really good! and true, I feel the flow is smooth

[JoeCool]

From my RTS experience, I think choosing the "Squad" control/behavior over too many individual units is a good one. This looks very promising - following! 

Sorry missed your post. Thanks a lot mate! Much appreciated. Haven't yet tried to implement Squads. It's something I am going to work on today.

I have still a lot of hard design questions to solve. Especially if the player can place units everywhere or just around towers. While I am implementing squads, I will also try to place them anywhere on the map and see how it goes. Oscar Stalberg heavily inspires me with hits upcoming game pic.twitter.com/L4XVq354tr. His fights look really good and he is using a unregular grid placing his squads. Not sure if this fits my needs, but it's a really clever idea.

[JoeCool]

Actually, this looks really good! and true, I feel the flow is smooth

Thank you! Glad somebody likes my "art style" .
It's really just a start. 

[Beyond]

The archer animation looks really good. Good work.

As for me, blood is a big turn-off. Though I'm not sure how common that is.

[JoeCool]

The archer animation looks really good. Good work.

As for me, blood is a big turn-off. Though I'm not sure how common that is.

Thanks for the feedback. Glad you like the animations.

I am not sure about the blood decals either, they are very peculiar as there is no terrain yet, this might go away with some proper terrain. I think it's quite common, using blood as an indication for a big ongoing fight.

It might just not be fitting for a voxel game. 8 bit hordes for example does not use any blood at all.

[JoeCool]

I have finally implemented the squads logic and the archers. Just a very short update for today. I will go into much more detail in the upcoming days.

[JoeCool]

In the last few month I have mainly worked on a terrain system and the ingame editor.

As I decided not to use the Unity terrain system, I had to come up with my own solution. I looked into marching squares. Unfortunatley is the site down so I can only link the tigsource thread and the html5 implementation of it.

Here is a gif of how it currently behaves in my ingame editor:

The system is currently quite limited. I am only able to connect water to earth, earth -> grass, grass -> stone, stone -> mountain. I might be changing this later, to be a bit more flexbile in terms of levels. Here is an image from the same guy (Timothy Landers), with an improved version. This would really help to make more interesting landscapes.

To improve/speed up the level editing process I made a brush tool for props, to add them in different scales and rotations as well as variatons. The gif shows an example of how that currently behaves. It really helps to make good looking levels in a short amount of time. I can also move and delete props quite fast with that tool.

The next step was to place nodes, which the player and the AI can interact with. Nodes also do have some constraints in terms of placement. The need to have a certain distance to other nodes. Node props allowed in a certain radius and they need to have some land under them. The brush works almost exactly like the props brush, but has more constraints applied and also changes the metadata of the tiles if needed.

As I wanted to be able to give AI or players a head start in a level, I also needed to add the ability to add resources, towers and a certain amount of troops in the editor. I have tried avoiding writing new code for the editor, so I used most of the time game code which is visible when you spawn units in the editor, they are spawning as they would ingame.

The navigation mesh is also generated when placing props or units, as I use the navmesh also for collisions. As Unity supports now navmesh generation on the fly, its easy to update it when editing the level. Unfortunately it is still too slow to use it ingame, but I hope they are going to fix this soon, as they already have a asynchrouns generation, just use up too much time per frame. As you can see in the image, the navmesh has to be quite detailed, due to the fact that I am working with voxels.

The ingame editor also has some more features like adding and removing players, win conditions, map resizing, map naming, save, load etc. Here how the editor UI currently looks like. It's far from perfect and needs a lot more work, but it's ok to editor some levels for now.

Making a small test level is a matter of seconds:

[JoeCool]

Just a short update today. I am mainly working on the AI basics which is quite complex. To keep my motivation up I started daily voxels to push the look of the game and improve my voxel skills, which are still very basic.

Two days ago I made a volcano:




It didn't look really good, but I thought maybe I can integrate it into the tilesystem as I did with the snowy mountain. So I tried an it worked out ok.





Now I have plans to make the vulcano a gameplay feature. It will have a "calm" state and an "eruption" state. In eruption state it will spread lava, can cause fires and might hit units on the way to their node. The lava is currently static, I will  make this more dynamic, so that during eruption state the lava gets spread all over the mountain and fades out, when switching to calm state.

[JoeCool]

I made a relic portal today. As I want to be able to reduce transportation times for squads, the portal can be used by wizards to teleport squads to those portals and also transport squads from those portals to nodes. I am also planning to use it as a tool for survival map scenarios. So I can bring endless streams of enemies into the map.

After receiving some feedback, that I would  use too many voxel sizes I made a new version. It looks much more consistent now.

I still have the problem, that the terrain and the props use different voxel sizes. Have to see how I solve this problem. Changing the voxel size of the terrain would let the polycount explode and make the navmesh generation even more problematic and slow. Have to think about a better solution.