Ludomo Games

Game: Curve Ball

Created in: 2008-2009

Ludomo Gamestudio gameproject

Team: Kjell ‘t Hoen & Dave van Luttervelt

This idea came after playing the famous ‘Peggle’ game from Popcap. In Peggle players had to aim and fire in order to collect as many points as possible.

Peggle

With this concept I changed the aiming into a timing mechanic. In stead of aiming players had to wait for the right time to fire. Objects that would launch the moving object (the player’s avatar) would themselves rotate or change direction. Due to this simple timing mechanic I was able to make this game a ‘one button game’, a game that could be played entirely with on button.

As with most games, I first made a prototype:

Curve Ball prototype

After a while I remade this prototype into a full game. With this upgrade I also improved the theme and graphical style to what I originally had in mind. In this version the moving object was a mechanical ball and the objects that would fire this ball were rotating crossbows. The graphics had to portray an expensive jewelry-like look with moving and rotating elements:

Curve Ball new graphics

To make the game more interesting I added different special crossbows that would have a special effect in the game. A gravity reverser would turn the gravity into the direction of its arrow and the bouncer would bounce while rotating, to give the game an even more arcade feel:

Gravity Reverser & Bouncer

During playtesting I found that many players did not touch even their keyboard. They used the mouse to click everywhere in the screen and nothing happened. The first thing that I changed was making the cursor invisible, but that didn’t really help, so I also gave the left mouse button the same functionality as the keyboard button.

Another important thing in this game was the game flow. One of my fellow students (Toby Hazes) at the time suggested that there should be a smoother flow in the game. With this he meant the time players had to wait for a chance to shoot the ball in the right direction. As the game originally was, players had to wait some time with every crossbow. Toby suggested that it would be better if a player could fire much faster if he were to be more skilled. The game had to be tweaked in such a manner that players could do the entire level in a ‘speed run’ just like was almost always possible in games like Sonic and Mario. By creating code that allowed me to delay some of the crossbows I managed to create this flow.

What was tricky with the graphical representation, was to make the players understand that there was gravity that also had an effect on the ball. This is why I titled the game Curve Ball, where the curve is the curve the players had to project with their mind in order to make the correct ‘shot’. After experimenting for a while with falling objects in the background, I eventually went for a more subtle solution: arrows that point to the direction players had to go in. These arrows were situated on walls and ceilings and as soon as I added them to the game the gravity was easily understood, for when there are ceilings there are also floors and thus gravity.

Arrows

You can play Curve Ball here:

http://www.ludomo.com/curve_ball.php

Game: Plan-it

Created in: 2008

3rd year project Utrecht School of Arts

Client: Project bureau Leidsche Rijn, City of Utrecht

Team: Emiel Boelman, Dax Erken, Robbert van Geffen, Kjell ‘t Hoen, Ruud op den Kelder,  Rob van der Pol, Jasper Siebeling & Maxine van Tongeren

During my 3rd year at the Utrecht School of Arts I co-designed a game for the city of Utrecht called Plan-it. The assignment to create a game for the promotion of Leidsche Rijn Center, a new urban area on the crossing of the A2 (freeway) and railroad. The game had to illustrate the difficulties and tough decisions a project bureau has to make when developing plans for a center of large magnitude.

First we sat down with our client to talk about what it was they wanted and what they expected from us. Our predecessors were the creators of ‘the Blob’ (now Ronimo games), for the city center of Utrecht. Leidsche Rijn project bureau now wanted something similar for their urban area.

The next step was research. What were the problems surrounding a project like Leidsche Rijn Center? From these problems had to arise the gameplay, for most games evolve around the solving of problems. This approach, together with some small physical prototypes led to many different concepts. The designers (Maxine and myself) were tasked to turn all rough ideas into just a few working concepts. In addition, the design had to be something that our client wanted and something our team would be willing to create. Therefor the entire team was invited during the brainstorm sessions and we contacted the client on a regular basis.

Physical prototype

Prototyping gameplay

At the end of the brainstorming and conceptualization period we presented 4 possible ‘final’ concepts. From those 4 concepts, our client had to choose only one we would then take further into development.

The client choose for the eventual concept: Plan-it, a game set in space (the final frontier), where players have to buy and place structures on empty planets. Every level is a large planet, suggesting one of the urban area’s in Leidsche Rijn: Terwijde, Parkwijk, Het Zand and Leidsche Rijn Center. By placing buildings on the empty planet, players gain income to buy even more buildings and road. To make the game even more interesting, there would be holes in the planets player had to avoid. If they would build too close to a hole, they risked their buildings falling in. Also there were computer opponents that would deliberately try to push the player’s buildings in the holes. The goal with those levels was to beat the opponent(s) and push his/their buildings in first.

Final concept

After this midterm presentation we had to write a design document and asset list to specify every graphical and technical element of the game for the graphic designers and programmers. We had to make a lot of choices during this process. In order to view the outcome of those decisions, check: http://www.ludomo.com/Documents/Design_Document_Plan-it_Final.pdf this document is the final version. Of course there were many things that had to be tweaked and altered before we had the design nailed down like this. Here are some examples:

1) Core gameplay. We did not want the buildings to be stationary, but create an ever-moving, growing and evolving city. After some prototyping, the programmers came up with a technical solution for our dream concept: buildings hovering on cells. In our game cells were round circles that could move over the planet and expand or shrink according to the size of the building that was placed on top of it.

Technical prototype

2) Experts. In Plan-it there are 3 experts you can hire for a service. We invented them, to give the player some help while building their city. The marketeer would provide inside in what types of buildings were going to be popular (so players could build those buildings in advance). If there were no desired buildings hovering around the planet, players could hire the architect to create some for them. Finally, there was a archaeologist that could prevent players from building on top of archaeological findings.

The greatest challenge while designing the experts was their specific role in regard with other game mechanics. ‘She has to help you with the market and he has to design buildings’ was too vague. What could a player use them for? Eventually we turned this around and focused on the core mechanics. There were archaeological findings, a ring of buildings and a market, so we decided we should find the things that were hindering or annoying to the player and let the experts take care of those things. This way (described above), the experts really fulfill a role that is meaningful and makes the player wants to use them. Last but not least there was the project manager, that guided the player through every step of the process.

Experts

3) Enemies. Originally, we wanted a game that was multiplayer. Because this would take far too long to create, we decided to make it single player and let the opponents be controlled by AI. AI was fixed quite fast by making it the sole responsibility of one of the programmers (Jasper Siebeling). He skillfully managed to let the AI make a way around holes and towards the player. Because we aimed at the rather casual market, the AI had to be simpel to average and had to have different attitudes towards to player to stay interesting. By tight communication between designers and programmer (asking and answering loads of questions), this part of the development turned out to be fairly easy.

AI behavior and difficulty

After some months of production and a few additional months of post-production the game was finished. What was most interesting to me about this project was the size of the team and the client. This was definitally a serious game that had to inform people that might otherwise never play games about something that was going to happen (the LRC). It was a challenge to create a design that fitted all requirements, was fun to play and interesting for the team to build.

Final game screenshot

The client was kind enough to send me some copies of the final printed version. It was only when I received this final version that I felt the game was really finished. I had worked on it for so long and it was a great reward to see (smell and touch) it for real.

Plan-it final version print

You can download and play Plan-it here for free: http://www.utrecht.nl/plan-it

There is also a Leidsche Rijn game hyve:  http://lrgame.hyves.nl/

Game: Wheels of Imagination 0 and 1

Created in: 2006

Private gameproject

By: Kjell ‘t Hoen

This game concept was one of my first concepts I thought was really new and innovative and truly never done before. I was just starting with Gamemaker and this idea was something that was on the edge of what I could do at the time.

The idea was to collect incoming symbols. This in itself was not new, but the manner of how to collect them, was. Instead of turning the incoming objects like in Tetris, in this game you had to turn the objects that had to catch the symbols, or put those objects in the right position. The game is called wheels of imagination, because there are multiple wheels which all speak to the imagination of the player (so to speak).

Even though I did not have a clue on how to build it I started anyway and made the first prototype. There were a lot of things wrong with this prototype. For example:

• There was only one level. At the time this seemed a good idea, because the concept reminded me of Tetris, which has also just one level. It was a huge mistake though, trying to put a huge concept like this (it turned out to be much larger than I originally thought) in one level and expect it to be fun. Putting it all in one level resolved in a large tutorial and too many wheels right in the beginning.
• The symbols: they looked too similar and were far too small.
• The difficulty: it was way too hard, right from the beginning.
  

  Too small wheels and only one level

What was a good thing of this prototype, was that it solved an interface problem: the status bar on the top right portion of the screen is often overlooked. I solved this problem by focusing the camera on that point right in the beginning, so players would understand what the bar meant.

Status bar

A while after I put down this first trial, I had more ideas for different wheels and I wanted to put them all in one game. Wheels of Imagination 1 as we know it was born.

In this version I decided to make a large menu wheel that could select the different wheels. This turned out to be a mistake in the end. The wheel had the same logic of the rest of the game: click left to turn left and click right to turn right, which was not explained yet and difficult for players to understand. This wheel caused some of the players to be unable to start playing without my help, personal explanation (e.g. it failed usability).

Bad, complex interface (my bad)

The in-game wheels I came up with were straight forward and easily understood (except wheel 3). Below a small description of each wheel with an image of both concept drawing and eventual wheel:

Wheel 1

This was the wheel of the original concept remade with the lessons learned from the prototype. Now, the wheel had only 3 smaller wheels that were a lot bigger. The shapes were also a lot less similar and I added more color to make each wheel even more different. I also made this version of the wheel a lot less difficult in the beginning. I could do this now since I understood Gamemaker better and therefor had more control over the spawning of symbols. I could determine where the symbols came from, what color and even what shape they had. With this power came great responsibility, because almost nothing was random and I had to make every decision.

Wheel 1

Wheel 2

A new concept I thought of separated from the early prototype. First I wanted to make it an entire game on itself, but a the time it seemed a good idea to embed it into the wheels project (as they also are large wheels). In this wheel the symbols would come from within the wheels and had to be matched with the corresponding symbol on the wheels. For this part of the game I made three wheels that would appear one by one. Every wheel could separately be controlled by the player.

Wheel 2

Wheel 3

This wheel turned out to be complex (maybe too complex) to understand. The goal was to guide the right color laser from one of the 4 objects through a wheel towards the right incoming symbol. Even though the symbols moved very slowly, players had trouble getting the objects situated and the wheel turned in time. This was fine, as some players enjoy a challenge provided by a wheel like this.

Wheel 3

Wheel 4

The most casual of all wheels. Players just had to click until they had the correct form to intercept an incoming symbol. A key matched a lock, fire matched water, a saw matched wood and a hammer matched stone. With this wheel, because of it’s simplicity and speed a lot of players were instantly hooked.

Wheel 4

Lessons learned

• With regard to the level of control. As I described at wheel 1, but what was true for every wheel: I had a lot of control over every symbol or shape. This was great, but it tought me that sometimes it is better to have some randomness in your game. You can not fake randomness if you control everything and therefor the game feels fake. This way every challenge is created by you (and not by ‘nature’) and therefor everything is also your fault. It’s great if you get it right, but in my experience I got it right faster when I was tweaking on a higher level, just determining the maximum and minimum of values.
• With regard to tweaking: when tweaking symbols, colors or shapes, realize that most of the time the fun of the game is not about how well you tweak the order of visual shapes or level layouts at all. This happened to me while tweaking wheel two, where in the end I was slamming my head against the wall out of frustration. No matter how I tweaked the symbols, the game still failed (while at the same time I knew the concept was solid). Then, while staring at the code I changed the speed value a little. This tweak immediately improved the entire gameplay and fixed the wheel. An element like speed (as well as animation speed) is crucial to any game experience design and should never be overlooked. Especially not while designing arcade games, where speed IS the game.
• With regard to tweaking numbers: it is better to halve, double or triple a value than to ad only a tenth. When adding to little and trying it again, the difference will be almost invisible and you will always start with the idea: ‘this time I’ve got it right’, which is wrong. When you halve, double or triple you realize this and you can better estimate what the true value should be. In addition you might also find a new challenge for the player or interesting game mechanic that involves speeding up or slowing down.

You can play Wheels of Imgination here:

http://www.ludomo.com/wheels_of_imagination1.php