Posts

The Final Presentation – Process and Afterword

I was personally rather dissatisfied with how our last presentation turned out, granted we didn’t spend enough time on it, due to me being plagued with serious migrane on the day before, when we met to work on the presentation. So this time we decided to start working on it a lot sooner, so we met after our Group Mentoring Specializations on Wednesday, January 27th.

The first piece of the presentation was a document by Anna, who had written down some of the most important things that need to be in the presentation. We then had the idea to “put the presentation in the game”, which at that point was limited to simply making slides, and showing them in the prototype while walking past it and talking about it, much like a normal presentation would be.
After we didn’t get to work on the presentation as much as we planned to on wednesday, because we prioritized the prototype, Patrick started working on the presentation after we went home, orienting himself on Anna’s document.

Friday

I spent most of my working time on Friday intending finishing up the Mentos-ColaLake puzzle, and make it easy for Patrick to implement in his project files. During this time Patrick worked hard on making the presentation as cool as possible, quickly moving away from the “show slides next to another” to the experience that it eventually turned out to be. We gave him feedback whenever a question came up, like how the artists want their assets to be placed, or how he should word some things, but didn’t really get to see what the whole thing looked like until the day after. While the rest of us went to bed between 1am and 2am, Patrick had worked through half the night, uploading the project files for the presentation at 5am!

Saturday

On Saturday, the first thing I did when I saw the project files was simply starting the “game” and walk through the presentation. You can imagine my surprise when there was suddenly no floor, and Pan kept falling “deeper and deeper and deeper…”! I was extremely impressed with the work Patrick had done, so of course the first thing I did was nitpicking ! I went through the presentation a few times and noted down everything that I felt could be improved, and how I would do it. I also read the syllabus a few times, to make sure we include all the important things. We had a lengthy skype conversation we anna also went over the presentation, to add her feedback to mine.
While Patrick was working away on implementing the changes (it was past midnight by then), I had to work on the ColaLake-Mentos level again, because the way I did it before didn’t quite work out, the platforms were to small, or the lake to wide, so I had to add a third platform, and redo the animation for the second one. I finished that up until 3am, and tried implementing it in the project I got from Patrick and it worked as intended (with minor issues).

Sunday

Sunday was long for me!
Patrick and Caterina started chatting at 12am, I joined a bit later and Anna as well, and we continued optimizing the presentation.
We were still missing something for the “reflection on development process including a detailed project plan”, as we weren’t entirely sure how we should best convey it all. Eventually we decided to use the Project Plan as a timeline to show what happened.
First I went through all of our chat histories (Skype and Whatsapp) and added mot important dates to the project plan, writing them below the timeline, so one can quickly see what the plan was, and what actually happened. I realized that it was incredibly bland to look at, so I decided to remove some more of the less important dates, color coded everything (production, design, art, programming) and made the more important dates even more visible. I finished up with the Plan at half past midnight.

Versions 1, 2 and 3 of the Project Plan Show

After taking a small break, I wrote a script (performance) for how we could do the presentation. For this I once again walked through the presentation a few times, and wrote down what exactly I would say, paying close attention to how long each part would take me to say. Along the way I noticed a few more things I’d like to change, and those were implemented the day after. I was done with this script at 4:30am, quickly uploaded it to our dropbox and fell right into bed.
The script I wrote for the presentation, we mostly stuck to that!

Monday – Presentation Day!

We had decided to meet at 10:30am on Monday morning, to put the finishing touches on the project files/presentation, decided who said what, and make sure the timing works out as planned. Anna wasn’t quite happy with the gameplay portion of the script I wrote, so she changed it to point out some more things that I missed. She also wrote down things the artists could mention about their process, as I as a non-artist couldn’t think of anything.
Caterina was also fighting, as she had to deal with a terrible migraine, but she managed to still do the presentation without a problem!

Feedback

I was very happy with how our presentation turned out, and the feedback we got was mostly positive too!
However we made one major mistake, which is the part of the gameplay we showed.  We just started at the beginning and showed how it all looked in-game, and since the beginning of the game is rather unexciting, it didn’t make as much of an impact, and didn’t show as much of the game that it could have! Instead we should have shown the ColaLake puzzle, even if that meant skipping most of the level before.

We also received good feedback for the game, most notably that the environment feels “dead”. We hadn’t noticed that ourselves, but I knew what was meant by that, there is not much movement in the background, almost everything is static. We’ll work on that after wednesday, until the 19th.

Throwing stuff and respawning changes

I’ve mainly been working on two things at the moment, which is coding the throwing for the last puzzle and a proper/pretty respawning process. Both are not 100% polished yet, but they work, and I’m confident that they won’t make any trouble implementing.

Throwing

For the throwing we decided on using a kind of gauge that decides the angle, so the player will need a mixture of planning and timing skills to throw the m&m in the right angle. Here’s the result first:

Things that are still TODO with this mechanic:

-limit throwing speed (rof)
-finetune positioning of angle-gauge
-use proper animation of Pan
-how to leave the throwing state
and the rest of the puzzle itself, the mentos stalactites, platforms and fountains!

The throwing mechanic mainly consists of two pieces of code, the first in the “PlayerInteractScript”, and the second in a “ThrowableScript”. As well as an animation for the red “Aimer” line to bob up and down, and a short animation for the m&ms to shatter.

Below is the relevant code from the PlayerInteractScript:

Screenshot_9

There are two interactions that deal with the throwing. The first is for entering the throwing state, which currently just starts the “Aimer” animation and enables the second interaction. The second interaction does the actual throwing. For this it uses the transform.positions of two objects which I manually placed at the beginning and the end of the “Aimer” line, subtracts one from the other, and uses the resulting vector to provide the direction for the throw, which uses normal Unity 2D Physics.

Next is the “ThrowableScript”. This script is attached to the m&ms that Pan throws. The Script simply detects collision with any object, and reacts accordingly. “TargetMentos” will be the object the player has to hit in order to solve the puzzle. When the m&ms hit any object (except the player) they will be triggered to enter the “Shatter” animation state, which is directly followed by the “AnimDone” state. Once in this state, the object will destroy itself through its Update() function.

Screenshot_3

Respawning

We hadn’t thought much about how we would do the respawning/death animations, but anna and I suddenly got the idea of “falling down the map and then falling on respawn from above”, and Patrick later expanded on it with the idea of the blackscreen to smoothen the transition between locations. So for this I had to redo the whole death/respawn/reset-progress code AGAIN because it wouldn’t look nice as it currently was. But I managed to reduce it a fair bit. Even then, it still looks like a bit of a mess, but to me it makes the most sense like this. The code for this process is almost entirely in the “PlayerInteracScript”, and I’ll go through that in the order the program would go.

The first method is Kill(), which is called by anything that can Kill Pan (like the chocolate River), giving the ‘killing object’ to the method via constructor. This method primarily disables the level-floor’s collider causing pan to fall through the ground and sets the trigger for the camera’s ‘DeathZoomAnimation’. It also causes Pan to do a little jump, and sets the global variable deathCause.

Screenshot_61

 

After the CameraZoom has completed its animation it calls this function:

Screenshot_52

It instantiates the blackscreen and puts it below the player, directly below the area the camera can currently see. It also sets the deathBlackScreenInstantiated bool to true, which sets the Update() function in action next and destroys the colldier that made pan go up, causing him to fall down from now on!

Once the blackscreen has been instantiated, and now that pan is falling, the Update function will let pan fall until a certain point, where the camera only sees the blackscreen, and calls the HandleRespawn() method.

Screenshot_10

The HandleRespawn() method reenables the floor collider, so pan can land again,  and calls the appropriate ResetProgress and Respawn functions (see below).

Screenshot_82

Respawn() simply relocated Pan and the blackscreen to the pre-set respawn location.

Screenshot_7

ResetProgress() resets all progress behind the specified respawn point to it’s default calues.Screenshot_4

And here is the result (you may want to watch it twice, first the Game-view, then the Scene-view):

The Ghost of the Player-Object

This is a really strange bug I experienced, which I don’t entirely understand. To me it felt like a ghost story and I’d really like to share it with everyone, so I’m trying to make this as easy to understand to non-coders as possible!

Screenshot_3

This “KillZoneScript” is attached to a river, which is supposed to kill the player when they touch it. It does two things: The first is that it find a reference (basically a hyperlink) to the  Player-Object when the game is started. The second is that -when the player touches the river- it tells a script that is attached to the Player-Object to run a method in it, which will do the actual death animation etc of the Player.

Now while I was working on implementing an improved death animation of sorts it bugged out -the Kill method wouldn’t be called- , so I did some reconnaissance:

Screenshot_6

Using lots of print functions, and trying to make the program tell me exactly WHAT happens and WHERE the bug is located, I found out that the reference to the player was wrong. This version of the method told me the object it was referencing is named “Player(Clone)” instead of “Player”,as it should be named. So I started suspecting that I might accidentally have tagged another object as “Player” which would explain this problem (the other object would be found instead of the correct one). Eventually, I made the program find all the GameObjects tagged as “Player” and tell me their names:

Screenshot_1

I learned that there were indeed TWO GameObjects tagged as “Player”, which are the “Player(Clone)” (gobjo[0]) that I noticed was weird, as well as the Object named “Player” (gobjo[1]), which had to be the correct object!

Now here is where the story moves from being like any annoying bug hassle to being a ghost story: The “Player(Clone)” object was nowhere to be found! In Unity, ALL objects are displayed in the so called “Hierarchy”, as below:Screenshot_7

And no matter what I did, searching manually or through the search function, whether it was while the game was playing or not, the “Player(Clone)” object would not show up!

I had one idea left, which I thought would serve to confirm my suspicion of the “Player(Clone)” object to be the one to ruin my code, so I changed the method to delete that object:Screenshot_8

Since I knew that “gobjo[0]” contained the evil Clone-Spirit-Demon, I made the method destroy that object during play, so I could see whether that would allow the rest of the method to work. I didn’t quite figure out yet how I would fix it in the long run, since anything that happens during play will be reset once the game is stopped. However as it turned out, I didn’t need to! Mysteriously, the “Player(Clone)” object was destroyed, and remained gone even after leaving play-mode!

And so the spirit of the Player-Object was banished to the depths of the GarbageCollector, and was never heard of again (?).

This was a bit of a weird post, but I really felt the need to share this. I hope I could entertain some of you, maybe even someone that is not an experienced coder!

 

Follow up, 4 days later:

Short follow-up:
The cloning happened again, while we were in a group meeting, and I eventually found out that the cause is somewhere in the mechanim (this user had a similar problem)
It can be fixed by just restarting the editor (how boring :P)

 

Programming Bliss

I’ve finally gotten to start programming. I took Patrick’s Unity Project and started by putting the current level layout in, and just ran around the level and tweaking Pan’s jump height and speed, as well as the level in terms of gaps and heights for jumps.The Original File is 4 times the size!

The bits of code I needed for this first part of the level (in addition to the character-controller that patrick had made) was the interactable lever which should cause the claw holding the box to open and make the box fall.

The first course of action was to make the player controller recognize that Pan is within reach of the lever. So I gave the lever a simple BoxCollider2D, which is slightly larger than the lever itself and made it an IsTrigger.

Then I attached a script with an OnTriggerEnter2D method, that checks whether the other collider has the tag “Player” on it. If it does, so if the player is within reach of the lever, it will tell that to the PlayerInteractScript, giving the GameObject of the lever to it. This Script can and will be attached to all interactables, as it doesn’t specifically targets the lever. The Script also contains an OnTriggerExtit2D method, which deletes the reference to the lever when the player leaves the area.

Screenshot_8 (1)

Next, or rather parallelly, I attached a new PlayerInteractScript to the Player object. This script will probably be merged into another script, but I wanted to keep it separated for now, as not to mess too much with Patrick’s script.

This Script holds a variable that contains the current interactable within Pan’s reach (GameObject interactable), and a method to set this variable (void NewInteractible). It also currently contains the input method for interacting with the object, as well as a hardcoded list of things that happen for each interactable (currently just the one lever).

Screenshot_11

Other than that I made a mockup animation for the claw holding the box (as referenced in line 41) which took me considerable effort, as I’ve not worked on animations before, and I had trouble with having a start and end position for the claw, before and after the animation plays.

The result can be seen in this short video (turn on sound for german electropop)

New Year

I was on vacation for the week before Christmas, and then over Christmas and New Year I didn’t get much work done either (or any really), but now I’ve finally started working on the level design again. Patrick had made a first draft of an intro/tutorial level, so I decided to start off  fleshing that out, and then working on a first level.

Intro Level Concept
First Draft that Patrick made

I started by writing down how I would imagine the level, leaving all sorts of gaps and questions about how exactly I would do it:

IntroLevel.txt Show

Then I started drawing it, even if my drawing skills are terrible, because I thought it would help me to give it exact dimensions instead of rough ideas, which it did!

introlvl

I used PaintDotNet, a tool that is somewhere inbetween MSPaint and Gimp in terms of power, but easy to use and enough for me anyways. I started drawing the exit of the level, then slowly drew the cave larger so there is room for the box and the lever to the left. I drew in a cross that shows the (rough) screen dimensions and moved it around the level to make sure that the starting screen shows the full controls, and the exit. Then I moved it further to make sure that the player can see the box drop from the claw when they interact with the lever.

I used some different colors, and intend to keep that color scheme for later level mockups, to help seeing the important things in the level.

Before working on the first level, I did some research on puzzle games (again), and learnt from one video, that “a puzzle has to make the player stop and think”. According to this video, the right order of events is “player sees obstacle > player thinks about > player finds a solution”. Although this should be obvious, I hadn’t thought about that yet, so now I had something to keep in mind!

So revisited the first level that we had started thinking about before, which was not much more than “gumball rolling down a slope to break through a wall, after that something with Mentos and a Cola lake”. I now realized that just triggering the gumball machine and the gumball breaking through the wall would be no puzzle, because all the player did was interact with everything they can, instead of thinking about what it is that they’re doing. I went back to writing things down before drawing again, because that worked pretty well for the first level.

gumdispenserlvl.txt Show

After that I started drawing. I took the intro level file, and took the screen dimensions from it. Using those I drew a cave entrance, a bit lower than the screenheight. I drew a “brittle wall” in it which would have to be broken by the gumball later, and then made a connection to the intro level. For now I just drew some slopes up, and put a gumball machine at the end, but I will work with the rest of the team on monday to finalize the level designs.

gumdispenserlvl

Dreams of Pan

As the project leader of Dreams of Pan, I guess I’ll be writing quite a lot of TEXT in this blog, I’ll see whether I can get some images in too though (I’ll just steal from the artists)

Our group was formed quite soon, Anna came with Caterina up to Patrick and me, as we were brainstorming together on the first day of the project-phase, and had the idea of dreams. We quickly realised that everyone could put their own ideas into each dream, and that we could make them as different as we want, as each dream would be separated from the other. The week after, on the second meeting, Taylan joined in. We then had the idea that we might make 3 levels/dreams, as we had 3 artists in our group, and each level would have their own artstyle in them. After the first feedback round with the rest of the students and the teachers, we realised that that probably wouldn’t work out well, as the game would look too differently, and it could well break the flow of the game. Currently our plan is to make ONE very well optimized and very enjoyable level in comparison to multiple levels.

The theme we settled on is “Candyland”. It will be a world that is made entirely out of candy. The base idea to this came from Anna’s artstyle, as it is very cutesy, and we figured that we could use that for the first level, and as we eventually decided on making only one level, that is what we ended up doing.

Pan
Pan

About the game: Dreams of Pan will be a Side Scrolling, Puzzle-Platformer. We’re still working on an interesting iterative mechanic that might give it a special feel, but we’ll have to see whether we can figure something out for that. For now we’re thinking about puzzles that could work in a candyworld, for that we’re looking up all sorts of candies, and throw ideas around about how we could use those candies to make a certain game mechanic with them. Currently we have a list of candies with special attributes, that we could make into puzzles.

One part of the level could look like the following (an image may follow):
Pan jumps down a cliff, and then walks up a hill, and sees a giant gumball machine. He’ll trigger it (through another puzzle), and a giant gumball will roll out of it, and chase Pan while he runs down the hill. Pan will find an opportunity to dodge the ball, and the ball will eventually crash into the cliff and break through the rock to reveal a path down. Down in the cave Pan will be confronted with a large lake of Diet Coke, with Mentos-stalactites hanging down from above. Pan will have to find a sort of raft and a way to drop some of the mentos down into the lake, which will give the raft a boost upwards, enough to reach a ledge above that he couldn’t reach before.

I’ve also made a Project Plan, currently not containing much information, but I will add to it as we go along.

Dreams of Pan Project Plan 12.12

Inspiration

In terms of pace we orient ourselves at Limbo, because we all feel that it has good pace, and that pace would fit our theme very well.

For the world and gameplay, all the candy stuff, I watched Wreck-it-Ralph, because it has a very well made Candyworld (Sugar-Rush game) that poses some dangers to the protagonists. I threw in the idea of living candy like in Sugar-Rush, but we all happily agreed against it.