Update 24: Setting up a Build process

While I've been relatively quiet here, I have kept busy. I've used these last two weeks as a breather as I keep focused on a busy 6 weeks at work (6 deployments in 6 weeks) and work on a few infrastructure details. 

I had invested a fair amount of time setting up my project to check into the Visual Studio Team Services (VSTS) service and run a build to validate the code integration. This was more trouble than usual for a few reasons

1. Unity doesn't support VSTS integration, so I had to create a script to check out my files to an intermediate location, copy over the updated scripts and then check in my files again.
2. The build process isn't straight forward with the new Windows 8.1 preview service.

The results are promising, but it still doesn't *quite* work. Still, I know left this too long. Now that it's setup, every change I make is backed up, checked in, labeled with comments about the change and then built to ensure the change hasn't broken something else.

Next I'm working on a few minor changes to setup early path-finding and improve movement, as well as fixing some animation bugs. 

There is also a software release next week that will keep me busy (aka: distract me). 

Update 23: Alpha 1.6 - Lots of stuff finally released!

Alpha 1.6 has been released. This represents about 10 months of (part time) development, and is finally a little mini game. Admittedly a game without much depth, but still a game! Included in this release (since Alpha 1.5) are:

• New cameras
• Timing fixes all over
• A very basic AI
• New character models and animations
• More dynamic explosions
• Targeting indicators
• More advanced stress testing
• Links to the currently active test levels
• And lots of little bug fixes

This is all pretty exciting to me, and I've started working on a story/theme for the next step, while I also add in some feature requests and refine some of the mechanics a little.

Try it out for yourself and let me know what you think!

http://www.samsmithnz.com/content/tbe/tbe_alpha1.6.zip

Update 22: Alpha 1.59 - Cameras

I was so close to releasing Alpha 1.6, but at the last moment I had to postpone due to camera issues that forced me to spend an extra week rewriting the camera mechanics. I'm close, the camera now pans, rotates and zooms with just a few issues left on some of the camera position calculations for the AI.

It's all good though, the new characters look great and the AI is also progressing nicely. It's so close to a game now! I'm hoping to release Alpha 1.6 by Monday.

Update 21: Alpha 1.57 - Upgrading the character model

With the timing fixed, it was time to take the next step in implementing line of sight. 

An early line of sight mechanic highlighted how simple my character models were. As my characters are still just a single object (cylinder), cover effectively made my targets invisible if the one point of balance in the center of the cylinder was behind cover. It was time for me to develop my characters a little, to have multiple points (head, arms, body, etc).

Heading to my sketchpad again, I tried to design a simple model about the height and width, with arms, legs, a body and head.

The new model ends up looking a bit like this (with the old model to the left). It's a little silly looking, but is enough of a person for me to continue building the game engine.

What does he look like in a level? This is some basic animation I am using to aim at a target (The right arm is at 90 degrees - like I said "BASIC"). There is still a long way to go, but this is at least an upgrade from the cylinder.

Update 20: Alpha 1.56 - Timing

One of the biggest bugs in my code has been the timing of the camera movement, shooting and throwing. I've put off solving these problems for a variety of reasons, but with some early AI experiments, I found that it suddenly became essential to solve this immediately.

Fundamentally, the issues come from my usage of Coroutines, a Unity function that runs until it is finished. It's almost the same as creating a new thread. I use coroutines for my camera movement, shooting, throwing, and soon, for AI.

My game is simple, but still complex enough that I decided to create a separate  isolated test level to solve this problem. This little doodle shows my plan. I need two 'paddles', a ball to bounce back and forth, and the camera to switch between the two paddles between bounces. This functionality is all very similar to the way my camera follows a character taking their turn, and has them shoot/throw an object at an enemy.

With this design, my test looks like this:

I was able to easily try a few different tests, running through the 5 steps designed above, firing two projectiles instead of one, and really ensuring that the timing was working. I found that I could never get coroutines to wait. My bug was relatively simple (of course), and I've spent the last few hours actually refactoring the main branch of the code. Once this is working, I'll post about the AI.

Update 19: Alpha 1.55 - Targeting and More Dynamic Explosions

Continuing with my momentum, I've implemented a new mechanic based on some feedback I received. When the camera zooms in behind a player to shoot, it now shows a partially-transparent-targeting-indicator. It's now a little more obvious who you are aiming at, especially when there are a cluster of enemies close together.

I've also been working at creating more dynamic explosions. In Version 1.45 I had created a prefab that contained little blocks. When the prefab was hit, I'd basically pull down the wall and let the little blocks explode. While effective, I found that when I scaled up from a 10x10 level to a larger 30x30 tile level, that the prefabs and all those little blocks really hit the frame rate pretty hard. 

To solve this, I wrote a little class that divides the parent object into a series of smaller cubes - created when I need them. Then instead of a million little cubes buried in my level, the cubes aren't created until they are needed.

Here is a sample before:

And after: 

Next on the list is some timing and camera improvements.

Update 18: Alpha 1.5 - Finally Moving...

I finally have my characters moving. If you know me and have talked to me about this project, this has been a significant barrier for the duration of the project to date. I've tried multiple path finding algorithms and methods to move my characters, mostly with pretty horrific (lack of) results.

Today that changed. 

It's simple, but it involves two pretty important mechanics. 

1. A simple tile based system that highlights possible moves. This creates the 'sectors' my game needs, but still gives me the flexibility to not be tied to these tiles. 
2. The ability for me to click on the highlighted tile and actually move the current character to that position.

The test level below shows both mechanics at work, but in the final game, the red grid will not be visible.

You can download the Alpha 1.5 version here: http://www.samsmithnz.com/content/tbe/tbe_alpha1.5.zip. Also included in this build are links to some of my test levels, where I develop and validate mechanics in isolation, the explosions from 1.45 and some more bug fixes. 

As well as this, I'm still continuing to improve dynamically exploding walls, setting up the final milestones for the complete Alpha demo, starting to develop a theme/story and finalizing a few other details. So what is left? I have 5 items that I'm currently working through in various stages, and 8 more items that I have not yet started. (This neat chart was produced by Visual Studio's free and online version of Team Foundation Server).

Update 17: Alpha 1.45 - Explosive Walls

I've been working on destructive terrain, and I decided the best way to blow up something, is to build it up first, literally brick by brick. As my current walls were just a (1,0.5,0.1) sized wall, I figured I should build it with 50 individual bricks into a prefab. Then when I apply force to it, it will spray across the screen in 50 pieces not one!

My first hurtle was that when I applied the rigid body property to all of the bricks, the wall tended to wobble like jelly (Jello for you Americans). I was able to solve this by not applying my RigidBody component (to enable physics) until the explosive force was applied. It actually turned out to be easier to apply this component to items in the blast radius rather than every single item on the screen. It's probably cheaper, (resource wise), too!

Next it was time to stack a few of these prefabs on top of each other, and then apply an explosive force to a random point in front of the wall... the resultant explosion was... unexpected. I'm still not sure why the explosion is along the z plane...

Moving on, applying the new prefab to my test level, it gives a far more satisfying burst across the screen when I throw grenades.

There is no download for this, I'm still adding some the next feature... which is visible in that last screenshot...

Update 16: Alpha 1.4: Throwing

In the last few Alpha releases, I've been focusing on stabilizing the camera and shooting mechanics. I feel much better about how it all looks, especially the camera movement, with all bugs around the camera now addressed.

Although I have a few timing issues with the shooting still to solve, I've moved on to the next type of attack, throwing grenades. I started by working through the physics and showing the trajectory. 

With the help of two very important links:

1. Some excellent theory from the Castle Story: http://www.sauropodstudio.com/dev-diary-number-eight/
2. A script to draw the line from Unity3D wiki: http://wiki.unity3d.com/index.php/Trajectory_Simulation

Using this, I was able to calculate the distance to the target, based on a fixed angle of 45 degrees: this meant that I can throw my grenade in a nice parabolic curve towards the target. 

Here are two screen shots showing this in action in my test level, with the red line replaced by a trail of smoke: 

Just before the grenade hits...

Just after the grenade hits...

When my grenade collides against my target, it 'explodes'. At the moment it's just an expanding red sphere - particle effects to come later. I use the Physics.OverlapSphere() function to look for items within a certain radius:

Collider[] hits = Physics.OverlapSphere(myProjectile.transform.position, explosionRadius);


If any of my collider hits are a player, I deal damage, but if it's destructible terrain, I use the AddExplosionForce() function like this:

//If destructible terrain was hit, destroy it
if (hit.collider.tag == "DestructibleTerrain") 
{
    //Add Rigidbody to terrain/wall
    hit.transform.gameObject.AddComponent<Rigidbody>();
    
    //Add explosive force at the point of the projectile impact
    hit.transform.rigidbody.AddExplosionForce(explosionForce, myProjectile.transform.position, explosionRadius);
}

This has two effects: it removes the destructible terrain from the explosion area, and it propels the same terrain across the map, which I think is pretty cool...

You can download version Alpha 1.4 here: http://www.samsmithnz.com/content/tbe/tbe_alpha1.4.zip.

Update 15: Alpha 1.3

Alpha 1.3 is released. This fixes all of the bugs in the previous two versions, as well as replaces the laser with a real projectile. Also fixed are all of the targeting icons in the GUI, tabbing between enemies and targets and a few camera issues.

Still outstanding are a few camera issues and the shooting timing still isn’t quite right. This holiday has been quite productive.

[Link removed to upload the newer and better Alpha 1.4]

Update 14: Alpha 1.1

Alpha 1.1, that doesn't crash (nearly as much), is released. There are still lots of camera and timing issues, which I am slowly crushing.

[Link removed to upload the newer and better Alpha 1.3]

Update 13: Alpha 1.0

After an extended summer break, I've picked back up where I left things in June. I now have my first, very basic vertical slice of a basic tactical warfare game. There is still no player movement, but I do have cover and shooting. Everyone has a 75% chance of hitting. The player has slightly more health to give him a better chance of sticking around. 

Most importantly, I have a build that works from beginning to end. The players take turns, and if the game doesn't crash, the last team standing wins! 

There are bugs, especially when characters die, sometimes the game gets stuck and crashes.

[Link removed to upload the newer and better Alpha 1.1]

Update 12: UnityVS - Adding Productivity

I've purchased my first tool to assist me in my game creation, UnityVS. This productivity tool will really help me with my debugging, enabling me to set breakpoints. With this, I should be able to move forward quickly


Here is a quick video of the camera I've been working on animating, transitioning between different states. 

Update 11: Chipping away at the basic game

It's been a busy few months for me as I had a new baby girl, kicked off two major projects at work and worked on a variety of outside spring projects in the backyard.

I have still been chipping away, converting my characters into Unity Prefabs, working with selecting objects on clicks and finally, getting the first, very basic turns working. It's always two steps forward and then one step back. Fixing a shooting bug introduces a camera bug, which when fixed creates a UI bug.  

Tonight was typical. I rewrote the shooting mechanics, everything looked good, I fired it up, and then.... nothing. One of the downfalls of game development is that a lot of the debugging tools are still behind that of most web applications. I did figure out the issue, but my code is riddled with Debug.Log statements that track my progress.

It is coming along. Here are 4 screen shots that for the first time are beginning to show the basic workflow. Please ignore the obvious clipping and camera issues.

Turn 1 Player: The isometric camera scrolls to center over the player. The player can see two targets (ninjas). Clicking on these centers the isometric camera over the enemies.

Turn 1 Player Shooting: the player then presses/enables the shooting button, which switches to the player cam view. Here the player has 3 options. 1, shoot the current target. 2. using Tab, switch between the other targets. 3. Press escape and go back to the first screenshot.

Turn 2 Enemy. After the player has show, it's the enemy turn. The same rules apply as turn 1, but now it's the enemy. Note that I now appear in the enemy/target list on the bottom right

Turn 2 Enemy Shooting: Ditto, but with the enemy again.

Update 10: Updating the Camera

It became clear to me very quickly that my camera in the isometric view looked a little cheap. Looking at how XCOM implements their camera, I noticed that they did actually use a perspective view, but at an isometric height. Today I switched to a perspective view, which I think really improves things.

I also added a 'killcam', which is a camera directly behind my player. When I shoot at enemies, it now switches to the camera so that you can watch the kill shot and then back again. Pretty simple stuff really, but very effective.

Update 9: Destructible Terrain

As I worked through the shooting mechanics and really got ray casting to work properly, I suddenly found that I couldn't shoot my enemies. I was initially perplexed, but then quickly realized that everything was working perfectly: the shot was hitting the cover (wall) in front of the target. 

It was time to implement destructible terrain.  

Part 1: I aim an the enemy on the far right. He happens to be under cover, so my shot hits the wall in front of him.

Part 2: The wall currently only has a HP of 1, and my laser does 1 HP of damage, so the wall is destroyed. With the wall gone, the enemy is exposed and can be hit easily. In the current prototype, characters have 3 HP, so just 3 more hits from the laser and he will be dead!

Update 8: Randomizing the shooting and adding health (and death)

Now that I had a basic level with shooting from point A to point B, I needed to add some randomization. I personally don't like games of attrition, I prefer games of skill, with some luck.

Enter the random number generator. Basically I pass in 2 numbers, a chance to hit percentage, and a random percentage  The two numbers are compared, if it's a hit, no problem, if it's a miss, I created some random variation so that the shot misses and goes off into the distance.

I spent a bit of time trying to create a random shot until I discovered the Random.insideUnitCircle function. Basically I can multiply a variable against it to have it select a random position around my target, which I then just add to my target position.

Finally, to get everything working, I decided to create a test level. I setup a target, with a wall behind it. It works pretty well and is another item I can cross off the list.

Update 7: Pathfinding

I need to be able make my players move from point A to point B, avoiding any objects on the way. This is basic pathfinding. Pathfinding is one of those simple features that seems to be difficult to do properly. There are plenty of games that just don't quite get it right. Taking this into account, I knew I wouldn't be writing mine from scratch.

I analyzed a number of different tools, before selecting the A* Pathfinding Project. I found this project both really simple to use... and difficult to use. The primary problem I was having was that my character was stopping half way towards his destination. The sample wasn't quite right and I pulled my hair out for a few days, still unable to get it to work. 

I added in some basic movement, but my player kept hitting walls and falling over (shown below). While hilarious, it wasn't the result I was looking for. It turned out to be a physics problem. While my pathfinding is not complete, I was a good introduction and I did have some positive results (not shown below).

Update 6: Shooting

With a basic level, it was time to work on shooting. First things first, I had to get rid of the soldier model I downloaded. Instead, I transitioned to a simple, blue cylinder, my player object. I then created a few red cylinders to represent my enemy objects. 

Next, it was time to actually shoot. I started with a laser, mostly because instead of having to deal with an object moving from point A to point B, I really just have to draw a line. Later I'll work on getting animated bullets and missiles to be fired. Creating the laser, with a line renderer, was refreshingly easy to setup.  

With a laser, a source and a target, I was ready to shoot! I created a little function that scanned the level looking for objects of a certain tag type ("Enemy"), and used that to dynamically create shoot buttons, to target each enemy.

Update 5: Starting the Engine Prototype

With a basic plan, and some knowledge of the Unity Development Engine courtesy of some online training programs, a few books (see references at the bottom of the post) and some videos, I'm ready to start the engine prototype. The goal of this prototype is to have a basic turn based game. No fancy effects, just a 3D map, with player and enemy objects that can move and shoot each other.

With this is mind, I created a short work plan with a list of tasks that would have me building the prototype in a few months. I know that much of what I will be developing will be brand new and slow. Shooting, moving, path finding, object selection, map building: it's all going to be a new adventure. 

So far, I've been able to replicate the same basic prototype level I created in Google Sketch-up and added a camera to examine the level. I wasn't 100% happy with the result, but I also had to look back at it and say “it’s OK, lets look at this more later”. It just seemed to me that I started with this powerful graphics engine and made things look so… BUDGET, by making it into an isometric view. I can see myself definitely going back to a Perspective view soon.

But lets look at the positives. I created a level. I added a camera that could scroll and move. I then downloaded a free model that had WASD movement (with keys) built in. It even shoots... It was progress. Next I'm going to add some enemies and some basic shooting.

The 3 books I referenced are:

Game Coding Complete, 4th Edition

Unity 3.x Game Development Essentials

Game Development with Unity

Update 4: Pre-Production

Although it sounds like I've just started, in actual fact, I've been working on this game for the last year. I started by doing market research into 4 of my favorite games in the genre, as well as general information about the video game market in general. I've collecting feedback from online forums and created lists of what worked well and what didn't  The announcement at the beginning of this year of XCOM: Enemy Unknown by Firaxis was an interesting development, as I could tell from a lot of interviews that they went through the same process. I was also excited with the innovations they made with the turn-based tactical role-playing strategy video game genre. With an renewed active community in one place, I was able to collect extra information about what did and didn't work in the original 1994 XCom.

Based on this, I then looked back at the last 30 years, looking for trends. My initial idea was to create a zombie apocalypse game for a few reasons.
1.    This was my first game and I wasn't sure I could build a good AI. Having zombies would help with that.
2.    Zombies seemed like a popular area to develop for.

Over the period of the year, this all changed. Suddenly zombies seemed to have reached a saturation point. I kept telling myself that the story didn't matter at this stage until I had an engine, but half of me was conflicted, knowing that if I didn't know exactly what I would build, I would not have a sense of accomplishment (e.g. I've completed 20% of the game!).

In the end I came up with a few alternatives, all wildly different.
1.    American Revolution. Muskets and Indians and such. The slow pace of muskets would be ideal for a turn based game.
2.    Space Marines. Set a few hundred years in the future, with aliens (very similar to the Chrysalids who I think are fantastic and one of the most interesting units in the game) and space travel. Think a combination of Starship Troopers/ Aliens.

I’m torn on direction, but as I mentioned earlier, at this stage of the development, I have plenty of time to still to decide.

Here is what I know
1.    I need a basic engine that will allow me to load levels, move characters and attack other characters. I need (at least partial) destructible terrain.
2.    Once I have this, I can start putting together a story and levels to support the story, as well as a simple 'strategic layer to create story around each of the battles.
3.    The idea is to create 3-5 levels into a short, tech demo. I could even call it “Episode 1”. The Walking Dead recently handled Episodes very well. The tech demo will be very linear from the over story point of view, but of course the tactical game will have plenty of choices which I hope will balance things out a little.

Based on this, I started to design a few tech demo levels in Google Sketch up, an excellent tool I had used in the past. The idea of my first level was to show multiple levels, allowing me to build in destructible terrain, cover, and path finding into the initial level.