Bubble Pack update – monetisation

It used to be the only question about monetising your game was how much to charge, and you could leave that decision until quite late in the development. But in this era of free-to-play we have to ask ourselves how we propose to charge for the game, and we have to ask early because the decision can have significant ramifications for the game.

How to charge for your game is sometimes very simple and other times very hard. With Bubble Pack I have always known that I want the initial download to be free. There are two reasons for this Continue reading

Bubble Pack update – gameplay

I have been playing around with the gameplay for Bubble Pack, adjusting it to get the right difficulty balance. There are lots of small adjustments that can be made to make the game a little easier or a little harder and I also tried a couple of bigger changes.

First I tried letting the player set the power at which the ball is thrown. Unfortunately, this made the game far too easy whilst also making the controls more complicated, so I ditched that idea. Continue reading

Bubble Pack – my first indie game

Wow, setting up a company is a lot of work. More than I remember from last time I did it (fourteen years ago!) but I’m getting there. All the admin has had a substantial impact on development of my first game, so progress is slow. I have also neglected to tell you about the game I’m making, which is remiss of me. That changes now.

My first game is called Bubble Pack. It is a physics game – how many bubbles can you pack into the screen. You launch each bubble to bounce around the screen, and when it stops it expands until it touches the side wall or another bubble. You have to pack as many bubbles into the screen space as you can. Continue reading

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. Continue reading

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