A game a week - Chicken Catapult Constructor

Chicken Catapult Constructor is a project I created for university with just one week to pull it off. In addition every other course is happening as regular. So the time is really limited. It's a real challenge but also quite an opportunity, producing a game every week means creating 4 games a month. Designing something completely new and different every week.

So in that regard it's like a game jam, but in fact it's completely different, let me show you why:

My initial idea was to make a physics-based catapult construction game. This idea, consisting of nothing more than physical objects and the goal to build some kind of catapult, was very rough and had none of the features the game ended up having.

(In the end it looked like this.)

I spent my first day creating a very basic physics playground, with planks, stones and two modes: construction and simulation. Since Unity has a built in physics system I simply had to add rigidbodys and a few lines of code to make it work. As I handed the 'game' over to some friends with the instruction to build a catapult, they immediately started having fun with it. The outcome of a physics simulation can be funny very fast. More on this later. I was on the right path!

Since I had university- and other private stuff to do, I took a day off from the project and had some time to think about the following steps. A great benefit from the "a game a week" concept compared to a game jam.

My next step was giving the player a few more elements to better construct a catapult. Therefore, I designed nails, functioning as connectors between objects, but they can be used as hinges for rotating elements around a certain axis as well. The other big thing were the ropes. Since a real catapult also has ropes and by spawning the projectile a few seconds later, the whole construction has to be stable before, they were quite important for both realism (as far as you could call the game realistic ;-)) and gameplay. Before, the player could have effectively cheated, by placing a stone high above the catapult and use the falling down force to launch the projectile. So, trough spawning the projectile a few seconds later, the stones would have already fallen down in the moment it spawns.

After adding some camera behavior trying to always frame the right things with the best fitting scale, the next playtesting started. The feedback was mostly positive but really fast I had a good Idea of the flaws the game had, then.

- a rather complex control scheme consisting of different mouse inputs and some keys to press. Also, the left mouse button and right mouse button were not used in the same way for every interaction, some elements used drag and drop and others didn't.

- Furthermore, I needed lots of explanation not only for the controls but for the different states the simulation could be in etcetera.

- The task to build a catapult was in there, but no challenge was formulated like: hit a certain point.

So after adding explanation and correcting the control scheme I decided on giving the player the task to throw a projectile as far as possible. It best matched the idea of the sandbox. If the goal would have been destroying a castle, by throwing stones at it, the game would have had a different challenge.

The challenge to create a far shooting catapult, is way clearer and even after you built a great catapult, you would try to further improve it. After your construction has reached its maximum potential (or is totally messed up) you might have new ideas of what works better, and start with a fresh construction.

Here lies one part why the game is fun, the mastery. The willing to find the best way to archive a certain goal. Another important part is the perceived self-efficacy. The players are constructing for a certain time, and then seeing the construction in action, self-assembled, they build a functioning catapult from limited parts.

To further improve that, I added a line visualization, for the path the projectile travelled. The curves do not only look cool, they are also made by the catapult the player created himself. To finalize it, I added one important part I had in mind for a long time. Little flags, that show the distance to the starting point.

Without the small breaks, days off and play-testing sessions in-between, the game could have ended up very edged and unpolished. Not saying that it's greatly polished now, but the additional time to think and amount of feedback added a lot improvement I was able to achieve. If I had made the game during a game jam, these momentums of reflection in-between would not have been possible. I would have missed great opportunities in which I was able to identify what I think the core of the game’s idea is.

Very often during jams an imagined idea sounds great in your mind, but later in reality it doesn't work out the way you pictured it. I'm not saying that game jams are bad, or game jam games are all missing this core. That's not my point. But I think that something like "a game a week" is a great alternative or additional way of creating prototypes as well as small games in a short amount of time. 

View the result on Itch.io

Making a Detective Game

Making a real detective game. That was the Idea I had in my mind, while inventing the basic design of “a Case for Watson”. For me that meant, to NOT give the player any feedback whether he/she is progressing by solving the crime or not. No flickering elements in the environment that tell you directly that they are important ore interactable.

The main ways to get information, were the dialogues and the environment. For that, most of the dialogues have hidden markers, which store information in a certain sentence. It includes topical tags like “war” to real clues, like “the victim played piano right before he was found dead”. The player is able to save things the NPC’s say.

Same goes for the environment. In every detective game there is blood at strange places and potential murder weapons all over the place. Instead of letting the player take all objects with him/her, we had a different approach.

We let the players take drawings of everything. That had several reasons and upsides I want to talk about now.

  1. The Player can’t take things like splattered blood with him/her. And removing all evidences from the places they have been before sounds not like good detective work anyways, does it?
  2. There was no direct feedback, whether the things you found were relevant or not. Like a real detective you really had to look around and think yourself, instead of trying out what you can click at.
  3. We were able to easily make more abstract things, like missing objects available as evidence.

This drawing also had the same type of clues hidden inside, depending on what you took a photo of.

With both, the dialogue parts and the pictures, you can go to any NPC’s and show them the things another person said, or the ones you found in the environment. They will comment on that now. If you, for example, show them a picture of the cake you found in kitchen they will tell you about Elizabeth making a cake, whether they knew it or not. Their answer also has a clue in it. Clarice for example may tell you, that she didn’t know Elizabeth was making a cake, because she was giving a concert. Now you are able to ask her about the concert, and so on.

Sadly, we had to cut a feature of combining two clues to a new one. That would have generated too many possible combinations, we were simply not able to create answers for.

But as a detective, you must be able to deduct, and expose lies. To do that you confront a NPC’s with a statement that conducts the things they told you before.

To prevent the player from getting lost in the dialogues, I ensured them to be highly interconnected. There are several big topics, like war, green, as Richards favorite color and the piano. All these topics intersect one another. Richard suffered from war, that led to some weird habits, like loving green and hating red and the strict timeslots he used for playing the piano. Of course, on a larger scale and the different characters play a lot of roles, by stating their opinion to the victim, the murder and the relations between all characters.

At any point in time you can always leave the scenery to wait for sherlock. That means you think you have seen enough and know anything to correctly identify the murderer.

In a final dialogue with him, you name the murderer and answer the key questions, by showing dialogue or picture evidences, you think of as prove. The key questions are: when, who, why and how. In the end you get a final score, calculated based on how many correct evidences you had. You are able to get back to the crime scene in order to improve.

In the end, the game is more experimental than I imagined it to be. But I think if you get used to the way the game tells its story you can have a very interesting experience. I learned a lot during the creation and improvement of the games mechanics, some of the key ideas can be used as inspiration for future projects, like the picture taking mechanic.

A game in 2 weeks.

Before I started this project I mostly created concepts, single assets ore levels for games, and had lots of long time projects i worked on over a long time. To see If I was also able to produce a whole game, in a limited period of time, I challenged myself with creating a game in 2 weeks, all by myself.

For that the scope had to be very small, but on the other hand it should have enough aspects I could work on. The aspects I planned to create were: simple 2D movement (including climbing and collision), 2D pixelartstyle, an own shadow/light -system, camera behavior and level design, to only name the biggest.

My first goal was to create a prototype, to test the basic gameplay elements, like running, climbing and collision. I chose Game Maker Studio 2 for it, because it was the environment I used to be most experienced with and knew what I would be able to pull off. The result looked like this:

With all sprites included and no lighting yet, the game looked like the following

Maybe the biggest challenge for me, was the creation of the light/shadow system, because I had never done anything like that before. The shadow system basically calculates which areas are out of your/(the players) sight. With simple vector calculation, all walls draw their ‘shadow’ (the area behind them – from the players perspective) on a separate surface.

This separate surface is multiplied onto the normal game view, later in the rendering of the frame. Something similar goes for the light-system. Every light source gets a radius and an intensity, after that I generate a white blurry dot in matching size and opacity.

The light representation is also drawed on a separate black layer, which is added in the rendering process along with some more blending methods to create the light effect. The finals result looks like this:

After I created all elements including their look and behavior, I was finally able to set them in context, to create the levels. The first levels are teaching the basic mechanics, like jumping and the usage of pressure plates to open gates. We take a look at a more complex one here.

In the center of the level is a bigger hall, with 3 gates and 3 pressure plates, located. The one in the middle is already activated. If the player walks on one of the others or takes the barrel that is already placed, he can directly see the connection between the plates and the gates. An additional hint is stored in the stone plate on the wall. Stone plates are used in the game to give hints for puzzles or to tell stories through poetry or different kinds of texts, the player is able to read. The player hopefully has the idea to get two additional barrels to place them on the plates in order to open the door.

The barrels have another function as well. You are able to climb onto them, to reach areas which are higher that you can normally jump or climb. In that case you also have to take the barrel with you, to reach the other barrels. The other barrels are, in this case, also locked at their places, so you first need to get the two keys from the bottom floor.

But you are also able to get the keys first, the level can be played in different ways and orders. The most optimal way looks something like this:

The level is enhanced with some decorative elements like spiderwebs and other stone plates for you, to learn more about the castle you are captured in. Some rooms are placed around you, which you can’t reach, just to give the architecture a more natural feeling.

In conclusion, the level design is very simple and was quite fun to come up with. Moreover, playtesting from friends and family really helped to improve the experience of playing the level.