Void()

After countless tries I finally managed to create something that approaches presentability. This is still just a Photoshop mockup, but it demonstrates where I am trying to go.

I will add a little box to the bottom right for the turn counter and then think about adding a minimap somewhere at the top right (maybe move the sidebar down to have more space). The energy bar at the left side will get evenly spaced segments (that disappear one by one when hit) or a big one (that just shrinks). I prefer the first option. Also I might make it smaller. The color of the outline is the same as the player character’s outline, but I might change them both.

The hexagons at the bottom and the right will get little icons for the different weapons and items, with the other weapons resp. item count in the small boxes below.

I would show you my failed attempts but thankfully, I mean regrettably, I don’t have anything besides pencil sketches and my memories of these tragedies.

I started creating the enemy models with some simple idle animations. The first two are two flying ones, one ranged, the other melee. Especially the later one packs some punch…

I created some power-ups the for use by the player: a shield, that absorbs damage and when it is saturated it will emit the stored energy and hurt nearby enemies, a mine, that explodes when a enemy comes near it – multiple charges, a bomb, that explodes after a given number of turns, a turbo, that doubles the players movement speed and a health pickup, that heals the player. The mines’ and bombs’ explosions will hurt the player, too, if he is in range, but he will not trigger his own mines. Also I created a crate, that reveals one power-up when it is destroyed, either randomly or predetermined.

The top parts of the pick-ups rotate, as does the crate.

Partly thanks to the guys and gals at Answers.Unity3D.com, I solved the problem I had with the collision detection. It is essentially the same approach I already tried, twice, but apparently now I did it correctly. I have a two-dimensional array, in which every actor in the scene stores their position, and if a tile is occupied, no other actor can move onto it. When an actor leaves a tile, it is set to unoccupied again. I also used this array to create a boundary around the game world to keep the player and the enemies on it.

I added a bunch of new particle effects. Player and enemies explode in a cloud of triangles, projectiles have a muzzle flash and spawners announce their spawn.

Next: Powerups.

I added an experience system. Upon level up, the player gains more hitpoints, deals more damage and gains resistance to damage. The maximum level is currently capped at 10.

Also, I added a particle system for leveling up.

I added some particle effects to the projectiles that are used, when the projectile dies, either of old age or when it hits an enemy or the player. Also, projectiles now can hit enemies and the player and do damage. Man…this game is hard, if you aren’t cautious…

I use the same particle effect for blaster and laser, so there are only two currently. But there will be more later; for enemies and player dying, for spawning new enemies, for explosions, for muzzle flashes and whatever else I can think of.

 

I wrote a little script to let enemies shoot the player, whenever they are aware of him. They shoot only in the six cardinal directions, so they miss often, but it is still hard enough to not get hit, especially if you don’t play slow.

The player can now also shoot. He has two attacks (left and right arm), but I haven’t yet implemented melee or the ability to switch weapons during runtime. Hit detection also isn’t working yet, so even if you hit something, you don’t hit anything.

Here are the three basic projectile types (the player’s). Just three intersecting lanes with an alpha texture. They also use a script so I can change properties like rate of fire, damage and speed.

I encountered a (not so) little problem. My movement algorithm seems to be highly resistant to registering collisions. I move the objects directly and so they ignore any collider in their way. To prevent this, I would have to apply forces on the objects instead, but this would nullify all benefits from the new algorithm. Also I don’t want them to stop anywhere on the map, they should stick to the grid, so they would have to know that their destination is invalid, before they start moving or – even better – before they choose a direction.

I tried creating a two-dimensional boolean array and assign true/false values to each tile on the map to test against, and it kinda works, but only with predefined tiles. Setting tiles invalid during runtime doesn’t work. Maybe I am doing it wrong.

I will try and conquer that problem later.Until I have an idea I’ll be working on other parts. Fighting, powerups, experience, some FX.

I rewrote the algorithm for the movement completely. Instead of just using translations relative to the last position, I now generate waypoints on the grid, on absolute positions, each turn and move the actors between them. At the end of each turn I place each actor exactly on its waypoint. I think I am content with the robustness.

The behavior itself doesn’t alter visibly from the last algorithm, so there is no new video, but here is a screenshot showing the waypoints.

The yellow points are used for random movement, the green ones for hunting the player, cyan for spawning new enemies, magenta for the viewing direction of the player and red and blue for the player movement.

At the same time I added some more enemy types: flying enemies, that aren’t completely constrained to the grid (they start and stop on a tile each turn, but can move outside of the six cardinal directions), turrets, that are stationary, but have a long detection range and spawner enemies, that create new enemies (within limits; each spawner has a maximum number of children and stops spawning new ones, once this number is reached. If one of the children is destroyed, the spawner can resume spawning). As before, all models are placeholders.