11 Game developer tips

14 Sep

Here’s an short article I wrote a while ago for a company, unfortunately they never ended up using it so before it gets too long ago, I thought I’d paste it in here. This is from about mid 2011, I think.

My names Terry Paton, I’ve made many games now over a 8 year period, mostly self taught. My advice typically comes from being a solo, independent developer, though I’ve worked for several years in studio environments making games for advertising and promotional companies.

These tips are mostly focused at those new-ish to game development. In designing a game world that can be played in, a series of systems and procedures need to be created. For me game development is essentially solving a long chain of problems. Learn how to solve those problems and your a long way to making a fun game.

1. Imitate and copy

Copying or imitating is an awesome way to learn how to do something, traditional artists have done it for centuries. “This practice was generally considered a tribute, not forgery, … ” (http:/ / – If you want to get better at something, then trying to do it like those who already have mastered it. Look at the choices they have made and consider why they made those decisions, often important things are hidden in subtlety and the only way we learn those subtleties is by creating the same thing. The balance here is ‘stealing’ versus ‘inspiration. Ripping off someone else’s idea in a way that harms their hard work or producing something which is ‘inspired by’ their work. If you plan on publicly releasing something, I recommend you should inject some of your own vision into any game you make, take a concept but then extend or change it to create something of your own.

2. Break it apart and experiment small

It’s extremely easy to get overwhelmed with the sheer amount of work in producing a game. Breaking apart the game into segments or sections that can be worked on independently makes game creation much quicker and easier.

It also great for your motivation, with clear identifiable tasks you see your progress clearly, and see how much is left to do. Isolating and breaking apart a problem can mean many things, depending on the context. In code it may mean separating into more classes, or just separating functions into smaller separate loops, or more … The idea is to try to reduce a problem down to easily manageable parts that can be worked on cleanly.

Breaking apart and experimenting with several ways to solve a problem, in separate small isolated projects, is extremely useful, and keeping those projects for later reference also makes a great resource when your making another game. Especially in early development, your able to isolate problems much easier while the code base is small with few external code influences, so it’s important to do so.

The optimising process, where you speed up rendering, code execution etc, can also be helped when elements are separated out, again allowing you to clearly see bottlenecks and problem points.

3. Sketch, plan and visualise

Documenting and writing about your game is a great way to explore the ideas, and experiment. Our imagination is far greater than anything we can make, so use as much as you can before committing code to bringing something to life.

Sketchbooks are a great way to quickly explore ideas and concept, with just a few scribbled lines you’re able to visualise major themes or ideas within your games. For me games are little self contained worlds where the rules are made up, and you can lose yourself in them. With dreaming up these worlds, visually doodling the various concepts within the game helps with thinking about those parts, and often show you problems you may encounter.

You can come up with the core idea for a game very quickly but the many parts that make up a game may need some careful planning and thought, especially if you have only done it a few times. By exploring these ideas as much as possible before committing resources it can save you a lot of wasted time that comes from when you encounter unplanned problems or ‘scope creep’.

Scope creep is when the amount of work in your game grows and grows because you keep adding ideas while the game is being made, introducing new problems that need to be solved. Scope creep is your enemy.

Mind mapping is also a great tool for exploring ideas and their various elements. The basic concept is to list out a few key topics, then note down thoughts about each one, expanding each note further and further. This can quickly become a branching list as your explore various concepts and ideas. What this does is quickly break down a game into manageable parts that can further be broken down into a todo list (if necessary). One of my favourite tools for this is ‘Thoughts HD’ for iPad.

Other methods to explore gameplay aspects – white boards, cut out shapes and use physical objects to pretend or play, use Lego. This ‘playful’ experimentation quickly shows potential issues, and helps to visualise the things that need to be built. It’s also important to remember that you won’t know if something is fun, until you try playing it. So it’s important to make prototyping and play testing a part of your planning process before you are fully committed to a game design.



4. Interface planning ‘Wireframing’

Wireframing is essential to making a game efficiently and with minimal changes. By planning the games interface with simple boxes and text you can quickly get an idea for the various UI elements that need to be designed and built, along with potential interface flow problems. It quickly becomes clear when a screen has too many buttons or is missing features when you see a rough of it in front of you. These wireframes then become the basis for the games ‘shell’ (as I call it), giving both a programmer and designer information to build and design from. Be clear and concise, if it’s not in the wireframe, it shouldn’t be built – unless it’s not visual, and even then notes can be added to each page. Example wireframe:




5. Polish and tweaking

This can be one of the hardest parts of game development as it comes at the end of the project when you’ve worked for a long time and can start to feel burnt out and bored. The thing to keep in mind is that this phase of game development will unavoidably come, so save some enthusiasm and energy for it, be prepared for the hard part at the end of making a game.

Polishing a game can involve lots of small changes and adjustments – though sometimes you’ll need to make some significant backend changes to make a relatively small player side change. To help with identifying what need polish, it can help to take a break from your game for a little while, then look at it with fresh eye.

Record a video of yourself (or someone else) playing the game, this’ll help you see things easily overlooked when you’re engrossed in playing or making a game. How much polish depends on the game style, the target market, budget and resources. Again, plan for this phase as it means your almost ready to launch your game.

6. Crowd source your motivation

Making a game, especially in a small team (or on your own), is tough. There’s a lot of work, parts that you won’t enjoy and sometimes you will encounter set backs in development. Morale is hugely important, games get finished much more smoothly if your happy about working on it.

Sharing your work and showing others both inspires other people and motivates yourself. If you talk to the people you share it with, you’ll also find out if it has obvious flaws. Depending when you start the sharing process it can also be a great way to get ideas for your games. Often before I start actual work on a game I’ll talk over the idea with a trusted friend who has a different way of looking at things than I do. Our excitement as we talk and explore ideas helps me greatly and often he’ll suggest things I overlooked or never even thought of.

Listen, but not too carefully to feedback, If your going to share your work you do need to be wise about who you share with and be prepared for any type of feedback. Its easy to get distracted by the comments you can get back about beta version of your game. People can easily focus on early graphics, gameplay or features, so be aware the games going to be criticised for these things. If your aware that these will be issues, you can quickly overlook them and focus on the suggestions that have.

Being wary of negativity and avoid getting caught up in it. Sometimes you do need a thick skin as you may not expect what you hear, and occasionally some feedback can be negative. Pick and choose who you listen to carefully, look for those who will inspire and motivate what you – but also tell you the truth. Feedback from players and other developers has helped me enormously over the years, to keep going when at times I’ve felt like giving up.

7. Cut corners, wisely

Often while developing a game it becomes apparent there are a few ways that things can be done. For example, using a detailed accurate physics engine can often be unnecessary when a simpler solution will do. One of the key reasons to cut corners is that there is so much to do, so any time saved is time gained for something else. It’s often better to rough something together and get it completely working, then look at what needs improving with added detail.

That way you’ll end up with something playable (and able to find out if it shows potential for fun), which can then be polished and refined. Its good to be aware that some things are not so easily shortcut and may in fact present greater problems. A good practice is to think broadly about major components of your game and guestimate ways in which they can be done, look at the options and evaluate how long they may take. If something looks complex, research ways in which the problem has been solved before, or alternate ways of solving it.

8. Focus
Make there be a primary focus within gameplay, give your player a primary reason to be working their way through your game. Give them extra things to do as added incentives, but by focusing the player you greatly enhance the players ability to get lost in gameplay. Make the primary gameplay mechanic fun & enjoyable, and let it consume the player.

Also in terms of development, narrow down on problems, remove external influences and make the current problem the only one you focus on. Set limits on how much scope creep you’ll allow before the task at hand become too big task and needs to be broken down further. Making sure you stay on one task, and finish it well first is paramount to getting a task done quickly and effectively.

9. Work with the end in mind
If your vision for your game is clear then finishing becomes a whole lot easier. When your ideas are vague or weak it’s quite likely you’ll experience ‘scope creep’. If you set fairly tight limits on what will be in the game, how much time your prepared to work and budget constraints, it makes it much easier to finish and focus on. Decisions about features are quickly made when there are clear limits.

Motivation over the length of development is also helped by focusing on the finishing line occasionally. Evaluate the current build state of your game and document what’s left to build, (hopefully) you’ll feel more motivated and have a clear list of whats needed to complete it.

10. Play test, early
Making sure the core of your game is fun (or engaging) early on is essential and a , proof of concept is essential if you want to be successful in finishing, nothing is more demoralising than halfway through a game realising it’s not fun and it can be difficult to change that. Early play testing will also show how players handle controls and the game concept. If possible watch people play your game, and give them as few instructions as you can, if a player is confused by your interface, your gameplay or certain mechanics then it helps enormously to see that happening. When the game is launched, the people playing it aren’t going to have you talking through the game, and will almost always skip instructions. If a player can’t pick up your game and just work out how to play then you may to do things differently. It’s best to identify these problems early rather than try to fix a finished game engine.

11. Game theme, and vibe

Creating a theme or ‘world’ that your game exists in makes game development much easier. For example, if you choose a theme of Egyptian, immediately lots of choices about design and gameplay become obvious. If you choose ‘Bleak Future adventure’ then again choices about style and gameplay are quickly narrowed. When planning out a game there’s often small pieces that need decisions to be made about, and without a theme become much harder to decide.

Another example, If your designing doors in your game, with the theme of ‘Egyptian’, your design choices are quickly directed towards things like – sand, stone, hieroglyphics, wood etc. Making the decision process much easier.

Some helpful links:

Seven Creative Tips for Amateur Video Game Makers. LINK
Some great advice on making games:
I’ve blogged about the development process of one of my games here: cat=445
I’ve photographed my game dev sketchbooks over the years and can be viewed here: http://
A mindmap I’ve made titled ‘What makes a great game':



One of ‘those’ posts

14 Jul

Yep, it’s one of those posts that sometimes pop up on blogs that were once very active. After several years of a lot of activity posting about the development of my games and prototypes, working as an Indie game developer, it’s all suddenly very different. I wanted to write some notes here as I’ve pretty much stopped altogether.

2013-07-14 11.20.27

One of the biggest drivers for change in my life has been the birth of my beautiful daughter, Pixel Maya Paton (My wife’s choice of name, and happens to be the same as this blog name!). As of writing this she’s about 3.5 weeks old. Life is suddenly very different, revolving around the needs of our highly dependant little person. It’s a wonderful change and one that I’ve looked forward to for most of my life, a little Paton. Other big driver in what I do has been lack of financial success, burn out and the need for a certain measure of financial security.

A while ago I was blogging about the tower defence game I’d been working on for several months and for most of the time I was enthused about finishing this game and bringing it to life. But then my eyes started to open a little. One of my biggest problems with developing my games has been to develop a relatively straightforward game mechanic and then just pad it out with more levels, not really expanding the gameplay or fun the more you played the game. Some of my games have indeed been quite fun, and even somewhat popular, but for me I’ve really begun to feel that I’m repeating the same mistakes in game development over and over. I don’t necessarily think this is a bad thing, and has indeed been a process that I’ve needed to go through. The nature of my skills, being self taught mean that I often get hooked into cycles of doing things until I reach an ‘Aha’ point, then move on to different things.

And so, a few months back I canned the idea of even finishing the tower defence game, it had actually reached about 80% completion for what I originally had in mind, but suddenly the gameplay lost its appeal and I couldn’t see the depth and fun in the gameplay anymore. I love the concept, world and several of the mechanics in the game, but it’s over. I’d even considered scrapping the core gameplay and implementing a TD plugin system had more of the gameplay elements I was looking to add, but then suddenly it was too late and my motivation had moved on. I’ve chalked it up to experience and moved on.

Its easy to hold onto things when they’ve long lost their real appeal, fearing that my motivation, my skills, passion have dried up. But its also easy to get stuck into cycles of bad habit. For me to see my failures more clearly and move on is more important.

So what am I doing now? In the lead up to my daughter being born, I had a couple of false starts with a few companies, trying to find where my skills lie in the employable space. The rejection of Flash as a widely used technology affected my job prospects quite heavily, and I’ve not wanted to go down the HTML5 path if at all possible. Finally my pursuit of Unity3D as my main platform has proved a good choice and I’m now working a 2 days a week for a company (developing games and augmented reality apps using Vuforia) and the other 3 days for a private client (developing a game, probably more after that too).

My passion for making games has changed dramatically, and how could it not after making well over 100. I still love games, still love sketching ideas for them and thinking about how I might make something. But for the short/medium term it’s all about providing for my family, which as an Indie game developer I personally had no chance of doing the way I was working.

On a more positive note, I did get a Ouya recently and this is something that excites me. I’m extremely tired of the touch screen controls and have wanted to make games using a controller for quite a long time, but there;s been no practical way for me to publish anything using a console like control (The bigger consoles have definitely been out of my reach). After some initial hassles with setting things up for publishing I have finally been able to get something running on the Ouya, and it’s exciting stuff for me. I chose to test out a prototype I made a few months ago, which is based around my Deep Sea Diver game idea.

Here’s a video I made recently just after I’d got it working:

ouya with controller from Terry Paton on Vimeo.

Now lets be clear, at present I’ve pretty much given up even considering to make finished games for myself any more, it’s all about client work. BUT I do still really enjoy tinkering with ideas, playing with code and creating little worlds to play in. This gives me a freedom like I haven’t had in a long time, the pressure to finish ‘complete’ games has been immense and really started to ruin the experience for me, where what I want to do for the moment is prototype and play, get some love for my craft back again. I’d like to explore this game engine some more, now that I’ve got a new control scheme and platform to play with … but I’m also saying that I possibly won’t.

Anyway, lets wrap this up. It’s been amazing blogging and sharing my work over the years. I hope people have enjoyed the ride, learned something from me, and even been inspired. I’m starting to move on to other things, wanting to explore new interests in life … before my life runs out. I’m now what I consider about halfway through (expecting to reach to 80) and I’d like to be more.

Some final more philosophical thoughts …

Often times life can be a shitty experience, but through hard work and focus that can change. Trust me it will probably get shitty again, but you’ve got to make it worth it.
Do what you love, even if you don’t have much time. Earlier in life I drew 100 pages of hands, about 5-10 hands per page and it helped me to draw a whole lot better. It took about 10 mins a page per day.
Ignore people who shit on your ideas. People seem to like to criticise what they don’t understand, or what seems strange or confuses them. Often it will be subtle and undermine your confidence. Get away from those people and that kind of influence. Ignore that crap and follow your gut instinct. People say stupid stuff sometimes.

Rock on!


Posted in Misc


Source code to 6 more AS3 games! (Part 5)

02 Apr

IMPORTANT: Due to bandwidth problems I’ve moved all the links, but the good news is that all downloads of all my games will be on one page. Please visit this page to download zips of each file:

Following on from my previous posts (Part 1 & Part 2, Part 3 & Part 4) I’m giving away more AS3 Flash game code. For more information why I’m doing this, please read the first post. I’ll repeat the terms and conditions at the bottom of the post, but otherwise, lets get on with it!

IMPORTANT: Please read my blog post here ( for ‘conditions’ of use for this source code.

IT IS IMPORTANT TO NOTE: Some of these game were made with Flash Builder 4.6 or less (and sometimes the Flash IDE), Flash Builder 4.7 seems to break the games, especially embedding of images and fonts.

Jacks (Blackjack)
Live game:
Source: see note at top of this post!

Deep Sea Diver
Live game:
Source: see note at top of this post!

Meteor Storm 1
Live game:
Source: see note at top of this post!

Live game:
Source: see note at top of this post!

Xmas Cannon
Live game:
Source: see note at top of this post!

3D Deathchase
Live game:
Source: see note at top of this post!

You can email me at or catch me on twitter ( / google plus ( .

If this source code help you in any way, I’d love to know. Cheers!


Update on my Tower Defence game

30 Mar

Well it’s been a while, but with good reason. My wife and I packed up our lives and moved house away from our country living and back to the suburbs. I’ve now gotten a full time job, moving away from full-time indie game development, and we have a baby Paton on the way in about 3 months. So without internet, and time, the development of this game had to slow down immensely. But I’m getting back up to speed again and I’ve made quite a lot of changes to the game since my last video update.

I’m getting pretty close to a good solid game engine now, with just one majar thing to work out, then LOTS of small things to tweak and adjust. The graphics are still very much placeholder, I’m not really sure how the final game will look at this stage, but I like to keep polishing things as it gives a more realistic setup for when real graphics are finally used.

Due to the game play needing more flexibility I switch over from using the built in pathfinding solution in Unity (Pro version) to using an A* method. I ended up buying the excellent ‘Simply A*’ from the asset store and worked with the plugin developer to tweak things a little. The developer was great help and for $20 this plugin saved me a lot of time and hassle. As I had already set my game up with a completely different method of pathfinding it did take quite a bit of effort to adapt my game to an alternative method, but it’s all working well now. The biggest change brought about by using A* is that levels are now more dynamic and pathways can be created by the player, rather than being baked and unchangeable.

Here’s a couple of videos where I talk about the pathfinding …

Pathfinding demo from Terry Paton on Vimeo.

Pathfinding demo 2 from Terry Paton on Vimeo.

Check it out ‘Simply A*’ here:

There’s still quite a bit of work to go, but it is progressing. Can’t wait till I start getting new graphics into the game!

1 Comment

Posted in Unity


Source code to ALL the AS2 and AS3 games I’m sharing

14 Mar

Due to some bandwidth problems I’ve collected all the source code for my games I’m giving away into one place.

IMPORTANT: Please read my blog post here ( for ‘conditions’ of use for this source code.

ALSO IMPORTANT TO NOTE: Some of these game were made with Flash Builder 4.6 or less (and sometimes the Flash IDE), Flash Builder 4.7 seems to break the games, especially embedding of images and fonts. Some games were also made in the Flash IDE (the AS2 games we’re all made with it), the point is … there maybe a large variation in the quality and errors in each of these games, be warned!

Another NOTE: You might get a warning from google that they are unable to scan the files for viruses. It’s because the files are over a certain limit and Google won’t scan them. They are safe to download though.

—– Actionscript 3 —–

Meteor Storm -
Xmas Cannon
Deep Sea Diver
3D Deathchase

Blockworm -
Galaxy Gems
Meteor Storm 2
Treasure caves 2

Deep Sea Diver 2 -
Bowling 3D
Breakit 4
Body Defence

Maus Trap
Vector Defender

Darts 3D
Robot Arena -
Drive 2
Stunt Run

—– Actionscript 2 —–



Space Ace -

Cavern Run -

Frogit 2
Grid Memory

You can email me at or catch me on twitter / google plus.

If this source code help you in any way, I’d love to know. Cheers!