Some months ago I wrote an article on this blog titled “Tools for creating a game“. On that article I talked about the tools I used to develop my first iOS game New Sokoban. The message of that article was summarized with this mental note:

Mental note: always use existing tools. If there is a tool that barely fits your needs use it. You will be amazed about how quickly you adapt yourself to that tool and how your productivity increases.

However, currently I’m working on a new game that needed a very specific and game dependent developing tool. So, unfortunately, I spent about two weeks developing, testing and refining a development tool for my new game. In today’s article I’m going to share the experience.

The game I’m currently working on is an endless type game. Like classic Tetris or Doodle Jump. You know, I game that generates new content on the fly based on some predefined rules. The opposite case to New Sokoban, where the game progress is based on different levels, that slowly increase in difficulty.

On the current version of the project we have 4 types of entities that have some kind of behavior based on some properties like speed, size, trajectory… The game needs to spawn periodically one entity type with some pseudo-random values for its properties. So, how can we achieve that?

The naive approach

First we needed to define the spawner parameters that will be modified along the game progress. Currently we have:

• Probability to spawn. The spawner tries to spawn and entity every half a second. But we define the probability to actually spawn it.
• Probability to spawn each kind of entity. If the previous step is “YES”, then we roll again to decide which kind of entity is actually spawned.
• Entity speed.
• Entity size.

However, this parameters need to evolve along time to make the game increase in difficulty. So, actually, we have “Init” and “End” pairs for every parameter above. I think that this is the naive approach. With this architecture you actually can create an endless game based on a pseudo-random spawner.

However, the results achieved on prototypes created with this system were very lineal and boring. The game was essentially always the same but with more speedy entities on screen until game over.

We needed to sophisticate a little bit our architecture. I have no idea of how, for example, Doodle Jump or Tetris were designed, but I think that it is obvious that they have something more sophisticated that the system I have just described. It seems that they design the progress of the game based on some kind of “chunks”, “sections” or “levels”. I really don’t know how to name it.

The “Sections” concept

A colleague from iDevBlogADay, Ken Carpenter, called this concept Gauntlet, as he explains on this article. I finally decided to call it “Section” for our game. Ken’s game is more similar to Doodle Jump in the sense that with the editor he defines chunks of stages that have some interesting gameplay. Opposite to that, Tetris probably defines spawn probabilities for the different available puzzle pieces. Our game is more similar to Tetris in that sense. We also have entities that need to be spawned.

Anyway, when the “sections” concept was introduced, the need of a Sections editor became obvious. So, what’s a Section in our game? A section is basically a snapshot of the previously described properties and probabilities. So, for every section, you can specify spawn probability, entity probability, entity speed and entity size. And remember that every one of these parameters is actually a Init/End pair.

So, maybe you already see how powerful has become our system with the only inclusion of the “sections” concept. However, on the cons side, we have a much more complex system that needs a special, custom made tool to be managed effectively.

Mac or iOS?

Actually, I only spent about 2 minutes with this decision :p I decided to implement it for iOS and with an iPhone based interface, to be able to be used both on iPhone and iPad with the same code.

So, why iOS?

I decided to implement it for iOS devices because the idea was that every member of the team could create a “story” (sequence of sections) on his device when he was relaxed: on the sofa watching TV, at bed before going sleep, at the bus back to home… the idea was that the design process was done somewhere with a different atmosphere from the work desk, to improve creativity and inspiration.

Having the editor on iOS also makes easier to test the design changes directly on device without rebuilding the project.

Why iPhone based?

Basically, because the game needs a slightly different gameplay on iPhone than on iPad. So, the idea was to create iPhone stories on iPhone and iPad stories on iPad.

Using the Sections Editor

The Sections concept implied the addition of section-specific parameters to the system: section name and section duration. Section name allows the designer to label the different sections to better manage them. Sections duration determines the duration of a section in spawned-entities. So, a duration of 5 means that this section lasts the time needed to spawn 5 entities, taking into account the parameters described previously.

Following you have a video that shows the usage of the editor:

Conclusion

I have been using the editor the last two weeks to design the endless-type game I’m currently working on and the results are not completely positive in some aspects.

About the chosen platform

I think that having the editor on the device implies a lot of benefits. So, in general I think that it was a good decision.

Usability

However, designing the user interface of the editor to be usable on the iPhone caused it to have a navigation based interface. And this implies a lot of navigation. You get used to it after some hours of work, but I think that the user interface definitely needs to be improved.

Scalability

It is relatively easy to add new entities with new properties to the editor and integrate them to the specific behavior of every game.

Reusability

The editor and its user interface have been designed to be 100% reusable with no pain (however, that’s why the user interface is not good enough…). On the other hand, the integration with the specific code of a new game could be an issue. However, I think that the overall reusability is good enough.

Features

This is the best part. Actually, I designed and implemented this tool to have exactly those features I was interested on. So, the tool is powerful enough.

About the overall system

Overall, I think that spending about two weeks on the development of this tool has saved us a lot of work later. Moreover, the quality of the game will be probably higher. The Sections concept was not possible to implement effectively without the editor. And now, with the editor, adding and removing entities and properties is very easy, so prototyping and testing new game mechanics is very fast.

However, there are a lot of aspects that can be improved. And probably during the development of the next spawner-based game I’m going to spent some time improving them.

Opinions and Suggestions

Do you have experience developing this kind of endless-games? How do you face the development of them? Do you think that the system described in this article makes sense?

I have no experience working on this kind of games, so any suggestions or opinions will be welcome 🙂

Thanks!!

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.