Dókano is a 2D multiplayer game, centered around laying traps and being the last player standing. Players move around a game board in real time, dropping a variety of invisible traps as a timer ticks down. Once the timer reaches zero, all the traps are revealed and any players unfortunate enough to be caught inside one get eliminated from the match. The last player remaining is the winner! Dókano is built using the Unity Game Engine.
At our first sprint planning meeting, we decided that our goal for this sprint was to implement basic game mechanics such as the playerboard, grid system, character sprites and basic game design. The idea was to lay down a foundation so that each team member could work on individual tasks. In order to do this, we selected the following user stories as being of highest priority, and played planning poker to give them each a story points value. Story points are given in brackets.
Taking the uncertain situation of the world into account and being forced to work remotely, the start of the project was a success. We met virtually on monday morning and dived right into the goal of making a multiplayer 2D-arena game using scrum and agile methodologies. The team split into pairs and started tackling tasks from the storyboard.
We also started looking into both server functionality through trying to implement an online lobby system as well as the overall game logic to start connecting all of our building blocks and giving them meaning. Lastly, we tried to make sure our git workflow is top notch by among other things establishing a work protocol through the use of branches in git and scenes within Unity.
Overview of the storyboard using clubhouse.io
For our second sprint planning meeting, we made it our goal to finish implementing and polishing all essential game mechanics including sound effects, as well as having a solid amount of animations and also starting to implement server side in-game functionality.
During this sprint we made some final decisions regarding which direction to take in regards to our server setup and character selection screen. So far we have been using an exploratory approach concerning the development of features, in which we start working on two different alternatives and then decide which one to keep. The reasoning behind this being our lack of experience and using this also as an opportunity to learn as much as we can. However, we did find it difficult to actually make the final decisions and spent quite some time discussing and voting together.
Because of moving to a more server centered implementation, many of the scripts that were previously used in the local implementation were rendered useless. Due to this, we were not able to meet the sprint goal of completely finishing the game mechanics.
Other goals such as player movement and sound interaction were implemented successfully in the local version of the game. We have to wait and see whether the code for these can easily be ported to the server code.
This week we aim to achieve more server functionality as well as a completed UI experience. Movement should be complete. MVP should be completed by the end of this sprint. MVP defined as being able to play against a player and interact as intended.
During this sprint we went far down the server rabbit hole. A lot of learning and experimenting was necessary to get familiar with the intricacies of implementing everything we had on to the server side. We exchanged tutorials, tried to reverse-engineer existing implementations and gave each other tips on things we discovered along the way. We went from our honeymoon period to the valley of despair pretty quickly this week, but managed to somewhat climb out of it by the end of the week and find ourselves content with life again.
While we didn’t quite achieve all of our sprint goals (for instance, we are still not ready for players to play matches with one another online) we are pleased with the progress we have made and feel that it will be possible for us to get our product into a fully functional state during the final sprint.
The goal of the sprint was trying to pick up where we left last sprint and again trying to make the game playable and have a minimum viable product. The team agreed to do this as quickly as possible in order to add the new features that we could not finish last week.
Since we did not completely reach our previous sprint goal of having a minimum viable product, the focus for the beginning of this sprint was to complete that. We were able to do so and spent the rest of the time finishing off the game by polishing interactions between various components as well as improving the user experience in the game.
Now that we are at the end of this project we notice that the things we work on become quite specific. We are currently spending more time tweaking existing content so that it functions as intended and fits into the vision of the game. There are aspects of Dókano which we would like to add or expand on for a higher quality game but undertaking these tasks would be a poor use of time as it is a possibility that we do not complete it and are left with the project being buggy.
The current state of the game is a smooth playing experience with some bugs that could potentially affect player experience. We are working to fix them. The game is also undergoing the process of being ported to Android.
The title screen of the finished game
Link to Expo Page