Adventures in Unity – 1.4b Tighten & Tidy

Official_unity_logo

 

There were a few sections of code I added during the ‘tighten & Tidy’ process that I thought I’ve cover in a little more detail; Collision detection, jumping & platform generation.

 


 

Collision Detection

One of the problems with the code prior to the update, was that a player was able to jump whenever they wanted – whether they were rolling along a platform or already in mid-air. This allowed players to potentially ‘fly’ though the game – even jumping up, safely outside the screen\gamer area.

It seemed more sensible if the player could only jump when they were ‘on’ the platform – A ground level from which they could jump – No jumping in mid-air and no jumping if they fall between platforms.

I cheated a little with the solution – Rather than creating a universal collision detection test, I relied on the idea that platforms implemented used non-rotated/rotating box colliders.

I created a C# script called ‘platform.cs‘ which is attached to the platform prefab.

I check ‘OnCollisionEnter‘ & ‘OnCollisionStay‘ – ‘OnCollisionStay‘ is used for situations where the player-platform collision occurs/registers first against the side of the platform rather than the top.

The collision check itself first confirms that the ‘player‘ component is being tested for collision;

if (collision.gameObject.CompareTag("Player"))

if that is the case, it then checks to see if the collision has occurring against the top of the cube;

if (collision.contacts[0].normal == -(transform.up))

If all these conditions are met,  the player component is referenced directly and the players static bool ‘grounded‘ is set to true (allowing jumps to be performed).

Also at this point we check the platforms colour, if it’s set to white (it’s original colour) – We change it to something a little brighter. If the colour is still set, we keep things as they are (to avoid flashing cubes)

& that’s it – Unity’s built in physics engine does the hard work of keeping the objects apart.

void PerformCollisionCheck(Collision collision){

     //Ensure we are checking aginst the player.
     if (collision.gameObject.CompareTag("Player")){

          //---

          //If the top of the cube is being hit
          if (collision.contacts[0].normal == -(transform.up)) {

               //Grab the player
               Player player = collision.gameObject.GetComponent(); 

               //Set 'grounded' to true (so the player can jump again)
               player.grounded = true; 

               Renderer rend = GetComponent();

               //If the cubes colour hasn't already been set
               if (rend.material.GetColor("_Color") == Color.white) {

                    //Change it from white
                    Color whichColour = WhichColour(); 
                    rend.material.SetColor("_Color", whichColour);
                    rend.material.SetColor("_SpecColor", whichColour);
                    rend.material.SetColor("_EmissionColor", whichColour);
                    rend.material.SetColor("_ReflectColor", whichColour);

                    //Update the players score.
                    gameController.AddScore(GetColor()); 

               }
          }

     //---

     }

 }

 


 

Jumping

The original jump code was taken from the Unity Basic Platform Game tutorial. It’s pretty straight forward, and it does a good job.

Update‘ method checks for user input;

if (!GameController.inGame)
     rb.transform.position = new Vector3(0, 11, 0);
else if (grounded && Input.GetButtonDown("Jump")){
     jump = true;
     grounded = false;
}

If so, the ‘FixedUpdate‘ method applies force to the ‘rigidbody‘ – performing the actual ‘jump’;

if (jump)
{
    velocityY = JumpLaunchVelocity * (1.0f - Mathf.Pow(jumpTime / MaxJumpTime, JumpControlPower));
            
    rb.AddForce(new Vector3(0f, jumpForce, 0f));
    jump = false;
}

This worked well – Certainly well enough that I may reimplement it by the time this game is finished.

The problem is, platforms have random heights & widths – & using a static jump size sometimes made the game feel a little unfair – Some ‘game over’ screens felt undeserved.

Instead I thought I’d try allowing the player to control their jump a little more. The longer the player holds down the jump button – The higher they jump.

This, I hoped, would allow a greater deal of control for the player & making the game a little more skill based & putting the reason for the ‘game over’ back in their court.

I wrote a game for the Xbox 360 a year or two back called Magic Thighs & Slightly Phil – A Bomb Jack clone which implemented this kind jump system.

So, rather than reinvent the wheel, I used a modified (simplified) version of the code for this project.

 

The updated jump code follows the same structure as the original jump code; the update function checks for user input;

if (GameController.gameState != GameController.GameState.InGame)
    rb.transform.position = new Vector3(0, 11, 0); //Set game init position

else
{

    //---

    isJumping = false;

    if (Input.GetButtonDown("Jump") || Input.GetButton("Jump"))
        isJumping = true;

    //---

}

While the ‘FixedUpdate‘ method applies force to the ‘rigidbody

Though the jump code is now a little more complex (though still pretty simple).

With this jump code, we use a timer. When the player initially presses jump, the timer is started.

if ((!wasJumping && grounded) || jumpTime > 0.0f)
{
     jumpTime += Time.deltaTime;
 }

While the timer is running we apply force to the player objects ‘rigidbody

velocityY = JumpLaunchVelocity * (1.0f - Mathf.Pow(jumpTime / MaxJumpTime, JumpControlPower));                 

rb.AddForce(new Vector3(0f, velocityY, 0f));

Once the timer reaches a predefined ‘MaxJumpTime‘ or the player releases the jump button, we stop applying velocity to the ‘rigidbody‘ and don’t allow the player to try jumping again until he hits the ground/platform top

if (isJumping)
{

    if ((!wasJumping && grounded) || jumpTime > 0.0f)
    {
        jumpTime += Time.deltaTime;
    }

    // If we are in the ascent of the jump
    if (0.0f < jumpTime && jumpTime  jumpForce)
        {
            velocityY = jumpForce;
        }

        rb.AddForce(new Vector3(0f, velocityY, 0f));

    }

    else // Reached the apex of the jump
    {
        jumpTime = 0.0f;
    }

}

else // Continues not jumping or cancels a jump in progress
{
    jumpTime = 0.0f;
}

wasJumping = isJumping;

 

It’s not perfect, but, for now at least, it does the job.

 


 

Platform Generation

I’m intending to play around with platform a little before this game is complete, so for the moment I’ve kept things pretty simple.

The idea is I need each platform to be a different height – Not so different that the player cant jump onto it – But not so similar that the game doesn’t present a challenge.

I populate the level with platforms (from left to right) – Using a ‘farLeft‘/’farRight‘ variables to determine desired start and end ‘X‘ positions.

Every game loop I scroll the platforms left a little – Removing the platforms whose ‘X‘ position is < 'farLeft‘ – Adding platforms until the ‘X‘ position of right most platform  reaches (or exceeds) ‘farRight‘.

private void PopulatePlatforms()
{

    float posX = farLeft;
    if (platforms.Count <= 0)
        initalPlatform();

    //---

    //Find the X psition of the last platform in the list (furthest right)
    posX = (platforms[platforms.Count - 1].transform.position.x + (platforms[platforms.Count - 1].transform.localScale.x / 2)) + 1;

    //If we don't have enough platofrms to fill the screen - we need to add some
    while (posX < farRight)
    {

        float width = Random.Range(widthMin, widthMax); //randomise platform width
        float height = NextHeight(); //Find platforms height

        posX += width / 2; //Find the relevent X pos for the new platform.

        //Combine and define the final position
        Vector3 position = new Vector3(posX, basePosition + (height / 2), 0); 

        //Combine and define the final scale
        Vector3 scale = new Vector3(width, height, 10); 

        //---

        //Add the platform
        platforms.Add(Instantiate(platform, position, Quaternion.identity) as GameObject);
        platforms[platforms.Count - 1].transform.position = position;
        platforms[platforms.Count - 1].transform.localScale = scale;

        //Update the X pos so the while loop to chack (+1 to add a space between platforms)
        posX += (width / 2) + 1; 

    };

}

When adding a new platform I randomise the platforms width (within a range) – Use the ‘NextHeight‘ method to determine it’s height.

NextHeight‘ initaly sets the height of the new platform to match that of the last platform.

It them applies a random value to the height (within a range). This range is between -‘heightRangeMax‘ and +’heightRangeMax

height = lastHeight + Random.Range(-heightRangeMax, heightRangeMax);

heightRangeMax‘ represents the largest difference in height between platforms that a player can still be expected to jump up to.

(Note: The minimum range could really be any height, since falling isn’t a problem, for for now this seems more succinct).

After generating the platforms height, which we ensure the platform stays within the acceptable maximum and minimum height for the play area/screen.

        if (height > heightMax)
            height = heightMax;
        else if (height < heightMin)
            height = heightMin;

We make sure to the difference in height between the last platform and the new platform is suitably large.

while (Mathf.Abs(height - lastHeight) <= heightRangeMin)

& If everything looks good, we update the ‘lastHeight‘ variable with this platforms height and return to ‘PopulatePlatforms‘.

float NextHeight()
{

    float height = 0;

    do
    {

        //Randomise a height for the new platform
        height = lastHeight + Random.Range(-heightRangeMax, heightRangeMax);

        //Ensure the height isn't too large or too small
        if (height > heightMax)
            height = heightMax;
        else if (height < heightMin)
            height = heightMin;

    } while (Mathf.Abs(height - lastHeight) <= heightRangeMin); //Check the height difference is at least equal to the minimum acceptable size difference.

    lastHeight = height; //Save height to last height so the next platform has something to measure against.

    return height;
}

 


 

There;s lots more to tweaks with this code still to go – The player jump feels a little sluggish & the size difference between platforms is still a little small.

But I can tweak these as things go on.

Next I’m going to try to add a little audio to the game.

(I’ve absolutely been relying far too much on the ‘energetic‘ tune from Microsoft’s ‘MovieMoments‘ app to keep things sounding interesting).

 


Play the game (WebGL)

Grab a copy of the project here


 

 


 

Next post: 1.5 Initial Audio

Last post: 1.4a Tighten & Tidy

Contents page.

 


 

Advertisements

Adventures in Unity – 1.4a Tighten & Tidy

Official_unity_logo

 

This probably isn’t the most professional approach to development.

But what I tend to do, every so often, is to stop expanding the game (adding new functionality & features) and spend a little time refining what I have – Both in how the game works & looks, and in how the code is structured.

Note: I only really do this on games – such as this one – where I’ve started with no specific goal, endpoint or design in place – Just a general idea of what I’m trying to put together.

By refining I mean;

  1. Making changes which don’t require much (or any) code amendment, but do take a little time to refine (e.g. trying out different fonts for the GSM font or changing game scroll speed).
  2. Making small refinements to existing code which has a large impact overall (e.g. Making the players score based on a timer instead of a frame count).
  3. Tidying the code a little – removing anything that’s no longer required, updating whatever remains.

 

This allows me to keep control of the code as functionality expands and ideas/implementations change and are refined.

It also helps me try out new ideas – which I can test out and tighten as development continues – even remove altogether if I decide I’m going down the wrong path.

 


 

Reorganised GSM UI – Used tank font & expanded GSM text

Added materials (textures) to platforms and player (gem & rock) – Trying out new looks.
Removed materials – None of the new looks seemed to work.

Updated collision – Platforms are just Unity cubes; Checking that the player has hit the top face allows;
Player can now only jump when on the ground – removing the Flappy Bird style controls.
Change platform colour on collision – Trying keep things visually interesting without using materials/textures.
Added platform collision count – Whenever the player lands on a platform (hits the top face of the platform – a point is added – Currently used to increase scroll speed.

Changed score to display a timer & the platform collision count – Not the final score set-up; trying to figure out what info I need to see.

Changed camera position & rotation – Ensures the players block position is always clear.

Locked players Z position – To stop the player cube from bouncing off into the distance.
Tightened off screen check – It took too long, after the player moved out of play for the game over screen to show.

Updated controls – Space or mouse click are used to control the player and start new games.
Updated controls – The longer the space bar/mouse button is held down, the higher the player jumps. Using a modified version of the jump code from Magic Thighs & Slightly Phil.

Ensured platforms vary in height – Platforms are now guaranteed to be different heights (but not so different that the player cant jump between them).
Game increases in speed over time – Increasing game difficulty the better it’s played.

 


 

This isn’t supposed to represent the code in it’s final form –  But it helps me keep a handle on the state of all aspects of the project.

There are still plenty of issues with the code as is (for example there are lots of times when the game starts the player falls directly between platforms), and lots of features that I need to add – Hopefully after tidying and tightening the code, I’m in a better position moving forward.

 


Play the game (WebGL)

Grab a copy of the project here


 

 


 

Next post: 1.4b Tighten & Tidy

Last post: 1.3 Initial GSM

Contents page.

 


 

Adventures in Unity – 1.3 Initial GSM

Official_unity_logo

 

#1 What would I ideally like to achieve by the time I finish working today – Build a basic GSM incorporating a title and game over screen, displaying players score. Allowing games to end and be restarted.

#2 What’s the minimum I’d like to achieve by the close of play – Build a basic GSM incorporating a game over screen, displaying players score. Allowing games to end and be restarted.

 


 

With the game in it’s current state, there’s still a lot of work to do – I decided, for the moment, to stop developing the game-play and work on the GSM instead.

This was partly because I think the game itself is getting some shape (even with such little actual code in place), whereas the GSM & how I was going to implement it was still very much undefined in mind.

It was also partly because when testing the game I didn’t want to have to keep stopping & starting the test environment every time the player went off screen – It’s gets old fast.

Partly because it helps give the game some structure to work from.

& finally because the GSM is, for me, often the least interesting part of the game to develop, it’s easy to overlook, but is very important for giving players a sense/feel about the product as a whole.

 


 

My most recent experience building GSM’s comes from developing Xbox 360 indie titles. In that environment I used ‘screen-managers’.

XNA GSM Sample code

Explanation from XNA;

The ScreenManager class is a reusable component that maintains a stack of one or more GameScreen instances. It coordinates the transitions from one screen to another, and takes care of routing user input to whichever screen is on top of the stack.

Each screen class (including the actual gameplay, which is just another screen) derives from GameScreen. This provides Update, HandleInput, and Draw methods, plus some logic for managing the transition state. GameScreen doesn't actually implement any transition rendering effects, however: it merely provides information such as "you are currently 30% of the way through transitioning off," leaving it up to the derived screen classes to do something sensible with that information in their drawing code. This makes it easy for screens to implement different visual effects on top of the same underlying transition infrastructure.

This is very different to the way the GSM’s are handled in the Unity tutorials – Notably the ‘tanks‘ and ‘space shooter‘ sample code.

I figured I could replicate the XNA screenmanager GSM framework by using separate scenes instead of separate screens – Simple to implement and fairly clean.

But I figure part of the point of learning is to try something new, so I’ve used the  ‘tanks‘ and ‘space shooter‘ set-up for the GSM – If it works, hooray – If not, at I’ll know 🙂

 


 

Initially I pretty much ripped the ‘space shooter‘ GSM code wholesale.

It’s a nice simple set-up, easily replicable & I thought I could plug it in fairly easily…

I created an empty game object – called it ‘GameController‘ added a new C# script (also called ‘GameController’) – Into the script, I pulled over the relevant score, restart and game over code.

I added a UI-Text component, played with it a little, but as a rule I just replicated the settings from the ‘space shooter‘ game – Plugged these text components into ‘GameController‘ script, allowing it to handle when to display what text.

In the game itself, I needed to identify when it was game over – Since I’m just trying to set things up, I decided to keep things simple – If the players cube is at position -11 on either the X or Y coordinate (outside the screen to the left, or bottom)- Then it’s game over.

To make sure ‘GameController‘ reacted to the game over state – I created a global static bool called InGame – If InGame is true, game is running, if InGame is false then display the ‘Game Over text.

I added a little extra code to the player and platforms scripts – Ensuring they only updated when InGame was true.

But otherwise, that was pretty much it – It took a little smoothing, but it worked quite nicely.

 


 

The problem was, it was only a game over screen – At the moment, when the game starts running, it throws the player immediately into the game – Which I felt would be very confusing and a little off-putting for someone who’d just started the game up – I needed a title screen.

Again, I wanted something simple that played nicely with the modified ‘space shooter‘ ‘GameController‘ code.

Following the code in place;

When the game initially starts/loads InGame is set to false this ensures text is displayed and the player isn’t thrown, unexpectedly into the action.

Since the game has only just loaded, it seems a little rude to display the ‘Game Over‘ screen straight away.

I added an extra text field to hold the games title – currently called ‘TEST GAME‘ – Linked this into the ‘GameController‘ code.

I needed to figure out when to display the game title and when to display game over –

This I fudged – Given the interface I’d decided to work with, I wasn’t too sure of the best approach.

Creating a static bool called ‘counter‘ (originally it was an int, after updating I forgot to change the name). If counter == true then the games title text is displayed, if counter == false, then the game over text is displayed. By making the bool static, it keeps it’s value even after ‘SceneManager.LoadScene‘ is called.

 


 

Full ‘GameController‘ code;

using UnityEngine;
using UnityEngine.UI;
using System.Collections;
using UnityEngine.SceneManagement;
public class GameController : MonoBehaviour
{
     //---
     //---
     public static bool inGame;
     private float scoreActual;
     private int scoreDisplay;
     public Text scoreText;
     private bool restart;
     public Text restartText;
     private bool gameover;
     public Text gameoverText;
     private bool title;
     public Text titleText;
     public static bool counter = true;

     //---
     //---
     // Use this for initialization
     void Start()
     {
          scoreActual = 0;
          scoreDisplay = 0;
          UpdateScore();
          gameover = false;
          gameoverText.text = "";
          restart = false;
          restartText.text = "";
          //---
         if (counter)
          {
               title = true;
               titleText.text = "TEST GAME";
               counter = false;
               inGame = false;
          }
          else
          {
               title = false;
               titleText.text = "";
               inGame = true;
          }

     }
     //---
     //---
     // Update is called once per frame
     void Update()
     {
          if (restart)
          {
              if (Input.GetKeyDown(KeyCode.R))
               {
                    SceneManager.LoadScene(Application.loadedLevel);
               }
           }
              else if (title)
               {
                    if (Input.GetKeyDown(KeyCode.R))
                    {
                         title = false;
                         titleText.enabled = false;
                         inGame = true;
                    }
          }
          else
          {
               AddScore(0.1f);
               UpdateScore();
          }
     }
     //---
     //---
     void UpdateScore()
     {
          scoreText.text = "Score: " + scoreDisplay;
     }
     //---
     //---
     public void AddScore(float newScoreValue)
     {
          scoreActual += 0.1f;
          scoreDisplay = (int)scoreActual;
          UpdateScore();
     }
     //---
     //---
    public void GameOver()
     {
          gameoverText.text = "Game Over";
          gameover = true;
          restartText.text = "Press 'A' to restart";
          restart = true;
          Debug.Log("GAME OVER GAME OVER GAME OVER");
          inGame = false;
     }
     //---
     //---
}

 


 

So I had a basic GSM – A little funky, but it works – It’s an approach I hadn’t tried before & it’s simple enough that I can either adapt it (if I want to stick with the code) – Or remove it if I decide to go for something more substantial.

 


Play the game (WebGL)

Grab a copy of the project here


 

 


 

Next post: 1.4a Tighten & Tidy

Last post: 1.2 Initial Code

Contents page.

 


 

Adventures in Unity – 1.2 Initial Code

Official_unity_logo

For me, the very start of the project is always the best and worst part.

On the one hand everything is still up for grabs – Everything is potential.

On the other hand, I’m staring at an empty project trying to figure out where to start.


When I sit down to code I generally try have two objectives in mind;

#1 What would I ideally like to achieve by the time I finish for the day.

#2 What’s the minimum I’d like to achieve by the close of play.

In this case:

#1 What would I ideally like to achieve by the time I finish working today – Would be having the initial platform & player code in place

#2 What’s the minimum I’d like to achieve by the close of play – To have the platform code in place.

There’s no guarantee I’ll achieve either, but it gives me a daily goal to work toward and somewhere to start.


After staring at the screen for far too long & trying out a few dead ends, I eventually got to a point where I felt I had a basic structure in place – I’d split the project into three basic aspects;

1. Platforms;

A platform is currently a default unity ‘cube‘ object set-up as a prefab. I thought if I set it up as a prefab it would make any later customisation easier. It has a mesh renderer so it can be drawn to the screen & a box collider to it can interact with the player.

2. Platform Manager;

This is just an empty element with a ‘platform manager‘ script attached. This script is what actually manages the platforms.

The ‘platform manager‘ script contains a list of ‘platform‘ objects. At the beginning of the game the list is initialised with cubes positioned from the far left to the far right of the screen (extending off-screen in both directions). Each cube is given a random width & height (giving the player a reason to move/jump).

each update loop;

  1. All cubes are moved/scrolled to the left.
  2. Any cubes that are scroll off the left side of the screen are removed
  3. A check is made to see if more cubes need to be created – If so cubes (with random widths/heights) are added to the list positioned on the right hand side of the screen.
using UnityEngine;
using System.Collections;
using System.Collections.Generic;

public class PlatformManager : MonoBehaviour {

     //---

     public GameObject platform;
     List platforms = new List();

     float speed = 0.1f;

     float farLeft = -30;
     float farRight = 30;

     float widthMin = 2;
     float widthMax = 10;

     float heightMin = 2f;
     float heightMax = 4f;

     float basePosition = -3;

     //---

     // Use this for initialization
     void Start () {

          initalRoof();
          PopulatRoofs();

     }

     //---
     //---
 
     // Update is called once per frame
     void Update () {

         //---

          for (int counter = 0; counter < platforms.Count; counter++)
          {

               platforms[counter].transform.position = new Vector3(platforms[counter].transform.position.x - speed, platforms[counter].transform.position.y, platforms[counter].transform.position.z);

               if (platforms[counter].transform.position.x  0)
               posX = (platforms[platforms.Count - 1].transform.position.x + (platforms[platforms.Count - 1].transform.localScale.x/2))+1;

          while (posX < farRight)
          {

               float width = Random.Range(widthMin, widthMax);
               float height = Random.Range(heightMin, heightMax);

               posX += width / 2;

               Vector3 position = new Vector3(posX, basePosition + (height/2), 0);
               Vector3 scale = new Vector3(width, height, 10);

               //---

               platforms.Add(Instantiate(platform, position, Quaternion.identity) as GameObject);
               platforms[platforms.Count - 1].transform.position = position;
               platforms[platforms.Count - 1].transform.localScale = scale;

               posX += (width/2)+1;

          };
 
     }

}

3. Player;

Player is a default unity ‘cube‘ object. It has a mesh renderer so I can be drawn to the screen & a box collider to it can interact with the platforms – It also has a rigidbody and C# script (called ‘player‘) to manage movement.

The ‘player‘ script is very simple and uses code modified from Unity’s ‘2D platformer‘ tutorial. It sets the initial position for the player at the start of the game & uses two methods – Update & Fixed Update – To allow the player to control the cube.

Update checks to see if the player is trying to jump (pressing the spacebar) – If the player is trying to jump it sets the ‘jump‘ boolean to true – Since the platforms as moving from left/right – at this point – the player only needs to move up and down.

FixedUpdate handles the actual ‘jumping‘ – If the player wants to jump, it adds a ‘jumpForce‘ to the cubes rigidbody and sets the ‘jump’ boolean to false.

using UnityEngine;
using System.Collections;

public class Player : MonoBehaviour {

     [HideInInspector]
     public bool jump = false;

     public float jumpForce = 10;

     private Rigidbody rb;

     //---

     // Use this for initialization
     void Awake()
     {

          rb = GetComponent();

     }

     // Update is called once per frame
     void Update()
     {

          if (Input.GetButtonDown("Jump"))
               jump = true;

     }

     //---

     void FixedUpdate()
     {


          if (jump)
          {
               rb.AddForce(new Vector3(0f, jumpForce, 0f));
               jump = false;
         }


     }

 //---

}

& That’s it – By letting Unity’s in-built physics & collision engines to handle the heavy lifting we have the core to an endless/infinite runner game.


Play the game (WebGL)

Grab a copy of the project here


Now, don’t get me wrong – There’s still a long way to go before this is a game – & there is a LOT wrong with/missing from the current code. But this does provide an interesting basis to work from.

Next step I’m looking to wrap a simple GSM around the game. This will allow the game to be replayed without needing to stop/start the engine every time.


Next post > 1.3 Initial GSM

Last post < 1.1 Introduction

Contents page.


Adventures in Unity – 1.1 Introduction

Official_unity_logo

I ran through a few of the Unity tutorials back in November 2015. With the intention of putting something together straight away – while everything was fresh in my mind – but life, the universe and Christmas got in the way.

While I did manage to keep develop Bit:Shift (uploading to Google Play & Amazon App Store) over the holiday period – Learning Unity was put on the back burner.

By the time I did get back to looking at Unity it was mid-January 2016 & I’d forgotten almost everything.

Rather than go back to the tutorials – which may have been the sensible option – but would have been time-consuming &tedious. I decided to put together a very simple game – something I could make by referencing my existing tutorial code; that would allow me to play with different aspects of unity (game play, GSM, Sound, multi-platform, etc) and which I could expand on over time.

Something which I could potentially develop despite forgetting almost everything I’d learnt the previous year.

Now, the code was going to be horrible – There’s no getting around that – But it would be a project I’d developed from scratch – It would be a start.

screen640x640

[Image from Canabalt]

After I little thought, I settled on a 2.5D endless/infinite runner type game.

I figured this would be a good way to start since so few elements are required: player & platforms.

It can run nicely using simple graphics, I could let Unities built in collision/physics engines handle all the heavy lifting which I worked on trying to understand the development environment & structure.

It also means I don’t need to spend a lot of time designing aspects of the game – I can focus on learning while coding.

All good in theory – Now to see how well that works when I actually try 🙂


Play the game (WebGL)

Grab a copy of the project here


 

Next post: 1.2 Initial Code

Contents page.


10 Print “Hello World”

Hi – My name is Scott Lewis, I develop video games under the ‘20 Goto 10‘ banner.

 

Initially developing games for the Xbox 360, publishing EOLMagic Thighs & Slightly Phil, Twist Imperfect, Fat Cow · Hot AirnorT:Tron ’84

 

I followed these up with four small ‘one-tap’ Android games; Bit:Run, Bit:Rise, Bit:Fall & Bit:Shift

 

Currently I’m slowly teaching myself Unity & looking for a job (who knew it was possible to make so little money making indie video games? 🙂 )

 

I thought I’d try writing a blog – maybe update as I develop new games, post-mortem past projects – Try to give some perspective on what seemed to work & where I went wrong.

 

I hope you stick around to see how things go.