The End

The game development process is done and we’ve finished the game. The end result was according to plans. As we progressed with development quite a flaws in the design. Our group had some communication problems and we never seemed to be able to be flexible enough to do important changes to the design.

The development process went quite well and we had no trouble reaching our deadlines in time. Many team members wanted to stick the concept document which I found quite boring, since is made it hard to iterate and make changes to the game during development.

The basic concept of Umibozu relies quite heavily on the art style. The game is about a Japanese folktale of a mysterious sea creature. We wanted to have an art style with mostly black and white assets and a paper feel to it. We wanted the player to get the feeling that the art resembles reading a book.

The artwork turned out pretty well. For the next project I hope that the programmers will work more closely with the artists to make things smoother and avoid misunderstandings, but the overall results turned out quite well.

We had a sound designer in our team so do out musics and sound effects. He did an amazing job and the sound in the game turned out great!

The programming during development did not pose any bigger problems. The 2D space-shooter style game is not especially hard to program and the only problems we encountered was with volumetric lights and making the fog look good.

Fog in a 2D game is not that easy to get looking right. Also from a game design perspective I don’t think fog really adds to the experience of a game like this.

Since this was our first project in Unity game engine I’ve learned a lot about using the engine and scripting in Unity. I’ve also learned that in order to make a game that is fun to play, an iterative development process is needed. The hard part is to be flexible enough to scrap things that don’t work and be ready to try new things.

// Emile Sohier

Play testing the mystery

During development we’ve had two play testing sessions.

The first one was in a quite early stage of development, which meant we were mostly focusing on basic game mechanics. During this play test we only had basic movement, shooting and random spawned enemies, which limited the feedback we were able to receive. The feedback was mostly related to the looks of the game, with the flashlight, the mist and the vibe is set.

The second play test was between the alpha and beta build, which meant we were much further along in development. However we had still not had time to focus that much on balancing and level design. We were working on the level transitions, preparing for the boss battle, and making the game play fit with the story line of the game.

In order to get feedback on those elements we decided to remove the loosing conditions of the game so that players would actually get to the story points of the game. This was probably a mistake since we missed out on a opportunity to test out difficulty level and our communication towards the player.

Now that the boss is done, and the game is near completion, it would be nice to have some more play testing. I think it would have been beneficial to have one additional play testing session, or just delaying one of the two we had. It would have been very useful to have a session after the Beta presentation since that is when everything is coming together.

To remedy that we have decided to make sure to use the play testing group on slack, so that we can get feedback on the entire product and the game balancing of the “finished” game.

The points to focus on during these play tests will be visual communication to the player of whats going on, game balancing  during levels, and overall difficulty of the game.

If we would have had the play testing affecting out planning more from the beginning we would probably have prioritized our work a bit differently. However I don’t really consider this to be a problem since it’s not hard to find play testers even if it’s not a scheduled session.

Designing a Boss

This week (or last depending on how you look at it) has been mostly about getting the boss designed and scripted.

Our aesthetic goal for Umibozu is mystery, and in our boss fight is more a “run away from the boss” than actually fighting it.

So the layout is as follows:

The player goes out from the harbor in search for a missing person who allegedly was going into the mysterious waters where Umibozu is rumored to roam. After sailing through the mist and avoiding cliffs and sea creatures, the player finally arrives to the island where the missing person is shipwrecked. Apparently the person has been victim to Umibozu. The person quickly jumps on board and the player turns the ship around to head back towards the harbor.

This is when Umibozu makes an appearance.  To maintain the mystery of the mythical sea creature we chose to only show a dark shadow of Umibozu following the player under the water surface. The boss has two attacks, that the player needs to evade to make is back to the harbor safely.

The first attack is spawning whirlpools in the vicinity of the player. These are scaled up from nothing to their full size in order to visualize that Umibozu in spawning them. Their life span is only a few seconds but many spawn. This forces the player to be on high alert to avoid them and not be placed to close to the edge of the screen, in order to have time to detect them. The whirlpools also spins so that it looks more logical.

At the same time the dark shadow of Umibozu follows the player. Umobozu has tentacles that he launches across the screen to try and grab the player ship. These tentacles are positions just outside of the screen. Every 5 seconds one of the three tentacles is launched across the screen which forces the player to either fire the harpoon at the tentacle, to interrupt the attack and force the tentacle to retract, or just adjust the position of the ship to that the tentacles miss.

I am pretty satisfied with the result of the boss “fight” and the atmosphere is adds to the player experience. Out next step is going to make sure we have a few game testers so that we can balance the difficulty and make sure the experience if within reach for the players.

 

Comments Course 5SD064

Week1:

https://wordpress.com/read/blogs/142440897/posts/20

Week2:

https://thecodingspartan.wordpress.com/2018/02/15/2017-02-15-enemy-follow-move-towards-player-in-a-2d-environment-not-pathfinding/

Week3:

https://wordpress.com/read/blogs/138847846/posts/59

Working with Scrum

In our game project we’re working in we’re using the agile scrum method. Scrum is a method widely used in software development for breaking down development projects into the components within the project. This allows for the team to get a better overview of what needs to be implemented and helps in the planing process.

Scrum helps teams to handle volatility during the development process since often things change during development and the team needs to be able to adjust accordingly.

The setup we’re using entails Monday sprint planing meetings where we discuss what needs to be implemented during the upcoming week and divides the responsibilities within the group. All features get a priority and an estimated time for completion. Our sprints are one week long. See the picture below to get an idea of how the sprint planning looks, and how the elements in the game are broken down into fragments.

During the week we have a few stand-up meeting where we can discuss progress and how the work is moving along. If we have discovered any new features that are required to make things work, or if any new assets are needed. This makes us flexible and able to adapt quickly even during sprints.

On Fridays we meet up for a sprint review meeting. This is a summary of the work week where we can assess how the weeks has been going and how much we’ve achieved during the sprint.

I think the method is working quite well. It is helpful to have all features broken down into assets or smaller parts for planning reasons. Everyone automatically gets a to-do list which helps with planning on a personal level and gives an overview of how much work is needed.

Short sprints are also helpful since every team member has a shorter time span to complete their respective responsibilities, which makes sure all assets for a specific features are available at a specified time.

Overall I’m quite happy with this work method. I think it’s a good way to collaborate between disciplines and with different people having different responsibilities within a project. It helps with both planning, overview and workload distribution.

I hope this has been helpful for you as well!

Unity Collaborate problems

So this week we’ve had quite some problems using Unity Collaborate. Samuel, our other programmer in our team has done a lot of work during last week, and when I’m trying to get the changes a lot of issues arises.

Unity Collaborate is a tool used by teams to sync and maintain a project within the group. When working correctly that means that several team members can work on the same project and then upload their changes so that everyone in the team can download them to their local project folders.  A very powerful tool for small teams!

The problem with this is that if more then one person works on the same content, conflicting versions of assets seem to be quite common. Unity then seems to delete these assets since they are corrupt, and you end up with incomplete projects and/or corrupted assets.

So this week we’re on a deadline for the alpha presentation, and at the moment my responsibilities are to add a basic GUI and work on the game mechanics for the power ups. The problem is that the only recent build I can access is missing so many crucial components it won’t even run.

On the Unity Dashboard web page you can access a Collaborate timeline which specifies the changes made by the team, or maybe rather changes made be the team and Unity during the upload process. This game me some clues as to what has happened since I noticed that the camera was gone. In my unity project I also noticed that some game objects were just listed as “missing prefab”.

After replacing the missing prefab with a new camera prefab that we had been using in the project before, I was able to run the project again. However I noticed that there is A LOT of other stuff that is not working anymore.

I’m giving up on this at the moment since I don’t really want to spend an entire day trying to recreate something that Samuel hopefully has working in his local version on his workstation. So I’m hoping for him to wake up soon so that we can resolve this the old fashioned way, by manually sending .zip files to one another.

During my attempts to solve this I’ve done some basic research on what the cause to these problems might be. What I’ve read is that Unity Collaborate usually works great with scripts and and most simple assets, but is problematic with scenes.

Moving forward I think we need to communicate more and make sure we’re not working on the same scene at the same time, since that might be problematic. One solution that some people seem to be using is working on copies of the main scenes and then merging them when they are sure no one else is doing changes.

An other important part of avoiding problems with Unity Collaborate is to make sure that whenever you’ve made changes to the project, make sure to upload them! The reason for this is that if I work on a scene, do not upload my changes and then a few days later try and download someones changes to that same scene, I will most likely get conflicts. If I make sure to upload what I’ve done, and the others in the team make sure to sync before they start working, our progress will always be on everyone’s workstations and we will hopefully avoid conflicting version history.

To conclude. Unity Collaborate is a great tool for small teams working on the same projects. Just make sure to be disciplined and communicate with another to make sure you’re all up to date with the latest changes and everyone has a version of the project of the latest version. Also don’t work on the same scenes at the same time. Make sure to upload your work after every session, and download others changes before every session.

Let’s hope you get less problems than we did!

 

Projection and volumetric light

This is the first Unity project I’ve been working on, not counting a few tutorials that I’ve been playing around with in the past. In order to get a proper understanding of the game engine (and when I say proper, I mean basic) I started out by spending quite some time following an online course hosted by Udemy.

I started researching camera projections and the difference between a perspective projection and an orthographic one. I drew the conclusion that a orthographic projection might be easier to work with, since that would entail that I do not have to consider positions on the Z-axis for more than rendering layers. Basically perspective projection takes into account the distance of the object from the camera, and the angle offset it creates. Orthographic projection does not take into account the distance from camera to object. See picture below where the left one is perspective projection and the right one orthographic projection. Picture from stackexchange.com.

I started working on the alpha build and everything went along quite well. Until we implemented a volumetric light as a searchlight for the player avatar (which is a fishing boat). For some reason the light would not follow the camera completely. After some testing I found out that the offset from moving the player, and therefore moving the searchlight, which is a child of the player was about 1/2. That is, if the player moved 2 units on the x-axis the searchlight would only move 1. This was quite an issue since the light is supposed to be attached to the player avatar.

After some more research I found out that orthographic projection does not support volumetric light. Weird I thought, since the light was there. Almost working as it should.

Anyway. I then tried switching over to a perspective projection camera and after making sure that all my game objects were on the correct Z-position (since this now matters) I tested the prototype again. Lo and behold, the searchlight now followed the avatar as intended. This however gave me a few other issues as some scripts that worked with no issues with orthographic projection now did not. Quite easy fix and the prototype was fixed!

Added a second volumetric light as the player avatar was supposed to have a lantern lighting up the close vicinity of the boat, as well as the searchlight rotating its direction relative to the player avatar.

The Journey Begins

Thanks for joining me!

Good company in a journey makes the way seem shorter. — Izaak Walton