Post mortem (supplementary hand in)

After many weeks of development, our game is finally complete. It changed a whole lot from our starting concept.

Navisy: Creatures of the Deep is a top-down shooter where the player takes the role of a curious fisherman setting out in search for a mythological beast that lurks in the depths. The game has the player steering their fishing boat however they like across an endless sea searching for artifacts that eventually leads to a climactic boss fight, fending off enemy squids along the way with the their trusty harpoon. The water is dark however and seeing without an artificial light source will do no good, so the player will have to manage resources such as oil for searchlights and flares to survive.

The game can be played here: https://avokadomos.itch.io/navisy-creatures-of-the-deep

I have learned a lot during this course. Being able to put what we have been taught so far into practise have proven very useful and thanks to our excellent project manager, who’s been very thorough and invested through out, we’ve been able to experience a little bit of what working in the industry will be about.

First, I’d like to start with what have gone well: we actually made a game. I have never been part of a project like this before and seeing it slowly come to life has been a great experience. Although the game wasn’t perfect, I am still very proud of it.

So what could have gone differently? How could we, and more importantly I, have made the game better?

One thing I noticed later on in the project was that the game lacked proper basis. The core loop didn’t present itself until 4-5 weeks in, and it wasn’t very good. At the beginning of the project, our group had the mentality of ”Oh, the game will be a lot better once we add X and Y”, when in reality, that’s not how it works. If the game doesn’t work after the MVP, then it won’t work at all.

The main mechanics needs to be tight and really well designed. As an example, let’s look at the 2017 title by Gears for Breakfast: A Hat in Time.

In A Hat in Time, the player has two major mechanics: jumping and dashing. The developers made sure that these two things worked and felt good before adding anything else to the game, building the rest of the game around these two things. The fact that the game would still be fun even if the player only had a blank room to move around in goes to show how much they succeeded. Our game never got its main mechanics down properly, so the rest of the game kind of fell apart because of it. It just got new layers on top while we ”winged it” sprint after sprint.

The arcade project is coming up and I couldn’t be more excited. It’s one of those fresh starts that only the education can provide and another shot for me to take what I’ve learned from the first project and try some new procedures. This time, I will make sure that the MVP works and that the core loop and mechanics are down before I do anything else.

Blog feedback #6

Hi August! Great post!

I really liked your setting when I tested your game. It is very refreshing to see something that isn’t Japanese folklore, like many of the others did for their Umibozu games (myself included).

It’s very sad to hear that you had so much trouble with bugs in your game, especially game breaking ones. Collision can be tricky to program and is often the source of a lot of frustration.

I didn’t complete your game (I died about half way), so I never really noticed it being too long, but there are a lot of things you can consider when gameplay becomes a drag. You could, like Kentaro noted here before me, create a better sense of progression, but that’s been said so I’ll come up with something else. You could consider the game feel or game juice, i.e. make the game more satisfying to play, listen to and look at. Maybe the last enemy you kill on screen explodes in fireworks or maybe killing three enemies in a row without taking damage gives you a super shot with awesome sound effects to use on the fourth one. Just something to break up the monotony. Also, pacing the game can do a lot, like spawning enemies in waves for example.

I also relate so much to your last statement. Keeping the average player in mind when creating a game is hard, we very much had that problem too. I’d be happy to play test anything in the future if you need a free lab rat.

Postmortem – Game Design 2.

I have learned a lot during this course. Being able to put what we have been tought so far into practise have proven very useful and thanks to our excellent project manager, who’s been very thorough and invested through out, we’ve been able to experience a little bit of what working in the industry will be about.

First, I’d like to start with what have gone well: we actually made a game. I have never been part of a project like this before and seeing something like this slowly come to life has been a great experience. Although the game wasn’t perfect, I am still very proud of it.

So what could have gone differently? How could we, and more importantly I, have made the game better?

One thing I noticed later on in the project was that the game lacked proper basis. The core loop didn’t present itself until 4-5 weeks in, and it wasn’t very good. At the beginning of the project, our group had the mentality of ”Oh, the game will be a lot better once we add X and Y”, when in reality, that’s not how it works. If the game doesn’t work after the MVP, then it won’t work at all.

The main mechanics needs to be tight and really well designed. As an example, let’s look at the 2017 title by Gears for Breakfast: A Hat in Time.

In A Hat in Time, the player has two major mechanics: jumping and dashing. The developers made sure that these two things worked and felt good before adding anything else to the game, building the rest of the game around these two things. The fact that the game would still be fun even if the player only had a blank room to move around in goes to show how much they succeeded. Our game never got its main mechanics down properly, so the rest of the game kind of fell apart because of it. It just got new layers on top while we ”winged it” sprint after sprint.

The arcade project is coming up and I couldn’t be more excited. It’s one of those fresh starts that only the education can provide and another shot for me to take what I’ve learned from the first project and try some new procedures. This time, I will make sure that the MVP works and that the core loop and mechanics are down before I do anything else.

Blog feedback #5

Very nicely written Carl!

I think your post is the most well written I’ve read so far. It’s very nicely structured and super easy to read. It’s also very nice to have the graphs in front of you while reading to accompany your thoughts and descriptions.

You describe the process of playtesting (how you go from feedback in a questionaire to tweaking the game accordingly) very well. It is hard to keep viewing one’s project from the outside looking in, so things like (as you mentioned) bad pick-up sprites might fly by unnoticed. You display very clearly why and how getting external feedback is important and how it affected your game for the better, which is nice.

I actually don’t have any feedback for your post at all, except for maybe resizing the pictures better. They were stretched a bit weirdly.

All in all, very well written post and an interesting read. Hope your game turns out good for release!

The power of playtesting

At the start of the project, we decided to make some fundamental changes to the mechanics. Among other things, we changed the way the player moved. I have talked about this in an earlier post so I will keep things short, but the general gist was that we wanted to make the player feel like he/she was on an actual boat. We achieved this by having the boat rotate on an axis instead of instantly strafing left and right as well as adding gears. You can read the full detail on the changes in my earlier post.

Along came the first playsession with the class. People were allowed to play other groups’ games and give some candid feedback. We got lucky and got a spot in the middle of the classroom so lots of people got to play, which means that we received a lot of feedback.

We used a questionaire to receive feedback, so after playing, people could leave their feedback in a quick and easy way on the same computer. Among the questions we posed, one of them was ”How boaty was the movement?”, i.e. did you feel like you were controlling a boat?

As you can see, pretty boaty. However, it can allways be improved. When we spoke to participants post-test we found out that something was missing. People thought the movement was sluggish and un-intuitive. We decided to improve it.

Turning.
During the alpha, the turning rate of the ship remained the same no matter what gear the player used. We changed this slightly, now the player will turn sharper when going slowly and make wider turns when going fast. This is something that, to me, felt like a natural feature when playtesting and a no-brainer afterwards. It also gives the player a reason to go into slower gears as it makes it easier to make precise turns and collect those hard-to-get power ups.

Speed.
Some people mentioned that they felt like the ship was too slow. Now, this is very much a question related to how fast everything else is, but what we could change is the difference each gear makes. We gave the top gear a bigger kick to it, faster acceleration and top speed while making the lowest gear slower. We also sped up the reverse gear to make it more useful.

So, that is one way we improved our game. It was important to us to really nail player movement for our game, as it is what the player will be doing most of the time.

Blog feedback #4

Hi Amanda!

Great post! Well written and structured, it’s very easy for the reader to grasp what you’re talking about. I am the sound designer for my group as well, so reading about other groups’ sound effects is really cool. I particularly like how you layer sounds that people usually wouldn’t consider, like the whale calls and cicadas, to get a very different effect. It’s very creative!

I would, however, have liked to be able to listen to your sound effects. Maybe uploading them to an audio hosting site like Soundcloud could help? That way, your sounds can accompany your post and the reader can listen to them instead of imagining them themselves. Just a thought.

It would also be nice to know how you go about making the sounds. What programs do you use, for example?

All in all, good read. It’s nice to see other sound designers’ thought process. Very useful for inspiration.

Something wicked this way comes

While finishing up for the Beta, I have been working on the most prominent track in the game: the boss’ theme song.

Our game, based on the Umibozu concept document, features a large sea monster as its final boss. While the original concept document drew heavily from Japanese culture in both art and mythos, we decided to go a different route with a steampunk setting instead. So, instead of having the ”Umibozu” (sea monster from Japanese folklore), we have the scary Kraken to more fit with the setting.

I have never written boss music before. My personal music is very mellow and soft, something that boss battle music generally isn’t. First, I looked for inspiration. I needed something epic, something that really feels like a big finale. I needed Dark Souls.

The Dark Souls soundtrack features big, swelling orchestras and plenty of choirs. They certainly feel epic and grand. This track from the Abyss Watchers’ boss fight is a favorite of mine and the church bells at the beginning give me chills every time I play the game.

Now I know what I’m kind of looking for. Something swelling and grand. Strings are a must have. Now, how could I make it fit more with the setting? How could I make it sound more like the Kraken? I got an idea.

For the few people who haven’t seen the Pirates of the Caribbean films (first of all, how?), this is Davy Jone’s theme song, the dreaded ghost captain who just happened to have a pet Kraken. The track already reminds me a lot of Dark Souls and boss battle’s in general, which it basically is. Plus, it certainly has a feel of sailing and seafaring, which fits perfectly with Umibozu and our Victorian-esque setting. Also, I needed that music box from the intro.

I started working. I began by writing a small and simple melody which later would run through the entirety of the track. I wanted it to be a bit more up-tempo than the Davy Jones theme, so I sped it up and moved it over to a 4/4 tempo. I plucked the notes into my digital audio workspace (I use FL studio for those wondering) and added a small plug-in synthesizer I found online called DSK Music Box. My intro was done.

Moving on to the bridge and build-up, I wanted something monstreous. Something akin to a big monster roar. Turns out, if you pitch down a fog horn from a real ship, it sounds really interesting and just like a monster. I used it as the bass through-out the song. Now, the sound can’t just be music boxes and fog horns, I needed some chords and clav. For the chords, I wanted a lot of dissonance. What this means is essentially building chords in such a way that they sound ”false”, done by inverting and moving the notes up and down the octaves (so, going from e.g. C5 to C6). The Sherlock Holmes soundtrack is a good example of this (watch the volume for this one):

What this does is making the listener feel kinda un-easy, like something is off. Certainly gives off a spooky feeling. Again, fitting perfectly with our boss battle. It also helps alot to have the piano out of tune.

So, here’s the final track:

In this big mish-mash we have: Davy Jones’ music box for familiarity, Dark Souls’ swelling orchestra for epicness, Sherlock Holmes’ dissonant piano chords for discomfort and edited fog horn roars as bass. I think it turned out quite nice. I also added some tribal drums and chants to give that feeling of ”ancient evil” and folklore, for lack of a better term.

Blog feedback #3

Hi Sofie, good post!

Scrum is indeed a great way to work and splitting the work into sprints is a nice method of seeing how far you’ve come, how far you’ve got left and how things need to change.

You seem to know your way around scrum, I don’t have much to add. You did however mention that your group had some problems when your project manager wasn’t present, and I’ll add to that by saying that we have had a lot of lectures in scrum in our design minors. If something similar happens again you can always turn to your designer who should be able to scrape something together fairly easily.

If I had to provide some constructive feedback I’d say that having the “What”, “How” and “Why” subtitles can make the post seem unprofessional in a way, like following a bullet point list. But that is just me nit-picking at this point. All in all, good post!

Blog feedback #2

Well said Axel. Your post is well structured and fairly easy to follow. One thing I have to note is that it’s pretty hard to understand the whys behind the redesigning of the enemy. Or rather, I could use a longer explanation. You mention that the original design both lacked a sense of mechanics and had too complicated mechanics. How? An explanation or a visualisation of the original design would be great here, some simple drawing perhaps. The only thing I can pick up from your post is that it flies in formations around the player. You also mentioned that it didn’t fit the aesthetic of the game. Again, how? How and why does it not fit with the aesthetic, what is the aesthetic, etc.

Otherwise, good job. As Kentaro said before me, user stories is something we rarely see in our group so it is nice to see them in action. It is always interesting to see something go from an idea to a fully fledged asset.

I did also find some grammatical errors (“This is originally called The Skyslug” for example), but that’s just me nitpicking.

All in all, good read!

Blog feedback #1

Your post is clearly made and explained simple enough so that someone who knows very little about line art, like myself, can understand. You state what the post is about early on and keep the red thread through-out with very few to almost none tangents. By the end I understand exactly why paying attention to line art is important and how it affects character design, perceived character personalities and how it can work with the game aesthetic. The post is easy to digest and leaves the reader with some desire to read into character design further. It also sparks conversation and discussion about design in general. It’s also a pretty enjoyable subject!
I don’t have much feedback for improvement, except maybe having example pictures of how a character’s personality can be changed with line art, but that is just me nit-picking at this point. All in all, a well written post.