My first two weeks as an indie game developer

I’ve been an independent game developer for two weeks now so here’s a little progress update…

The business

Always hire accountants, their specialist knowledge is valuable. My accountants are setting up my company as we speak. It will be called Richard Lord Ltd. because this is all about me and the projects I want to do.

Not all the projects I want to do are games, but the majority are. I have a list of ideas including nine games, two apps, one piece of hardware, one web service, one book, and one dance production.

I will have one project in production at any time, with pre and post production on others as appropriate. I will try to balance my time so most of it is spent on the current production project.

Working from home

I like working from home. It’s quiet. I can concentrate, focus, get on without interruptions.

I can also manage my time how I want to. I start work early, at 7:30, and have broken the day into four two hour blocks of work, with long breaks between. I go for a mid-morning run after the first block of work, have a relaxed lunch after the second, and do some reading or play a game after the third.

The lack of distractions and frequent breaks means I’m very productive, so there’s no need to work in the evenings or at weekends, which is good because there’s other stuff I want to do with that time.

I try to use six hours a day for the current production project and two hours for other work – managing the business and pre-production for other projects. I’ve managed that most days so far.

I also try to get out and about a bit, particularly when there’s an appropriate event on. It’s good to meet other developers. I’ve been to a couple of evening events and this week is Mobile Games Week in London so I will be out a lot.

My first project

My first project is a 2d physics-based puzzle game. I’ve deliberately chosen one of my simpler ideas to start with because I want to release something soon and learn from it.

It’s a mobile game. It could be a desktop game too, but I think it’s better suited to mobile. I’m aiming for iOS and Android versions, with a Windows Phone version if it’s not too much trouble.

I’m developing the game with Unity3d. There’s a little part of me that would like to build my own ECS game engine, but I’m trying to be more practical than that and I already know Unity well from my previous work. It would be silly to reject such powerful tools in favour of more work.

I built a prototype for the game first, to test it out. The gameplay is relaxed. There’s no timing element to it so players aren’t pressured by the clock or their reaction time. But, painfully, a single mistake can ruin the best laid plans. I like it.

I hope to release the game in about a month. I’m building this game alone for now, but I am interested in meeting possible collaborators. I’m doing all the code but might collaborate on graphics or audio, and I certainly will need collaborators for some later projects.

Monopoly – too political or not political enough?

Monopoly is, in many respects, a boring game. Tactics are generally very simple and a game can last a long time. When I was a child and played with my family, my Dad always won. He bought every property he could, mortgaging other properties if necessary, because he knew that, when all the land has been purchased, the owner of the most land is in the strongest position.

But more than this, Monopoly is a nasty game. A player can only win by impoverishing the other players. Many games have winners and losers, but few so thoroughly abuse the losers as to bankrupt them. I don’t like playing Monopoly but I do find the game interesting. Continue reading

Teaching Game Design

It’s a little known fact that before I became involved in game development I was a choreographer. Yes, I have a degree in Maths, and I started programming computers when I was 12, but after getting that degree I went to dance school in London and got another degree, this time in contemporary dance and choreography. I followed this by forming my own dance company and spent the next ten years choreographing dances.

Which begs the question of how I got into game development. Most choreographers do something else to supplement their choreography income, it comes with the low-pay high-satisfaction territory. Some teach dance or do other dance related work, others wait tables in restaurants. I wrote code – it paid better and I enjoyed it. Eventually, a few years back, I stopped choreographing and focused entirely on game development.

Which is all background to what I want to talk about. Reading Daniel Cook’s recent article, How Revolutionaries become The Man, and particularly the section on game design teaching, caused me to remember, and dwell on, how I was taught choreography. Continue reading

Finite State Machines with Ash entity system framework

Finite state machines are one of the staple constructs in game development. During the course of a game, game objects may pass through many states and managing those states effectively is important.

The difficulty with finite state machines in an entity system framework like Ash can be summed up in one sentence – the state pattern doesn’t work with an entity system framework. Entity system frameworks use a data-oriented paradigm in which game objects are not self-contained OOP objects. So you can’t use the state pattern, or any variation of it. All the data is in the components, all the logic is in the systems. Continue reading

try{harder} level-up

The first try{harder} took place last October and I was lucky enough to be one of the 16 attendee/speakers. The four-day conference was residential – we lived together in four “executive cabins” at Center Parcs in Sherwood Forest. That means everyone had a double bedroom, an en-suite bathroom, and three new developer friends to have breakfast with.

If you ask people who attend conferences why they do it, most of them will tell you it’s for the networking. Some of the presentations will be good, but it’s the conversations, over coffee, over beer, and over dinner, that make the conference worthwhile. Because the best thing you get from a conference is the opportunity to share experiences with other developers, to talk about code, to learn from each other.

try{harder} has that in spades. try{harder} is about sixteen experienced developers teaching and learning. Seminars, code jams, pair programming, and of course conversations. Not shallow chats, but important debates, with depth and breadth, explored over a four day period. Sometimes lubricated with fine scotch whisky (thank you David). The experience is intense, exhausting, exhilirating, and absolutely wonderful. Continue reading

Why use an entity system framework for game development?

Following my previous post on entity systems for game development I received a number of good questions from developers. I answered many of them in the comments on that post, but one question stands out. It’s all very well explaining what an entity system framework is, and even building one, but why would you want to use one? In particular, why use the later component/system architecture I described and that I implement in Ash rather than the earlier object-oriented entity architecture as used, for example, in PushButton Engine.

So, in this post I will look more at what the final architecture is, what it gives us that other architectures don’t, and why I personally prefer this architecture. Continue reading