Update 45: Rebuilding random levels

Using the new resources I have, I've rebuilt the level generator, generating diorama levels with a wooden border again. I was pleasantly surprised how well the level generation code looked and worked, after not looking at this code for a year. Here are a few screenshots showing the progress. At this point I only have 5 variations of tiles, so there is a lot of repetition, but it's easy to add more tiles. Here are some screenshots: 

Next is path-finding!

Update 44: Splitting the Engine

XCOM is obviously a huge influence to this project, both the 1994 and 2012 versions. In a recent interview, XCOM designer Jake Solomon talked about a "Cinematic" piece of the XCOM engine. This was a really insightful and interesting way to think about how the player is immersed in the game via movie like cuts that are interlocked throughout game play. The idea is that when you have a move, the engine, (I'm going to call this the "Interaction" engine, as this is where the player makes choices and then observes the results), calculates the result of, essentially, the next 15-20 seconds. This is then fed into a "Cinematic" engine, which moves the camera around to create a movie like feel. This is what puts the camera behind the player to shoot, moves the camera to see an enemy when a overwatch action occurs and helps to show the 'killcam'. This also helped to explain a few glitches that happened where you would sometimes shoot through cover, probably because the engine considered the cover to not be in the way.

For example: A player decides to move to another location. The interactions engine figures out along the players path if anything will happen (enemy overwatch) and predetermines all results. (perhaps in this case, an enemy will have an overwatch event, shoot at the player and kill them mid path). This information is all passed to the Cinematics engine which controls the result. The camera would start by showing the players movement until it reaches the point of the overwatch event, where it would move the camera to show the enemy firing and then move again to show the player dying.

I really like this idea and think there are a lot of benefits in implementing it. You are essentially making it easier to test, (as you can setup the same set of events and reply them in the cinematic engine), as well as really separating the core mechanics of the game from the visual representation.

I'm really leaning towards trying to implement my own version of this, and this is the perfect time to integrate it in. Anyone else thought of an idea like this before? 

Update 43: Rebooting again

As I said at the beginning of the project, "this is a personal project and there will be breaks..." Sometimes it was days. Sometimes weeks. Occasionally a month. This time it was a lot of months. However, one of the interesting things I found about this project is I never stopped thinking about it. Most of the delay was caused by work and family commitments, but everyday I thought about what I should be doing next... 

Today, I'm back with a new reboot, using some assets from a "Simple Military" unity package, made by a New Zealand company called Synty Studios.

This in combination with a new design idea, (Hovertank Wars is dead again), still based on turn based combat (and XCOM), but set in a new environment that drastically reduces the scope of the project. and I think makes it all possible. Over the past three (!!!) years I've now created a turn based system with pathfinding, a UI, a dynamic camera system with killcam, loading/saving, destructive environments, random levels and even a basic AI. 

It's time to take all of this and create a complete game. I look forward to (re-) starting this journey again!