2 Games a Month — Game Sprint 2
Welcome to the report of the second Game Sprint for the 2 Games a Month program. If you’ve missed the previous report, you can find it here.
After a harrowing two weeks, the participants of the program delivered four more prototypes for the second sprint. The themes this time around? Zen and mobile, which has been unfamiliar ground for most teams.
These are the four games the teams came up with:
Line in the Sand — A physics-based game where you bring a ball from point A to B.
Sea of Dreams — An exploration game where you visit various islands and take pictures of them.
Pixie Harp — With a firefly and your harp, guide a feline fairy through the trees.
Terra River — Assist in rebuilding nature around a polluted river by constructing helpful structures.
The feedback has been considerable and helpful in preparation for the third sprint, but we’ll let you read about the teams’ reports yourself down below.
Line in the Sand: What designing a game for an unfamiliar platform is like
Julien Lommaert, Simon Buyck, Jens De Wachter, Jeroen Janssens
Summary
Line in the Sand is a relatively simple physics-based mobile game made with the idea of creating a zen atmosphere in mind.
In ‘Line in the Sand’ you have to control various contraptions to roll a ball through each zen garden level. When you complete a level, the zen garden gets restored with a satisfying line pattern.
The Idea
Designing a game for a platform you’re less familiar with is tough, which was the case for this project. The hardest part of this project was coming up with a zen-themed idea, also the added mobile aspect was a hard roadblock. Ultimately, we came up with ‘Line in the Sand’ by looking at mobile games we enjoyed in our childhood and worked off of those. Once we had more of an idea of what type of game we were going for, giving it a zen theme was a piece of cake.
When looking at everyone’s ideas, there was one recurring theme, some sort of marble being brought from point A to B. This reminded us of those tables where a metal ball is moved in a pattern using a magnet, leaving a line in the sand. Combining this with the stereotypical zen garden ‘Line in the Sand’ was born.
The Struggles
As stated in the title, mobile was an unfamiliar platform for us, and this caused some issues to come up during development. One of the bigger issues was to figure out an intuitive control scheme for mobile. We had to rework our control scheme in the middle of development based on player feedback. This meant rewriting a large portion of the code base and even then, there is still room for improvement.
We made sure to keep the amount of mechanics to a minimum, but still enough to get the basic idea across. That’s why, for example, we only implemented 2 contraptions. We had plenty of ideas, but in the end, that was all we needed to make enough interesting levels to get the idea of our game across. This also gave us enough time to polish the game and make it as enjoyable as possible.
The Future?
Despite all the challenges, ‘Line in the Sand’ ended up being a very nice, expandable game, with plenty of room for more levels and contraptions, some of which were already designed but scrapped to save time. Of course, there’s also room for new elements, like unlockables, customization, and of course, monetization.
Sea of Dreams: How a great idea can be destroyed by bad task management
Arnaud Sougnez, Lucas Van Baeveghem, Briek Keters, Milan Vanalderwerelt, Oscar Tulkens
Summary
Sea of Dreams is a zen mobile game that focuses on exploring and capturing nice photos of newly discovered islands and sea life by following the compass on your screen.
Our development story
Even though in the game you are smooth sailing, this wasn’t always the case in development. We started off with a brainstorm, it didn’t take long for the team to see eye to eye on the idea we had in mind, so we got to work pretty fast.
After a couple of days of development, we started to notice a pattern of unfocused working. We wanted to create a randomized feeling, so we created a procedurally generated ocean. We also used Houdini to create procedural islands for the game. When we were two days into development we saw that procedural generation of an ocean is more than overkill for a project our size. This is where we saw our first encounter with bad time management. Not only did one of our programmers lose two days of development, but there was still nothing to showcase to our mentors. From there on in order to create an infinite ocean, the team decided to make a big plain that follows the player, giving the feeling of an infinite ocean.
Our second big mistake was focusing on randomization. We overestimated the impact it would have on our mentors and how unbeneficial it was for our game. We had the idea to create a game, where every time you play the game it would be different. So, we had the idea to make the islands spawn randomly around the player and have a compass to guide you towards the nearest one.
Even though this didn’t take a lot of time to implement, we got feedback from our mentors that this isn’t needed in creating a prototype. They told us that faking it in prototyping is sometimes better, than actually developing it.
After this, we were 4 days into development and almost back to square one.
We got back to our planner tool called ‘Hack N Plan’, to rearrange our tasks and priorities. This is where it went completely wrong. Not only did we prioritize bad, but we wouldn’t get any feedback on our planning/game until next Wednesday. This meant from the 6 days of development left, we were going to be working 3 days of them not knowing we were doing something wrong. When Wednesday came, our team had the feeling our prototype was ready. We had super nice visuals, we had great immersive sounds, and our main mechanic to take pictures from islands was implemented and working. Well, it is safe to say that we were apparently the only one thinking that. On Wednesday we had a game testing session with everybody else from the internship and we got a lot of feedback that our game was too heavy for their mobile devices or that the file size was too big. Even though we thought that our game was great, nobody else did. With only 2 days left of development, we didn’t have enough time to fix all our majors issues. This was the point where our team crumbled. We didn’t know how to fix the mess we created. We started by focusing on the feedback we got from other interns, but it was too late. Our game was too far gone to save.
This was our story of how bad planning will destroy your game, even though you don’t see it yet.
Our Learnings
We learned a couple of things in this project since it was a mobile game that some of us aren’t experienced with and a zen game which all of us aren’t the biggest fans of. Since it was a mobile game, we had even less processing power than we expected so we ran into some big loading times which aren’t fun for anyone.
We had the idea of an infinite ocean with infinite islands, so we thought a procedural island generator was a good way to go. We wanted to use Houdini but none of us knew Houdini. However, we wanted to learn which turned out to be a bad idea. It took a week to make the island generator and optimize it so it wouldn’t blow up a phone which, for a prototype of only two weeks, is a lot of time. So we learned a new tool — great, but we also learned it’s not good to learn new things when you don’t have the time to spare. It is better for a prototype to use one or two islands quickly modeled to bring over the idea and when you get the green light for the project you can make them procedural.
Another thing we noticed is that post-processing and shaders can make your game beautiful, but not all phones are a fan of those. Either the phone has no problems and runs smooth or it gets 3 FPS and crashes. We don’t know what the big factor was in this but it is something to look out for when developing for mobile.
Now our biggest learning: planning, our biggest problem with the planning was the wrong prioritization. We focussed on the wrong things which left us with too little time to improve the important things. We had too much focus on looks and too little on mechanics and gameplay.
One step back, three steps forward: the story of Pixie Harp
Dylan Millian, Christian Fedrau, Thijs Snoeck, Tinca Antohi
The game is set in an enchanting forest, far away in a fantasy reality. We have our beloved protagonist — Purrince Fluffybottom — wishing to travel through the forest but is unable to because of the twilight night. Despite being a fairy, his dainty, tiny wings are too weak to carry his fluffy body; hence he needs our aid.
Light-bugs soar through the woods, allowing us to see which branch would be safe for our feline fairy to jump on. We guide Purrince Fluffybottom to jump on the safe branch by playing our harp. In order to succeed — we have to remember the path revealed by the firefly. Every member of our team provided an interesting concept for a mobile game with a ‘zen’ theme. We found ourselves unable to decide whose idea to pick; eventually, we came to the conclusion to roll a dice and have our idea to be picked for us.
The initial idea of Pixie Harp was straightforward: listen to the cat fairy play a melody on its harp, and then play the particular tune on your own harp.
After a session of play-testing, we established that our game was a duplicate of ‘Simon Says’.
To our luck, we had a team member, Thijs Snoeck, sharing another concept of Pixie Harp. It completely altered the gameplay; making it more challenging, and we believe it also made it more fun to play.
Unfortunately, we had only one week left to develop the new version of Pixie Harp.
Because of this, we were unable to polish the game. Although Pixie Harp has its main mechanics developed, it lacks player-feedback and visual fidelity.
Although the radical change of the entire idea was distressing, our team did not encounter too many problems. We had to work faster than we were used to. A lot of the previous art assets were scrapped and the programmers had to restructure their code.
If we had more time, our concept would have been better developed and we would have a clearer view of market viability.
For some of us, this was the first time working on a mobile game. And like any other game, we learned how important feedback and play-testing are. Without it, we would have delivered a mere ‘Simon Says’ game with cat fairies.
Terra River: the 2 weeks nightmare
Jorik Weymans, Viktor Colpaert, Jägers Jérémy, Robin Decock
Terra River is a mobile game where you need to clean up a polluted river to restore the natural aspects of the environment. This can be done by either manually cleaning up the river or using certain structures to improve the efficiency or build up the funds to clean up more easily. The river itself can first be set up by forming it into different shapes but be aware that the more twist and turns you make the less space you have to put up the different structures.
Some structures that need water need to be placed right next to the water on the grid, while the others can just be placed on regular tiles.
How did we get the idea?
We brainstormed on a couple of ideas surrounding the zen theme. Because we needed a mobile game, we set up the different genres that were popular in the app store currently which were platformers, idlers, ball physics. We started building up from those genres, this resulted in a couple of nice ideas that each of us set up individually.
These ideas were discussed as a group and shortly after were also voted on, the resulting game was the game that we made — Terra River. The idea itself was not perfect right away, so we needed some time to adjust our original idea.
What failed?
In the first idea you put fishes in the river, fish themselves generate oxygen coins, you can buy more fishes and put up decorations on the field near the river for passive abilities. You finish the level when the game is decorated enough to be made ready for the public. We started working on this idea in the first week of our 2-week game sprint.
At the end of the first week, the planning was not thought through enough to be successful so the priority of the tasks themselves was also not set correctly. Which, on the last day of the first week, resulted in an unfinished game loop that could not be tested properly. We invested a lot of time in the river forming setup which in the end didn’t add enough value to the game compared to the time invested.
The first idea itself was also not as fun as we thought in the ideation phase.
Back to the ideation phase
We started to brainstorm around a new idea that still involved the mechanics that we made so the new idea was about a polluted river that needed to be cleaned up to make it more appealing to the local residents. The player could drag the trash to a trash can, but also set up structures that pull the garbage out automatically. For the 2 week sprint, we minimized the number of buildings to only 3, a fishery, a trash collector, and a shop. Each has its own mechanics.
The fishery fishes out fishes the cleaner the river the more fishes you will get every second. Trash collection fishes out the visible trash, when a collector is busy the trash is ignored until ready to process again, so multiple of them are required for maximum efficiency. The shop itself gives various buffs that increase the performance of said structures. Each structure can be upgraded to a better variant. For example, the fishery can be upgraded to fish faster, boost nearby fisheries, or make more money per fish. This can be done for each structure. Fish baits can also be bought from the store to boost nearby fisheries where it is applied, these need to be bought and have a delay between usages.
Final result
The final game that we made answered the Zen theme, for us it was a successful first mobile game because it was uncharted territory for us until now. We learned that a game doesn't need to be filled to the brim with mechanics to be fun to play, it can surround one simple mechanics and be easily expanded to support more game content. This game could be more successful if it was made on a bigger time span which could lead to a fun idler.
The game itself is way too big and the different connecting logic resulted in that we needed a lot of gameplay tests which in the end we didn’t do enough of to get most of the bugs out.
The player starts by editing a river. After the setup of the river, the player goes to the next stage where the river is polluted. The player needs to place fisheries for money and trash collectors to clean up the river, mix & match the 2 structures to get max efficiency for the resource gathering.
Future
The game can still be improved by making more different structures that support the current ones because we are talking about a mobile game AFK element can be added for example a dump with an amount of trash storage can be built to further upgrade the AFK ability of the game, but also other buildings can still be added for more support in the game itself. The art style would most likely also be revised to come to a more coherent result, visual improvements could definitely be made. Along with the concept for the game the visuals too shifted quite often, this is something that should be fixed.
The procedural part would either be cleaned up a bit or be thrown out completely because the game evolved around a new idea the procedural part became obsolete and less connected to the gameplay. Not only that but because of a procedural environment everything else is more complicated this goes from environmental editing in a visual aspect to connecting other mechanics.
Conclusion
The takeaways from this Game Sprint have been many, but it will only serve to build even better games in the coming weeks.
- There has to be a clear focus on what’s important while developing.
- To build on that, the team needs a clear view of where they want to go.
- Make sure everyone’s on the same page with the concept and art direction.
- For a prototype, the focus has to be on getting the core mechanics working.
- Try to finish the game-loop in the first week of development.
- Don’t be too ambitious with the prototype, they only have two weeks!
- More player-testing outside of scheduled times.
- Start thinking about tutorials earlier in the development.
- Kill your darlings. What you like is not always what others like.
That’s it for the Game Sprint’s wrap-up! Hopefully, this has given you some new perspectives on game development. Stay tuned for the next post in two weeks!
