Friday, April 25, 2014

Update 32: Decaying objects

I wrote a class today that I add to components I want to remove from the game (for example, my destructed walls). 

I add it to a gameobject like this: (where character is a gameObject)

            character.AddComponent<DynamicExplosionPiece>();

In the "Awake" method of this class, it randomly generates a number between 0 and 10, which is the number of seconds in the game before the object dies. What this means, is when I create 100 little objects for my destructed object, the game cleans them up after 10 seconds - at the most!. Because it's random, it has a decay effect. Here is a screenshot, of a recently dead enemy (red) tank. The turret has decayed, the cannon has not, and about 25% of the square body has decayed.



The actual class is here:

using UnityEngine;
using System.Collections;

public class DynamicExplosionPiece : MonoBehaviour
{
    void Awake()
    {
        StartCoroutine(StartTimerBeforeDestruction(Utility.GenerateRandomNumber(0, 10)));
    }

    private IEnumerator StartTimerBeforeDestruction(float time)
    {
        yield return StartCoroutine(Wait(time));
        Destroy(this.gameObject);
    }

    private IEnumerator Wait(float time)
    {
        yield return new WaitForSeconds(time);
    }
}

Sunday, April 20, 2014

Update 31: Narrowing in on the game design: "Hovertank Wars"

Things are coming together nicely after an extended break from posting here.

I've had a positive look at the scope of my project and make a few changes to simplify what I'm trying to achieve. As a result, I've spent the last few months rewriting the design document and refactoring the code to create a new spin I am calling: "Hovertank Wars". Instead of soldiers, I will now have these hovertanks. Here is a screenshot of the test level I created to animate and test the new model:




I have a rotating tank, with pivoting turret and cannon. It fires explosive bullets:



I'm now refactoring the levels to use a new scale appropriate to these tanks as well as building a new campaign. 

Friday, February 14, 2014

Update 30: Line of Sight

I've managed to implement a simple line of sight mechanic with ray casting. If my character can't see an enemy - because they are behind another object and therefore, not in 'line of sight' of my character, I hide the mesh renderer on the object, effectively making it invisible. 




The great part about this solution is that the enemy character is still there and it's AI is still running. When the enemy character comes back into view again, I just enable the mesh renderer. Every time a character moves, I ray cast between each character and enemy to see if they are visible and then hide and show the enemy character depending on if they are in the line of sight of my player.

Here is a sample where I can't see the enemy (although, because I haven't yet replaced the UI of the enemy characters, you can see their health bars - this will be fixed later):




And here, after I move around the obstacle, I can see the enemy character again.



Monday, January 27, 2014

Update 29: Random Levels - Part 3

With the theory done and a solid prototype, it was time to implement the more advanced level creation into the main engine. I started by implementing the 6 tiles I needed, a vertical, horizontal, and the 4 turn pieces. I considered refactoring the pieces so that there were just two tiles and then rotate them to fit, but I realized it would be better to create the extra variation. Here is a screenshot all 12 tiles available now:



I moved my prototype code over to the main engine, replaced a few lines of code that were specific to the console app and generated my first dynamic level with a river.



With that working, I brought in the rest of the tiles (the previous screenshot was just river and a blank tile). The following two screenshots show two random maps with more of the pieces.





I can't begin to explain what a giant leap forward this is for me.

Sunday, January 26, 2014

Update 28: Random Levels - Part 2

Happy with my new random levels, I quickly discovered that some of my map combinations didn't make much sense, especially when rivers or roads were involved. In the sample below, you can see two river tiles are connected with a tile with no river - it just doesn't look right.



To make better maps, I needed to a river/road to start on one edge and finish on the opposite edge. I started a prototype to solve the problem, migrating over a few level data structures from my game - fortunately my design and structures were generic enough to allow this. My initial plan was to take my level area, draw a continuous river/road across the level, and then fill in the blank tiles with random tiles. To work through this, I created a simple console application to output ASCII, using these tiles as samples:

╔0══╗╔1|═╗╔2══╗╔3|═╗╔4|═╗╔5══╗╔6══╗
║   ║║ | ║─────║ └────┘ ║──┐ ║║ ┌──
╚═══╝╚═|═╝╚═══╝╚═══╝╚═══╝╚═|═╝╚═|═╝

With the templates in place, I started work on the tiles. The first level, running my current level creation algorithm, looked like this, again highlighting how ridiculous this all looks:



Next, I went to work drawing the river first, and then filling in the remaining tiles. This wasn't too difficult, starting with a simple (3x3 level): 



...and scaled nicely, getting more complex quickly (8x8 level):



Finally, I adjusted the path-finding of the river, so that it wouldn't drop back on itself. Essentially, if I start from the left, let my river go up, down and right, but never backwards (left). The output looks like this:



This is exactly the result I was looking for. Additionally, it scales up easily, I ran some 100x100 samples in less than a second.  The next phase is to recreate these tiles in my game, the next post will be about this process. If you'd like to play with the prototype, I've posted the level creation tool online here.

Saturday, January 11, 2014

Update 27: Random Levels - Part 1

After scaling up my levels and populating them with the new assets, I went to work creating randomized levels. The original xcom had 10x10 tiles that were randomly added to a level to create a 100x100 sized level. This worked very well to create a new experience in every level, even though the buildings were often recognizable.



I've only created four 10x10 tiles so far, but I've made them all prefabs. In the screenshots below, you can see two of the prefabs highlighted. Note that this is only a 20x20 level, with only 4 tiles of 10x10 each. 




Now when I load a level I am able to randomly choose, arrange and rotate these tiles to create a random level. This is a huge step forward for my project. By creating 10x10 prefabs with content in the center, I can really create some interesting levels. Here are a few more samples:




This last sample is a 30x30 sample (9 tiles total) from a five tile set (one of the tiles is blank):

Thursday, January 9, 2014

Update 26: Scale Issues

I recently bought a group of assets from the asset store to help make my prototypes look better. It's pretty exciting, even though these are only two colors (yellow and gray).



As with most implementations, you have to laugh when you see the first result. Here, I realized my scale was a little out. WAY out. Here is a screenshot of my level with some of the new assets, a bridge, palm tree and ladder. Fortunately, it looks like scaling everything by 10 is about right, as you can see my character looks to scale standing on the bridge.



If you'd like to see more about the assets I downloaded, you can watch this video: