First gameplay

Sun, 11 Jul 2010 by Thomas ten Cate · Comments
 Archimedes, Game Development

I had hoped that the editor would allow me to quickly test gameplay concepts by using “soft rules”: rules that are communicated to the tester verbally by me, instead of being enforced by the program. For example, I could say “Now try moving the orange ball into the blue rectangle, but only moving the green blocks.”

However, there was one thing I hadn’t realized: every change made in the editor is a change to the level itself, not a change to the current game state. In other words, barring saving and loading, there is no way back. Since I needed saving and loading anyway, I decided to make a separate “test mode” after all, in which the level designer temporarily becomes the player and loses his god-like powers over the game world.

With the design of most games, and this one is no exception, there are three basic questions:

1. What does the game world look like? (What does a level consist of?)
2. What will be the goal of the game? (When is a level “finished”?)
3. What tools will the player have to achieve this goal? (What are the possible interactions?)

So far, I have the answer question 1, the basic look of the game world: a fluid in a box, fitting on the screen, with objects that interact with the fluid.

As to the goal, this would clearly have something to do with controlling the fluid. Since the fluid itself is a rather amorphous thing, I decided to create some pellets that floated inside it. The goal would be to bring the pellets to a particular location. Perhaps pellets of different shapes or colours would have to be brought to different places, so you would have to take care not to get them mixed up. Perhaps the colour of the fluid would affect the pellets somehow. Perhaps pellets would only be moved by fluid of the right colour, and you’d have to mix the colours to get the pellets to move.

As to the interaction possibilities for the player, this is something I have left open so far. Ideally, I would like to give the player a lot of freedom and control, but of course not so much that the puzzles become trivial. However, all this is pretty vague; it was time to come up with something more concrete. For starters, I added a special type of wall that can be moved along a line by dragging it with the mouse. This allows you to block passages while opening others, thereby affecting the fluid flow. A screenshot is below.

You can see the light blue blocks and the “rails” along which they can be moved. You can also see how one yellow and ten orange pellets (in honour of the Dutch football team, which is playing the World Cup final tonight) are moving along with the flow. Unfortunately, the force fields that propel the flow itself are, as of yet, invisible! I had set up the green area as a target zone, trying to create a puzzle where it was not too easy, but not too hard either, to get the pellets from the top left to the bottom right.

Playing with this, I found it hard to come up with a level that behaved in a predictable way. The movable blocks also did not provide the degree of control over the fluid that I wanted. Finally, it was not possible to make the blocks close at least one passage: by moving it halfway, the player could choose to open both passages. I could constrain the block’s motion even more, but that would reduce the degree of control even more.

The problem was with the way the fluid is set in motion. As I mentioned in a previous post, the fluid was propelled by a force field that acted upon it in a certain region. However, if we set up a force field that propels the fluid into a walled-off container, fluid will forever keep flowing into the container in spite of mounting pressure. Perhaps this is due to inaccuracies in the fluid solver. Either way, this phenomenon put me on a different track: instead of propelling the fluid directly, I could specify the pressure in certain regions and let the solver take care of the resulting fluid flow. With different pressure levels in different regions, and a flow from high-pressure to low-pressure areas, this would suddenly make connectedness of areas a huge deal and make even a tiny passage potentially significant.

During the upcoming week, I’ll experiment with this idea and other gameplay-related concepts, in tandem with puzzle design. The most important part of game development has finally begun.