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.

I wrote a little algorithm to control the movement of the Player Character and the enemies to demonstrate my gameplay idea that I mentioned in my last post. The algorithm itself works, but is a bit unreliable, since little errors will accumulate and the characters might move off the grid, so I’ll rewrite it completely, but it is good enough for a proof of concept.

The enemy is just a placeholder.

I just started creating my first game. I will be using the Unity Engine to power the game and 3ds Max and Photoshop (if I need textures at all) for asset creation. Working title is ‘Void()’.

Story is about a computer program tasked with eliminating intruders in a system.

Here is a screen of the main character with the different available weapons:

From left to right: Laser, Blaster, Plasma, Lance, Sword, Mace.

I hope I can create a similar look with Unity Shaders.

Gameplay-wise it will feature what I call real-time-turn-based combat. The player can move in real-time and the enemies will move at the same time, but when the player doesn’t do anything, everything else will stand still, including explosions and projectiles. It would allow the player to choose between fast and tactical gameplay on the fly.

A little science fiction sketch I did recently. A mixture of bird, amphibian and a pinch of gorilla.

Here is a 3ds Max Viewport Grab of the robot with basic textures and DirectX shaders. Details will be added later. As you can see I have some problems with the display of Alphas; they hide the geometry behind them, but somehow only at some places (they don’t hide the feet, but the toes, the legs are hidden by the upper part of the central beam). I don’t really know what causes this. Haven’t found a pattern yet.

A small wooden lodge for Tehadon. Textures are still WIP. Roughly 6600 tris, 2k textures (modular).

(rendered in Mamoset Toolbag)

(rendered in Marmoset Toolbag)

Wire:

So…after finally finishing the bake, here’s the lowpoly version of the robot. 12.800 triangles. I used the same shaders like with the highpoly and added the Normal/AO Maps. It is missing the red eyes, since they are not separate meshes in the low.

Additionally, here is a wire-shot.

After getting some feedback I added an additional ‘outlet’ between the tentacles. Doesn’t even look bad.

A multiple stories tall killer robot in the style of classic SciFi movies.

Highpoly with basic materials (~4.5M Faces). Lowpoly will follow.

I would have posted the sketch for the robot earlier today, but somehow my scanner decided to stop working, so that was not an option.