Unity RTS, Update 2 – Structure & Metadata

So, just like the ‘first post’ in this series, this isn’t actually Day 2, (more like week 2), but progress has been good enough to post a new update.  Since I doubt that I’m going to have time to post updates daily, also decided to ditch the ‘day X update’ title schema, might as well not kid myself ;P


Last weekend, I posted a #screenshotsaturday pic of progress so far.  If you haven’t followed the #screenshotsaturday hashtag in the past, it’s definitely worth checking out – some amazing stuff being posted every week.

Here’s the pic again for the curious:



It’s nothing special to look at so far, but there are a few key things that I’d like to point out, and then I can dive into what’s next on the plate.

First – the code structure – MVC

As I mentioned in the first post, the goal with the codebase is to enforce a strict MVC pattern for the code.  It’s very easy in Unity to start just dumping a ton of public parameters at the top of your script. This quickly becomes unmanageable and starts to look like this:



That’s (unfortunately) some code from a project I wrote years ago (in Unity), before I really understood MVC and how Unity’s component model worked.  That very long page full of public variables / objects wasn’t even the full list in the top of that class.  As you can see at the bottom, the whole file is 1500 lines long. Note that this was the primary game loop / cycle for the entire game play mode (and it was a complicated game loop to say the least), but either way, it was far too complicated and did far too many things for it to be reasonable.

The Camera Controller – A Practical Examples

Enter the world of MVC. Let’s take a quick dive into the Camera Controller that I’ve put together for the project so far. Here’s what it looks like from the editor:


Code your components Wide, not Tall

At first glance, this might seem strange to you (or not), but as you can see, there is actually 4 separate components active just for the basic camera controller:

  1. Base Controller
  2. Movement Controller
  3. Zoom Controller
  4. Rotation Controller

The beauty of this is that each component is extremely narrow is scope and focus, which allows the code to be much simpler.  Because the camera controller isn’t particularly sophisticated yet (as far as configuration options goes), it might be overkill at this stage, but as I start to expand it, add new options, flesh out all of the potential variations that developers might want in a robust / general purpose RTS camera system, keeping the functionality separate from the start gives me a huge amount of flexibility.

For example, if you want a camera that doesn’t let the player rotate the view? simply deactivate the Camera Rotation Controller.  Don’t want them to zoom? disable the Camera Zoom Controller.  And so on.  I can implement alternate rotation modes for the camera without affecting the movement & zoom functionality (among other things).

Same goes for any of your class designs – instead of implementing crazy multiple inheritance patterns, instead focus on building small, building block components that can be built upon to create more complex behaviors.  This will save you a LOT of headache with Unity and simplify your code considerably.

The second point that I’d like to make with the above 4 components is that all 4 of them are actually built from 2 separate classes:

  • Controller class
  • Model class

The ‘model’ drop down that you see in the screenshot is a separate Unity class that has been tagged with the [System.Serializable] attribute. This tells the Unity editor that it should enumerate the class for display in the editor.  Otherwise, Unity doesn’t know what to do with your fancy ‘MyGameObjectModel’ object type, and it doesn’t appear in the editor.

Here’s the editor documentation about Serialization:  Unity 3d Scripting API : Serializable

So what does the Model class look like in code? It’s very simple.


using UnityEngine;
using System.Collections;

namespace gekido.gamesystem.models
public class CameraMovementModel
public float speed = 10.0f;
public float gravity = 10.0f;
public float maxVelocityChange = 10.0f;


That’s the entire Model class for the Movement component (so far anyways). Of course this will probably be expanded as things progress, but simple is good in my books.

Some things to note in the above code snippet:

#1 – Namespace All of the Things

What is a namespace, and why should you use it? 

Have you ever tried to use a .Net class, only to have to add a ‘using’ declaration at the top of your class?  What you are doing is telling the compiler that your code is ‘using’ objects (classes / methods) within the namespace defined by your using statement.

A common example of this is adding [csharp]using System.Collections.Generic;[/csharp]  if you want to use a proper List<> or Dictionary<> in a class.

Avoid Clashes with OPC (Other People’s Code)

Have you ever tried to import 2 Unity packages into your project and suddenly run into compile errors because 2 scripts have implemented the exact same class (albeit differently)?  This is probably my biggest pet peeve with almost every single Unity code asset package that is available on the Asset Store.  It is SOO simple to namespace your code, but only a few authors seem to bother doing this.  I don’t understand why.

The official Microsoft description of a namespace is this:

The namespace keyword is used to declare a scope that contains a set of related objects. You can use a namespace to organize code elements and to create globally unique types.

In plain english, a namespace means that any class that exists within that namespace is separated from other code, so you can name classes whatever you want, variables whatever you want, without worrying about whether someone else has implemented a common class name like ‘Unit’ or ‘Pathpoint’.

 Instead of those top-level classes, the actual path to my custom ‘Unit’ class is ‘gekido.gamesystem.controllers.Unit’ – assuming that Unit is the controller.

[csharp] namespace gekido.gamesystem.models [/csharp]

For all of my code, I have chosen the ‘gekido.gamesystem’ namespace.  Controller classes are in gekido.gamesystem.controllers, Models in gekido.gamesystem.models, Views are in gekido.gamesystem.views, and so on.

Programming 101

 Now, for anyone that has done  fair bit of c# / .Net programming, things like namespaces must feel like programming 101 fundamentals type code behavior.  The reality is that it’s startling how many supposedly ‘mature’ and popular Unity asset store packages (and full game projects) that I’ve encountered that don’t use anything remotely like a proper namespace scheme.   Hence why I feel that it’s important enough to talk about it.
Even NGUI doesn’t use namespaces for some reason, and it’s probably the most popular / successful Asset Store package of all time.
It doesn’t take much to add namespaces to your code, and it will save you and your end-users a TON of headaches in the future. Please for the love of all things Unity – add a namespace to your code!  I can’t emphasize this enough.

#2 – Not Everything has to be a Monobehavior

The second thing that you will notice in my Model class is that it does NOT inherit from Monobehavior.  This is likely a result of the fact that there is a lot of  starting programmers learning Unity and coding at the same time, but there are a ton of places where you do NOT need (or want) to inherit from Monobehavior for your class.  Short answer: If you aren’t directly attaching the script to a GameObject, it does NOT need to inherit from Monobehavior.  This also keeps your code cleaner and simpler.

#3 – Get rid of the default Unity class methods

A second, just as important, point is that you do NOT want to leave the default Start() and Update() functions lying around if you do not intend to use them.

When you create a new class, by default Unity adds 2 methods to the class:

[csharp]void Start()[/csharp]

and [csharp]void Update()[/csharp]

Update() in particular will slow your game down if it isn’t being used (particularly if you have a lot of Game Objects in a scene).  In the vast majority of the games I’ve built with Unity, I’ve managed to avoid using Update() and LateUpdate() completely, and instead gone with timed coroutines that allow the game to run at a different ‘tick rate’ for processing.  If you don’t need / want to process something literally every single physics tick or framerate tick in your game, then get rid of the Update() code and move it into a coroutine.

Additionally, if you do not intend to use the legacy Unity UI in your code, you can set useGUILayout to false to optimize the processing of your scripts.


void Awake( )

useGUILayout = false; // disable Unity GUI



Note that this (and other tricks) are available in the Unity Manual section that covers Optimizing Script Performance

Hooking the Model into the Controller

Now that we’ve covered our Model class, how do we actually hook this into our controller?

The good news is that this is very simple.  Here is a simple snapshot of the Controller that goes along with the Model that I’ve defined above:


using UnityEngine;
using System.Collections;
using gekido.gamesystem.models;

namespace gekido.gamesystem.controllers
/// <summary>
/// Controller for Camera Movement
/// </summary>
public class CameraMovementController : MonoBehaviour
public CameraController thisCamera;
public CameraMovementModel model = new CameraMovementModel();


You can see where I define the model object (the last line of the script snippet above), like so:


public CameraMovementModel model = new CameraMovementModel();


CameraMovementModel is the name of the class that we created above, and I’m adding a reference to it that will be just called ‘model’ in the component.  It is set to ‘public’ because I want to be able to edit the model from in the editor.  Unity knows how to display it in the editor because of the aforementioned [System.Serializable] attribute that we added to our model class, above.

This is displayed like so:



Elsewhere in the Controller class, any time I need to reference one of the model’s properties (Speed for example), we use the following syntax:


targetVelocity *= model.speed;


Simple, yes?  Now you may have considered the fact that this seems like I’m setting up 2 classes in my project for every component (potentially), but this doesn’t necessarily have to be the case.

Multiple Components, One Model

Once you start to organize your code into separate Controller and Model classes, you can also start to think of ways where a single Model could be used for multiple Controller components.

For example, the GameObject for a Unit in the game might have a Model to indicate what kind of unit it is, how fast is moves, what type of Unit it is, weapon types, damage, health etc.

This single ‘Model’ class could be used in both a MovementController as well as an AnimationController (as an example).

DataModel versus ViewModel

Something else to point out is the difference between a Data Model and a View Model.  Sometimes the term ‘Model’ is used to mean one or the other, or both of these terms.

Short version:

  • Data Model – represents the information about an object under the hood – ie as if you were extracting it from a ‘database’ of information.
  • View Model – represents the information that is used to visually represent that object to the end user / player – which might require transforming the Data Model into presentable form.

Sometimes the Data Model is an element of the View Model, but not always.  Often, in order to create the View Model for an object, you are required to transform the raw data (stored in the Data Model) into presentable formats for the View Model.

As a quick example, first let’s come up with a theoretical Data Model for a Unit in our RTS:

Data Model

  • unit_id = 100000
  • currenthealth = 80
  • maxhealth = 100
  • currentAmmo= 75
  • maxAmmo = 120
  • xpForNextLevel= 350;
  • currentXP = 200;
  • movementSpeed = 3.0f;
  • buildState = BuildState.Completed;
  • firingRate = 10.0f;

Hopefully the list of properties is fairly self-explanatory. We have a list of variables, with values associated with them.  Now, in order to present the Unit to the player, the ‘Model’ must be transformed into a View (which could indicate a UI Panel / HUD), or simply with the fact of rendering the Unit on the screen as a 3d model or 2d sprite.  The process of converting / transforming the DataModel into something presentable to the end-user involves building a ViewModel.  The ViewModel is passed to the View, which in turn renders the Unit for the player in the game (or a HUD Panel etc)

The above Data Model represented as a ViewModel might end up being:


  • displayName = John Wayne
  • health = currentHealth / maxHealth
  • ammunition = currentAmmo / maxAmmo
  • xpProgressBarValue = currentXP / xpForNextLevel

In my theoretical ViewModel, I have transformed the property of ‘currentHealth’ from 100 (in my Data Model) to a new variable called ‘health’ in the View Model.  Perhaps I am using an NGUI Progress Bar, which ha a value of 0 (empty) to 1.0 (full).  As well, the unit_id value could be used to look up the GameObject’s displayName of ‘John Wayne’ from a Localizer system, or perhaps the player’s input (stored in the PlayerPrefs potentially).  And so on.

Hopefully this makes sense.

Future Development and Updates

So, where do I go from here?  The next major step for the game is to actually start to flesh out some of the metadata that will be required for the game.  This means fleshing out the Data Model’s for the game (what data do I need to represent a Unit or Building etc).  After that step is done (in even a preliminary way), then I can continue to flesh out the Build systems (for spawning Units in the game) as well as some more of the gameplay (how fast unit’s move, what kind of attack(s) do they have, how much damage do they do, etc).

All in all, I’m pretty pleased with progress to date.  In the next update, I’ll go through some of the metadata that I’ve started to generate for the game, and discuss how I’m going about integrating it into the code (using JSON data) etc.  Things start to get interesting once some basic metadata is in place.  I’m looking forward to seeing the gameplay start to come alive!

Cheers, and see you until next time!


Unity3d RTS Pack, Update 1 – MVC in Unity

Ok , it’s not really day one, probably more like day 2 or 3, but close enough.

Short story is that I have a game design in mind that I’ve wanted to create for quite a while.  Being the lazy developer that I am, I’ve hoped that there would be a suitable Unity Asset Store Kit of some kind to come along and end up being ‘close enough’ that I could consider implementing the game for reals.  Alas, it hasn’t surfaced.  In fact, there doesn’t seem to be ANY half-decent RTS packs out there for building RTS type games to be honest, which seems strange, considering how popular Unity is, and how popular RTS type games there are.

I don’t consider myself an RTS expert by any stretch.  I’ll even admit that I’ve never played Starcraft – just don’t like Blizzard’s art style personally – I’m more of a Company of Heroes / World in Conflict person myself.  Either way, I’ve been playing a HUGE amount of Planetary Annihilation as of late (brilliant game, epic in scale), and love the fact that it is a) build in unity, and b) insanely huge in scale.  So I know it CAN be done, just a matter of HOW.

Which brings me to the RTS pack.  Now this is literally a side project of a side project, so we’ll see how fast it progresses, but I’m pretty pleased with how far I’ve gotten so far.  I have a pretty big library of related assets from over the years, so that side of things isn’t a problem, but my objective is to create all of the code myself (without using any 3rd party packs).  The only pack that I might use is NGUI, but I’m also kind of using this project as an excuse to familiarize myself with the new Unity 4.6 GUI system, so that might not even be incorporated.

To start, I’ve been focused almost exclusively on the basic code structure, getting some of the foundations implemented in what I feel is a clean code structure that should give me a solid foundation going forward.

What this means (to me) is a properly namespaced library built on MVC with a Pub-Sub event system driving things.

For example, I have a simple UnitController (the C in MVC) defined, that has a simple data model for all of it’s properties.

Instead of building out a crazy inheritance structure for the classes, I’ve gone ‘wide’ instead, where individual components are responsible for separate pieces of functionality.

So for something like a Unit in the game, I have:

  • UnitController
    • MovementController
    • AnimationController
    • SpawnController
    • AIController

And so on.  This is the same structure that I’m using in ProWrestlingX (the game that was just released on Steam), and it has kept the code clean and simple and allowed me to refactor / rework things several times during the development without worrying too much about the other layers of the code.

The UnitController also manages the Data Model (The M in MVC) and provides the single property bag for the entire set of components to work upon. The Data Model incorporates things like which prefab to spawn to actually show the Unit in the game, the Type of the Unit, and so on.

The SpawnController does the actual spawning of the Unit prefab (based on a Spawn event that the UnitController fires) etc.

Same goes for the BuildingController, that handles an Individual Building in the game, CameraController that handles the Game Camera, etc.

Overseeing the whole thing is a set of Manager Classes that will be responsible for managing things like the lists of Buildings & Units that have been spawned, AI Directors that will manage directing whole sets of Units etc.

The project doesn’t do a whole lot of gameplay yet since I’ve been focused on the underlying architecture and getting the foundation built, but it does spawn Units & Buildings appropriately, and I’m starting to work on the Camera Controller next, so I can actually start flying around and selecting Units etc.

Should have the initial layer of selecting & moving units done soon, after which point I can possibly post a screenshot or two.

Dev Blog – Adventures in Steam-Powered Games

Judging from this blog, apparently I haven’t been doing much as of late.  Nothing could be further from the truth though.

Last month, I was contacted by an old friend – they were just about to finish up a second Kickstarter for the game series they have been working on, and were nearing the point where they would be ‘greenlit’ to get their game on Steam.  They are a very small team (4 people at the time), with a single programmer actually working on the game itself.

Unfortunately, as they neared the end of the greenlight process, it became apparent that the programmer that had been (supposedly) working on things to date had vanished and/or become too busy to contribute any further, so they were in a bit of a bind.

I’m going to let the team and game remain nameless for the time being, but short version is that they brought me on to help whip a prototype together for the end of the kickstarter campaign.  This went fairly well, we didn’t achieve quite everything that we were hoping to, but it was fairly decent, considering that there was only a few weeks of part-time work done on it.  Before the Kickstarter completed, the project was greenlit, and suddenly things became very real – a game on STEAM.  Sure that doesn’t mean quite as much these days as it may have a year or so ago, but this game in question is fairly niche, and has next to no competition on Steam, which is a pretty rare position to be in – assuming we can get to market before any competitors.

The project prior to me joining was pretty chaotic.  The programmer(s) that they had been working with in the past were…strange to say the least.  Things like version control, continuous integration, wireframing, etc were all rejected as being ‘evil’ or ‘bad’ for some reason.  The only reason I can think of is because they let the project founder (ie the guy paying the bills) from having any kind of oversight into what the programmer was doing.  Ridiculous.

So I had a bit of work to get some basic structure / process in place, but luckily I had most of the pieces in place previously from my own projects.

So, the first thing that I did was set up the project in BitBucket – they have free hosting of git repo’s (even private ones) which is unbelievably awesome, and a life saver for small teams.

Continuous integration using Jenkins was next.  There is a jenkins plugin for Unity, but I just use my own simple batch files to run the build process, didn’t have any luck with the Unity Build runner when I tried it out a while back, and haven’t had time to revisit it again.  Either way, it’s easy enough to configure Jenkins to run Unity builds.

The rest of the past month has been a mad-house of trying to flesh out the prototype that I started building into something that resembles a full-fledged game, integrating steamworks, etc.  This has been a fun adventure – and has served to remind me why I enjoyed mobile development so much ;}  Building PC games is a pain in the ass in comparison!   Just trying to wrangle together a half-decent PC options screen is a huge process, let alone the other performance considerations etc that have to be taken into account.

To add an extra ‘gotcha’ to the project, one early requirement of the game is that it must be playable with a gamepad / controller from start-to-finish.  Not only one player, but 2 player.  This adds a level of complexity to everything (in particular the UI design), but it’s been a fun challenge.

The general process that I’ve taken so far is fairly simple – lacking any concrete UI designs or wireframes, this was the obvious starting point.

I started by taking the rough screen flow sketch that the designers provided and whipped off a ‘clickable wireframe’ using Balsamiq. Their tools are awesome, and let you get a LOT done very quickly.  This was great, and showed the team immediately how the game flow would feel, from a front-end perspective.  This immediately gave us feedback and let us tweak screen flow without even opening photoshop or Unity.

The second step was to do the same kind of basic wireframe / wkeleton layout of the  UI screens in Unity itself – get the entire front-end so it can be navigated from start to finish.  I have a ‘UI manager’ that I’ve been iterating on for a while now, so this first pass was also pretty quick.  NGUI gives us some great tools that auto-position and layout grids & button layouts, so I don’t have to spend a whole lot of time fighting with pixel layouts, I simply add a bunch of buttons to a panel and NGUI will position them properly. I’ll maybe do a post about some NGUI tricks like this later on – it can be a bit intimidating when you get started, but can speed up your work quite a bit.

Now that I have the front-end somewhat whipped into shape, I can finally hook it back up to the gameplay prototype that I had from before – and suddenly we have something that vaguely starts to resemble a game!

This will hopefully be an on-going series.  In future posts, I’ll try and cover things like Steamworks integration, how to handle Controller support across the board in Unity games (and any lessons that I learn as I finish this off), as well as NGUI tips & tricks.

Anyways, that’s it for now – back to the lair to try and finish rewiring the gameplay up ;}

Borrowed Post: My tips on how to stay motivated and get a game finished.

In lieue of actually having a post ready (or even close to ready), I’m going to steal / borrow this excellent writeup from reddit:

The question of how to motivate oneself or finish a huge project is a very common question here. I wanted to share my personal methods.
NB: This guide primarily applies to very small indie teams or solo developers such as myself, but some of the methods could be applied to specific tasks within a larger team.
Who am I? Where is the proof that my methods work? I’m a solo developer with two years of full-time work into my current game, taking it from prototype to a 30+ hour playable game. You can see screenshots and the current state of the game here
Getting Started
Most games revolve around a 10-30 second gameplay experience that is repeated endlessly. I first heard this concept described as a core foundation behind the design of Halo. This is the core of your game and if this isn’t fun, it’s unlikely the final game will be fun either.
Decide on the key concepts and gameplay elements that are at the core of your game.
Don’t waste weeks or months planning out every last detail for your game. (I first read this tip from Minecraft’s Notch)
Start work on it now. Don’t procrastinate. (Also advised by Notch) Start as you mean to go on. As Nike says ‘Just Do It’.
The Prototype
The goal of the prototype is to create that core 10-30 second experience to ensure that it’s as fun in reality as it was in your imagination.
If it’s not fun, tweak it until it is.
Don’t waste time on fancy graphics at this stage
If you can’t make it fun now don’t assume that adding more crap around it will make it fun later. That’s highly unlikely.
Once it’s fun, continue to add the core features (in a very rough but functional way) that you believe are essential to your game concept. It’s better to make sure the whole concept works now before you waste too much time on a dud.
The prototype can take anything from an hour to a month depending on the complexity of your final game.
If it’s not enjoyable now it’s unlikely that it ever will be. Don’t build a game on broken foundations.
The Master Plan
Now that you have a decent prototype it’s time to plan out in a very rough way your schedule for the project. If you don’t have a schedule you will fumble around endlessly wasting time and never get the thing done.
List all the core features that your game will need.
Don’t detail how you will achieve them. You may not even know how you will achieve them at this stage. Just list them. Also, list all the essentials that every game needs eventually – things like save game functionality, a website, rebindable keys possibly.
Do this in broad strokes. We are not looking to list every minute detail here, just an overview of the big picture – each big job.
Once you have your list, estimate how long each job in the list will take and write it next to it.
Total up the time for everything. Now double it! Seriously. Even if you are very conservative in your estimates, almost everything is going to take longer than you expect, and you are going to run into endless jobs that you never predicted.
If the final total is not something that you think you can achieve reduce the scale of your project and repeat the above process until you arrive at something manageable.
Breakdown the Master Plan – Chunks
Split all the jobs in the master plan into ‘Chunks’.
If your planned game will take two years you may want to break the list down into ‘Chunks’ that will each take three months each.
If your planned game will take 3 months in total, break it down into 2 week ‘Chunks’
List your ‘Chunks’ in the order that they should be completed.
Take the first ‘Chunk’ and break it down – ‘Pieces’
Even if your game is only planned to take 3 months to complete, you are still going to have a lot of work in each ‘Chunk’.
Break the first ‘Chunk’ down into a new list of ‘Pieces’. Again, don’t get into details here. A ‘Piece’ might be something like – ‘Create a basic GUI Interface’ or ‘Create assets for game feature X’.
Be sure that you have enough time to complete your ‘Pieces’ for that ‘Chunk’ in the timescale you have allocated. If not, you may need to move back up the plan and reduce the scale of your project.
Breakdown this first ‘Piece’ of the first ‘Chunk’ – Immediate Job List
Each ‘Piece’ might be still quite complex, and you may not know how to achieve it yet. As an example, our first ‘Piece’ might be something as broad as ‘Implement the user interface’ that could take two weeks to achieve. Now break that down into another wide brush stroke list, for example:
Implement the start screen
Implement the menu system
Implement the HUD system
Once again don’t detail each job yet. Just list the jobs.
Breakdown the first Job in your Immediate Job List
By now you get the idea. Hopefully each job in our ‘Immediate Job List’ will take no more than a day or two. For smaller projects you will probably be already down to jobs that should only take a couple of hours and you can skip this stage.
So for example we might break down ‘Implement Start Screen’ into this new list:
Create the background
Create the main menu (New Game, Start Game, Options, Quit)
Implement the code to make the main menu function.
Add some juicy special effects to make it look nice.
Pick a job and break it down
So let’s imagine we have chosen the job ‘Implement the code to make the main menu function’.
Finally we are at the micro scale. We now plan in detail how to achieve this single job. Break it down again. List each little piece of the job that needs to be done.
It’s a good idea to also now have a rough idea how you will achieve each little piece before getting started. This will help you predict problems that may occur with your chosen method.
This shouldn’t take more than 5-10 minutes. Maybe longer if it’s a complex problem that you need to do some research on first.
Now do it!
Rince and repeat stepping backwards through the processes. Do all the little jobs to complete a job on your ‘Immediate Job List’ Then pick a new ‘Piece’ of a ‘Chunk’ and create an new ‘Immediate Job List’ – Then do it!
The advantages of this method
It’s structured with timescales in place to get it all done.
The plan is all broad strokes that shouldn’t take long to list initially.
It breaks down massively complex systems into tiny, easy, bite-sized pieces.
You only get down to details just before actually implementing something that will be finished in a few hours.
No sooner have you planned the details than you are implementing them while the problem is still fresh in your mind. This keeps motivation levels high.
You get to strike jobs off your list quickly. Don’t underestimate how motivating this is. You see progression happening in a visual way constantly. There is nothing better than seeing a job list disappear.
Staying Motivated
Don’t procrastinate
If you ever allow yourself to think ‘I can’t be bothered right now’, push it out of your mind and get working immediately. Don’t give it any time to fester and gain traction.
We are stupid creatures. We live by habit. If we allow ourselves to not work because ‘we can’t be bothered’ this becomes a habit and it will happen more and more. Don’t let it start. Do the opposite – get in the habit of just doing it and then it becomes easy to just do it.
However, if you are in the habit of just doing it, and you get a strong feeling of ‘I can’t be bothered’ you are likely genuinely tired and need more sleep, or you’re overworked. See below.
Don’t Overwork – a recommended work schedule.
Applies only to full-time development
There is a reason the average working week is 40 hours. This has been proven over time to achieve efficient results. This is especially true in a concentration intensive job like game development.
Do 8 hour days, 5 days a week
Take a 5 minute break to get up and walk around once every 45 mins. Give your brain a break.
Take the weekend off to relax, recharge, and motivate yourself for the following week.
Get enough sleep. Don’t underestimate this tip.
Take a week off once every 3 months. This is essential or you will burn out. You need time away from thinking about something or you fry your brain so it’s of no use to you.
You will be more efficient and get more done by not overworking. Overwork makes our brain go around in circles while problem solving. If we are fresh, problems get solved very easily.
By not overworking, and getting enough sleep, your motivation levels will always stay high. – Well at least until mid way through Friday :)
The only times I feel like ‘I can’t be bothered today’ is when I’m genuinely physically tired from lack of sleep or because I’ve overworked recently.
I hope this is useful info for some of you. It’s not going to work for everyone but it’s worked for me and I’m still motivated after two years of development.

AI Navigation frustration

Have been using Unity’s built in NavMesh system for the character movement so far – it’s great because you can get things happening in all of a few lines of code, but just ran into a major hurdle.  Actually it’s one I knew about, but had been avoiding because I thought I could work around it.  But after further deliberation, it’s not going to happen.

Basically the goal for the environment design is to break up the world(s) into multiple scenes – for example, a larger outdoor scene and individual smaller interior locations.  The goal was to stream in the sub-scenes (the interior locations) and procedurally build up the actual mission environments dynamically.  Everything in Unity is geared towards this kind of asynchronous additive style loading of content – except for the navmesh system.  Unity only allows you to have a single, monolithic navmesh in a scene and basically ignores the navmesh element of any subsequently loaded additive scenes.

So, that’s not going to work for me at all.

Luckily, the RAIN{Indie} package not only provides me with what I’m looking for in the basic navigation system, but also provides behavior tree editing and mecanim support out of the box.  Going to put together a few quick prototypes to confirm that this will work for what I’m trying to do, but at an initial glance, seems to do the trick.  Their system also gives me some sample code for squad-behaviors, which will help quite a bit as well.  Hopefully should work well.  Will post an update if I can get things moving along.  Will be a bit painful having to rip out the guts of the character movement system, but luckily it was at a fairly preliminary state (and was pretty simple either way), so shouldn’t take more than a day or so including the prototyping.


The ‘Middle’ in Middleware

As you may have noticed, up until now, I have not touched any specific technical functionality or even come close to writing any code.  This has been a conscious decision for a couple of reasons, but the biggest is that I wanted to lay the groundwork for the next steps, and make sure that everyone is on the same page when we start to implement some of the initial functionality. Continue reading The ‘Middle’ in Middleware

Social Analytics & Game Design for Traditional Game Designers

Scan through the game industry news portals and it’s not hard to get an uneasy feeling of ‘doom and gloom’.

There are a lot of displaced game developers around the world.  I read an article a few days ago that claimed that ~10,000 people have lost their jobs in the game industry over the past few years.  I’m not sure if the author was simply totally up every mention of studio shutdown’s / downsizing etc, without factoring in the rapid evolution of the industry from big studios to social & mobile, but either way, 10,000 jobs is alot, and the closer the layoffs hit to home, the harder it is to stay positive about the whole situation.
Continue reading Social Analytics & Game Design for Traditional Game Designers