Monday, August 14, 2017

Update 46: OpenTile

Two years can really fly by. Growing families, big work projects, small home projects, and as many distractions as you can throw at a sticky wall, here I am. I haven't been doing nothing, I just haven't been writing about it. I'm trying to change the not writing about things problem today.

One of those mini projects I've been working on is very relevant for this project. About a year and a half ago, I started a GitHub project I've called OpenTile. OpenTile is an opensource solution to create the building blocks and data structures for a tile based game. There is no UI, apart from the ASCII files, but it's being built in C#, with a branch for Unity3d. There is currently functionality for basic path finding, possible available tiles (for movement), cover, as well as a number of utility functions. 

I've found this framework really helpful for building a game. I'm able to focus on fundamental functionality such as path finding or cover in a simple ASCII UI, and then it's much easier to integrate the changes into a full 3d engine - with the confidence that it works.

In the screenshots below you can see two simple examples that show the output of path finding on a large map with varied obstacles.

In Unity3D, this is what the result looks like on a small test map:

Friday, October 16, 2015

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!

Friday, October 9, 2015

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? 

Monday, October 5, 2015

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!

Friday, April 3, 2015

Update 42: Unity 5 and Unity Cloud Builds

I knew I would vanish for a few months eventually - the Christmas break last year was apparently the trigger. I haven't posted for a while, but I started development again about a month ago when Unity 5 was released.

Along with this was a new cloud build system that works with GitHub

This is a pretty neat feature that allows me to automatically build and deploy web versions of my game.

This is big news for me as it means I have a more repeatable and independent process. I have a few more hours left to transfer over the content into my Unity 5 project, and then I'll start implementing some new features.

Friday, November 14, 2014

Update 41: Code Reorganization

This last week has been productive and I have almost completed path finding! This involved a complete reorganization of the code files to implement namespaces. The new structure really enabled me to connect all the pieces together so that I can now click around my levels, moving my units from side to side. My new namespace structure looks like this:



I debated having UI at the root level with "Main" and "Character" children, but ultimately decided that these UI elements would be completely different. The diagram below should what the code map looks like after the new reorganization:

I've also developed a process to implement new features in a safe and comprehensive way, using several levels of prototyping. This is similar to branching, which many software development processes use (but I do not). My process usually starts with an almost blank level. Once the feature has been implemented, I usually integrate my new feature up to one of my intermediate test levels, testing in a controlled environment with a 
few buttons to test movement and shooting. This is typically my 'tank test' level which has a few static objects and buttons to constrict movement, almost in a unit test sort of way for regression testing. The final step of my process is to integrate in the feature with my actual game levels. This means it can take a while for a new feature to make it into the game, but it's also a comfortable way for me to test new features and not put them into the main game until I am ready. 

I've been using this with path finding really successfully, which is why I'm confident I will have it complete by the end of November.

Finally, I have the bug of the month. In the top design view panel, you can see an in progress picture with a sample level. All of the red nodes indicate areas that are not-walkable, generated by my path finding. In the bottom game view panel , you can see that... I have no grass/ground. Where did my ground go? It turned out it was a relatively simple problem, my camera had turned off the option to show the ground, but it did create a few interesting levels...

Thursday, October 30, 2014

Update 40: Dynamic Pathfinding

The last two weeks have been focused on getting a basic dynamic path finding algorithm to work. This includes getting the object to follow the seeker path, and allowing for dynamic environments.

The first screenshot shows where I've been up until today. The path finding is 'baked' into the screen and there is a path from the beginning (green gate) to end (red gate).

The second screenshot shows me what it looks like with some dynamic objects added to the scene and dynamic 'baking'. Here I can see that my green path adjusted to avoid the new dynamic obstacles and created a new path to the end gate.

The ultimate test of this is to move the end gate to the other end of the screen. 

This is all good news. Now that my prototype is working, I can integrate the path finding within my game.