Slime’s Adventure

Approximately a couple of months ago, the four of us -Filiz, Jing, Shi, Suraj - formed a team as a part of a class project to create something. In this context, a game. Fast forward 60 days into the future - here we are. We proudly present you, “Slime’s Adventure”. We finally did it. This by no means is the end though - as there is a lot of scope for development and we for one don’t see this as the end.

So without further ado, let’s get started.

1. Final prototype description

1.1 The background setting of our game

Our game IS a slime’s adventure. Slime is a vulnerable creature and easy to be destroyed by anything, and now Slime is exploring a dangerous dungeon! It will face mountains, logs, stones, holes and even volcanoes, and it needs to be flexible and smart enough to avoid all the obstacles and reach the tunnel in order to go home.

At first we thought of a lot of themes: Dungeon, ocean, sky, jungles, space. And we wanted to make levels for all of these themes, but then we realized that it is impossible to make all of them in this relatively short period; we could make two for most. Thus, comparing to make two not consistent and rough theme level, we chose to stick to one theme and try to make it better and better.

1.2 Game play

When player first get in the game, they will see a main menu which has a “New Game” button in the middle and “Credit” “Load game” “Scores” on the side.

(Main menu)

When player hit the “New Game” button, there will appear a short instruction about how to control the slime and they can click anywhere to begin the game.

(Instruction)

After the click they will be led to the game room, which has a deep dungeon theme. The slime appears on the left side of the screen and the position is fixed; the background scrolls toward left automatically so that it feels like the slime is moving to the right. After a short while the obstacles begin to show up, and players need to jump or shrink/expand their slimes’ size to go through. To guide our players, there are coins around the obstacles so that players will know when and where to jump while following the coins. To encourage players to follow the coins, we added the scoring mechanic: Players can see their score on the left top corner of the screen; their score get higher when they collect more coins.

(Screenshot of gameplay)

When Slime touches something it shouldn’t, or drop into a hole, it will die and the game will show player a ending screen. In the ending screen players can see their scores and choose to go back to main menu or continue to play. When they choose continue to play, they will be led to the nearest checkpoint and start from there. We added checkpoint before and after relatively hard and tricky obstacles so that player won’t get too exhausted working through them.

(Game ending)

Our first idea was letting player change slime’s size by eating drops on the way, but then we think that this mechanic is too hard to control the difficulty of the game, should we make the drops’ appearance random or by design? How should we tune the density of the drops? Also we think letting players eating different drops to shrink or expand their size would make it more like a strategy game, which is not the aesthetic we are after. Thus we decided to let player change Slime’s size by using arrow keys and they can change their size whenever they want, and the obstacles will force them to change their sizes. This way we can achieve the challenge aesthetic by practicing player’s skill.

We didn’t think of adding checkpoint before our first playtest, because we think our level was easy enough. However through the playtest we realized that some of the obstacle is really hard for players to go through and adding some checkpoints could really help encourage players to try again and again.

2. Description and analysis of final playtest

We had two play testers in our final playtest, and we would say their experiences were very similar to each other. They both passed the first few obstacles smoothly which means our coins are working as we expected. They know they can and they should collect the coins without being informed because this is kind of a universal law in all the games, and because of that, they were jumping at the right time and passing the obstacles successfully.

From our last playtest, we know that two of our obstacles are hard to pass. When we discuss about that, we think it’s not a bad thing to have difficult part in the game, and it will enhance the feeling of challenge, so we kept both of them in the game but put them in a rather latter stage of the game, and also added checkpoints around them to reduce exhaustion. In this playtest, to our surprise, they didn’t fail at the first obstacle - the volcanol obstacle (see the image below) - as much as they did in the last playtest. We believe it is because they have gained experience through last playtest by playing or watching other people play. Thus we think the difficulty of this obstacle is ok because players can get good at it by doing not so much practice. The other obstacle was as we expected, players were stuck there for most of the time during the playtest, and they managed to get through it at last, so it proved that this one was a hard one but not an impossible one. Plus, according to the playtester, our checkpoint really helped, because without it, they would have gave it up by now.

The problem is our playtester have pointed out that our current level is too short and the level design is pretty thin, so that it wasn’t very playable, after a while it will gets boring to players. Thus, there’s still a lot potential in our game, and we will talk about how we are going to improve it in the Projection section.

3. Lessons learned

3.1 What insights were gained about how players experience games.

From making this game, we learned that people won’t simply give up the game when they face difficulties, on the country, it may encourage them to engage more. Like in our second playtest, we didn’t expect the volcano to be a really hard obstacle, and when our playtester kept failing at going through it, we thought our playtest was just going to end there, but failing at it actually stimulated her somehow, and she got really engaged at it and kept trying until she finally went through.

However, playing game is not player’s job, if it’s too hard or too boring, they’ll quit eventually. Thus, we must find a way to balance the difficulty and player’s exhaustion. In our game, we think the checkpoint was a good way for the balancing and even when players already get tired, they are still trying because of the checkpoint.

3.2 What insights were gained about building a specific aesthetic experience through mechanics.

For the challenge aesthetic, we have learned that to give players a sense of challenge, the difficulty of the obstacles is crucial. If we successfully tuned their difficulty, they will generate the challenge aesthetic pretty straight forward, and with different design, the obstacles can have different kind of challenge, so every time when players encounter the next obstacle, it will also help generate the aesthetic of adventure and maybe a little bit of surprise. However, if the obstacles’ difficulty were tuned badly, all the aesthetics will gone. If the obstacles are too easy, the game is boring, it they are too hard, players will quit the game.

Also, to build the challenge aesthetic, we need to give players a break between difficulties, so that they’ll have enough energy facing the next obstacles and still feel challenging instead of exhausting. Thus we should place some easy obstacles between hard obstacles.

3.3 What communication and collaborative processes we would bring forward to future projects.

The most helpful and fruitful form of communication in the process of this project was the team meetings. We always have new ideas about our game, and at first we simply pass the new idea as messages one by one, and it was not efficiency at all. When we realized that, we begin to have team meetings every few days, and they really helped to get everyone on board at the same time. Plus, the meetings were a great opportunity for every team member to ask questions when they are not clear about something; to negotiate with each other when they have different opinions; to discuss about our next steps and record all ideas. This is a really effective communication way and we would bring it forward to our future projects.

3.4 What communication processes we would change for future projects

In the future, we think it would be better if we could use more visual communication tools. Because we found that even just some doodles on paper is more efficient than words. Images help explain our ideas and help others to understand that idea. In this project, we only used visual communication for once when we were discussing obstacles, and it was really helpful. Thus, we would bring more of visual communication into our future projects.

4. Projection

Now, our game is done - for the semester project. But one can’t expect its developers to just forget about it just because “it’s done”, at least not anymore. So, let’s move on to the possible/probable changes in the future. The list about to talk has no particular order in terms of priority because as of now, the answer to if we should polish the current game or add more elements is up in smokes.

• Expand the Size of the Level: This refers to expanding the size of the current level. We think our present level is good. We placed easy obstacles in the front and hard ones in the end so that players can feel an increase of challenge, and players can pass the level but not without a little practice. However, our current level is too short. Not short in a way where the players would feel so, because we have crazy hard obstacles. But now that we’re using checkpoints, I think we can go beyond our original size of a level and increase the size of each level that to be designed, just to make it more challenging. As of now, we are thinking to design more kind of obstacles that can stimulate more kind of player skills, such as multi-jumps. We are not sure if this is a thing, but we are considering the possibilities. Plus, as we mentioned before, we would consider to place more than one hard part in one level and we would separate them with some simple obstacles so that players can have a break after going through a tricky one.

• More Levels: As we said earlier, we were initially going to design at least 4 to 5 levels. But a mere 2 months proved to be too short a time for us to be treading that path. So we designed one bigger level. Eventually though, we will be designing more levels - filled with new obstacles, new terrain, new movement mechanics, new power-ups, basically a new theme. We have plenty of ideas. Ocean - where you will be swimming instead of walking. Space - where you will be floating, Jungle - where you will be running and a lot more. How many you ask? Only time will tell.

• Animation: One thing we definitely will be doing is adding the animation effects. The method of adding these on game maker studio is really simple - you just add multiple images onto a single sprite. That’s it. And we will be adding a lot of them. Right from the movement and actions of our slime to random events happening in the background. We will also be adding minute things like lava popping out of the volcano.

• Power-ups: Now what fun is a game if you don’t feel invincible every once in awhile? So, going along these lines, we will be adding the choice of picking up power ups mid-game. These will be popping up in the game screen at random. The range is also quite large. As of now, these include a boost in movespeed, constant jump ability, blink/teleport forward and complete invulnerability. More yet to come!

• Add a Back-end Memory: This literally translates to make the game remember things. Two things to be done with this. Add the mechanism of maintaining a list of the highscores. This will definitely help in making the game more competitive than it already is. Secondly, add the option of loading a previously saved game to continue playing it. If we are going to implement the previous two changes we talked about, one cannot beat the game in one sitting. This asks for an implementation of the “Load Game” functionality. The name speaks for itself and the player will be able to continue from the point he/she left off in the future.

• Uphill Treading: This has been a really big issue throughout the development of the game. Midway through the game, we had idea of allowing the player to tread uphill, at least on certain obstacles. To do this, we should be using build-in physics system of Gamemaker- something which we were not doing. This happened after the 2nd playtest and it too late to be adding such mechanics which require the entire script to be changed. However, we were and still are pretty sure this mechanic can be achieved without the use of physics. It is just really complicated, especially since we are talking about a foreign object. But once we figure this out, we will be adding an entirely new mechanic to the game!

5. Team description

We had a great team working on this project. Our collaboration and communication was all well performed and they all served helpful functions for our games improvement. It is true that we didn’t always agree with each other all the time. To be honest, we almost always have different opinions when making decisions, but different opinions were not holding us back, we know how to negotiate within the team. We would first explain ourselves and then talk about the advantages and disadvantages in each choices. This way, all of our argues worked out fine and we believe we have made good decisions for each of them.

We had both online and offline communication forms and we think they all increased our efficiency. For communication tools we mostly used Whatsapp to exchange ideas and set up in-person group meetings, and we used Slack to upload and share all the documents about our game.

As for our roles in this project, Suraj and Shi were focusing on the technical part and Jing and Filiz were responsible for the art assets. For the concept design, mechanic design, theme design, discussion about improvements after each playtest, and blog posts, we all did them together. We love working with each other, and we would choose this team again if we were to do another project in the future.