Team Moneymakers decided to make a scary game with low poly, indie game developer style.
We took heavy inspiration from these small, indie developer horror games that are fast and “easy” to play through but still offer some challenge and are memorable.
The player character (you) is a guest at a nice dinner party! The Fox, The Mouse and The Squirrel are already waiting for you to help set the table. But after starters, Fox gets missing. You should go to find him. Something feels off.
Development started with doing all the necessary assets to the game using Blender as a 3d software, as at same time programmers started to gather first mechanics to the game using Unity engine.
Both artists and programmers work at their own pace and schedule, and from time to time we combine our creations and build the game up. Team used GitKraken to share the project and keep everything up to date.
Idea was to have multiple different endings that the player could explore after finishing one, and we got two of the choised to the last build. Unfortunately time was not our favor and some of the endings are not in the build yet.
Our biggest challenge was time and timing of the other courses that were rolling next to the project, but after all we are happy with the outcome, compared to our challenges through the game project.
The project is part of the spring season in Games Academy and its goal is to introduce the students to 3D-game development and deepen already gotten skills in Unity and in game development in general.
Our team started the spring season with a clear idea on what we wanted to do. That idea came to be Curse Of The Amulet.
Curse Of The Amulet is a atmospheric, action-packed adventure game, with challenging gameplay. The game has multiple enemy types that offer a variety of challenge.
Skeletons vary from regular, mace and helmet equipped and bigger chief skeletons. The forest is also filled with giant mushrooms and possessed trees that offer a the player a unique challenge.
The player has two ways of fighting the enemies, sword and a spellbook. The sword is a reliable way to deal damage up close even to multiple enemies at once. The spellbook has four unlockable spells for the player to use against the enemies. These spells are hidden throughout the forest, only the fireball already unlocked from the start.
The Game consist of two levels, The Forest and The Castle. At first our idea was to make three levels, one of them being a dungeon level, but we decided to scrap it. Throughout the project we wanted to keep the scale adjustable so we wouldn’t have to make too many compromises on the game. We also wanted to make sure to use every asset and mechanic we created, so nothing was wasted.
First level: The Forest
Level starts in a decaying forest where the player quickly is introduced to the combat and the enemies. Player moves through three arenas where they will collect their weapons and keys from the enemies to advance deeper in to the forest.
In the deeper forest the player will try and collect the remaining spells, find a way to the castle garden and open the gate. There the Old Castle Guard awaits them.
Second Level: The Castle
The Castle is a smaller and more linear area. This way we could ensure that the experience is as fluent and engaging as possible for the player.
The castle is home to more tougher skeletons and a skeleton chief who guards the key to the great hall. There the player will meet the Cursed One
Game starts with a flashback of the player encountering an ominous figure that strikes the player down. Once the player wakes up in an decaying forest he will start the journey to meet his destiny.
After a few encounters with skeletons, giant mushrooms and not forgetting the tree trunks that seem to come alive. The player finds himself at the gates of the castle garden.
There the player will find The Old Castle Guard who guards the key to the castle. Once the Guard is defeated, the player can enter the castle where the ominous figure awaits. Once the skeleton guards are defeated and the door to the great hall opened the player will find The Cursed One.
After the One is defeated the player must choose, will he destroy the amulet that corrupts its owner, or will he embrace it and harness its power?
8ft. is in its simplicity a spider simulator, where you can live your spider dream of exploring the human habitat and catching bugs. The game consists of two rooms that you can explore; kitchen and bathroom, both including tasty bugs for you to hunt.
During the spring we started the work on 8ft. slightly late as our first idea which revolved around a garden gnome was pushed aside to explore a game idea with the possibility of using the ninja rope. For this we took some time to brainstorm ideas and decide on a concept we found most exciting.
Most of our troubles came from having not enough time between course and homework for school, but we still strived to create a game that works and serves a purpose. Our coders also battled to tame and understand the code of the IK spider that we hoped to use as a base for our own custom spider. Unfortunately due to time and the intense code of the IK spider we had to result into abandoning the custom spider, and borrowing the IK spider. We also hoped to create more rooms and consistency throughout the game but again due to time constraints we had to cut back somewhere.
Nevertheless 8ft came to a finishing a point and was a big learning experience to the whole team, sure to bring us food for the future so to speak.
The Observers’ Ruin started its development journey as a horror inspired spin on the arcade classic, Pacman, but as time went on, ended up inheriting more and more features and elements from the adventure game genre – namely the likes of The Legend of Zelda.
With a core concept of a lone survivor, striving to make it out of a nightmarish situation, it’s up to the player to lead the protagonist on a journey through the corrupted ruins of their once beloved temple, using both stealth and three unique abilities to make it out in one piece.
The game consists of seven unique levels that progressively introduce the abilities available to the player, as well as different types of enemies and other hazards, on their journey to the heart of corruption. Abilities grant the player some freedom on how to approach different challenges, but their use is also required at several points during the levels.
Most troubles that arose during development were centered around trying to establish the game’s identity, or direction, as our plans and ideas veered further and further from our original source of inspiration. We’d had some trouble with the AI, and since it’s an integral part of Pacman, decided to shift focus and build the game more so around exploration, abilities and light puzzle solving with both AI driven and scripted enemies to beware of.
Also, our movement system had to be rebuilt several times in an attempt to make turning corners smoother, both mechanically and visually, which was only made more difficult when wrestling with Unity’s old (and later, new) input system in order to implement controller support.
Yet, somehow, we managed to rise to the occasion, and The Observers’ Ruin is in much better shape than the eerie halls and stone pathways it houses.
Rocco the Raccoon’s Rolling Rad-venture has the player rolling around with a raccoon in isometric maps, collecting coins, keys, opening gates, avoiding hazards and trying to beat time scores.
Isometric pixel graphics
Controller and keyboard support
Casual and relaxing gameplay
Collectables and obstacles
We took Marble Madness as our reference point. Original idea was to have a colourful, casual game with puzzle elements and 5-6 different biomes relating to different eras and cultures, e.g. Ming-dynasty or ancient Greece.
Pretty soon we had an early prototype with some simple level layouts, character animations and movement. We started polishing and cultivating the concept, but eventually had to ditch the idea of different biomes (ended up having 2) and focus on general aesthetics and functionality of the game.
In retrospect, we spent too little time planning and thus got stuck in the early development phase and brainstorming. The project was a great learning experience for all of us.
Lenny Smith – Project management, coding
Juho Mansikka – Coding
Jirko Haapapuro – Animations, assets, UI
Jasa Paavolainen – Tilesets, assets, logos
Aatu Seppänen – Art lead, animations, assets, tilesets
For the Game Academy Project, our team “TeaCoffee Overdose” chose to do a Bomber man-copycat with a theme of 20’s rubber hose-animation, and so was born the working title RubberMan. The idea was to play as a robber, blow up banks and police, and eventually get into the getaway car with the money when all the banks at the map were blown up. The name switched eventually to Robberman.
The team was thinking of making the game for local multiplayer with only one keyboard (oldschool style), but when we dropped the idea at the first steps, we started to make the game as a classic bomber-man game.
Early concept art
We were thinking assets like hidden exits, abilities, power ups and flying SWAT-force coming from the sky with old helicopters, shooting grannies running at the map etc, and the robber we had an idea for using the money he gets from the banks to use it against cops by throwing money bags on them. After all, the game took the shape that it has now.
Our programmers played around different techniques to make the levels easier etc random level generator, but due the time limits we decided to handmade them from the start. We used a tiling map to make the levels look neat and consistent.
Art style was decided from the very start and stayed consistent. Some of the characters changed their appearance but overall our style stayed the same from start to end. We wanted to focus on good looking animations and keep the feeling on hand animated look.
We chose our main color scheme to be black and white to respect the original art style, but with some effect colors on the money.
Potion Bombers is a competitive multiplayer game that is based on the classic arcade game Bomberman. The team set out to make a fast based multiplayer game that was quick to play and had unique levels with different kind of mechanics in each of them. The game can be played with up to four players and is best enjoyed with controllers.
The team quickly got the idea of the different kind of levels and set on three types. Lava, ice and water levels. All levels have their own terrain and different mechanics in each. Difference to the original game is also in the players ability to break only a certain type of objects in the level with the walls being indestructible. These breakable objects spawn power-ups to the players to give them an edge in the fight.
In the lava level players are able to break to floor with their bombs to reveal the deadly lava. This makes the matches quick and strategic with the ability to trap the other players using the lavaPicture of the lava level and the breakable floor
In the ice level players will slide on the ice making movement harder, the bombs also slide on the ice if the player pushes them giving the players ability to deal damage from a distance
Picture of ice level and power-up items
The water level has waterways that will move the players and the bombs along the stream giving the player ability to move quickly and tactically place bombs to attack other players.
Picture of the water level with a detonating bomb in the water
About The Project
The whole project was completed almost entirely remotely, only meeting a few times to playtest the game. This added a bit of a challenge, but frequent meetings and discussions helped to keep the team motivated and focused.
Because of the time running out and few unexpected turn of events inside the team, the game is not as detailed as the team would have wanted with few graphical items missing, but the core game is fun to play, especially with four players. So in the end we are very happy with the end result since a fun game was our main goal.
Eetu Pohja: Programming
Jaakko Joenperä: Management, Programming
Emmi Pusa: Graphic Design
Laura Suvila: Graphic Design
Simo Kontiokorpi: Graphic Design
Aleksandra Pere, Programming
Mira Opukhovskaia, Artist
Ville Raunio, Artist
Toni Sundell, Programming helper
The idea was simply to create a Tetris clone with a synthwave artstyle. The game has many of the basic gameplay mechanics which are found in the older and newer Tetris games (hold, show next block, hard drop etc). The player can also choose from three different themes which change the game’s looks and music.
The development of the game was a gradual learning process of using Unity. This is very visible from the start of the project right to the final parts of development.
At the beginning of the project we managed to scrape together a basic prototype with some basic movement and art implemented.
At around the middle point of development more mechanics started to come into the game and the art also started to look more satisfying to the eye.
At the end of the project we had a ready Tetris clone in our hands, which finally started to feel and play like a proper game.
One of the things that really stuck to our head after this project was that some of the games can be surprisingly complex under the hood, in this case Tetris. It was satisfying to see the game slowly but surely mold together into a satisfying Tetris clone. Considering that this project was a first time working with Unity for the team, we are extremely proud of the final product.
Penguin Rescue is a 2D platformer game where the player goes through different levels while saving their little friends and eliminating hungry dingoes. The adventure is nothing without dangerous traps, such as ice spikes coming from the ground and icicles falling from the ceiling. That’s not all; the player also needs to beat the timer on each level in order to continue the game. The player gets health back by eating the fish that jump around the levels.
The game is easy to learn and fun to play. The game is challenging but not too hard, and it fits well for someone who hasn’t played a lot. The timer encourages players to go for the best time, and what’s more fun than comparing the results with your best friend, right?
Our team, Hungry Hamstersconsists of two programmers and three artists and we are all first year Games Academy students. Our mission was to make a 2D game by using one of the given old-school 2D arcade games as a reference. Our top two options were Bubble Bobble and Dig Dug, and after an intensive discussion and planning with the team we ended up with Bubble Bobble.
Pretty quickly it was clear that we would use the reference game only to generate ideas for our own game. Little by little we managed to figure out the game we would like to make; a platformer much like Bubble Bobble. The objectives of the game were formulated along the way, which took a bit of time to figure out. When we were clear on the objectives, it was easier for programmers to focus on coding and artists were able to start planning and creating the game graphics.
We generated ideas throughout the project, but we had to leave many features behind due to strict time limit. Our team worked well together, and we were able to discuss things with honesty.
The biggest issue we encountered in this project was the fact that we had to work remotely for the whole season. It brought new challenges our way and had an impact on all team members. Despite these challenges we were able to make a good-looking and entertaining game and that’s what we should be proud of!
The goal was to clone an old-school arcade game, and we very quickly ended up with Bomberman heritage as the team agreed on creating an action game. We set out to play and watch videos of other Bomberman-style games to draw inspiration from. The main ideas were roguelike elements and an asymmetric co-op play, where players would have different but complimenting abilities. As the scope of this project for us as relative beginners became clear, we simply ditched the multiplayer aspect and concentrated our efforts on creating a smooth single player experience.
The first steps were creating some concept art and themes, and a simple game prototype. One of the early mechanic decisions was about player movement: Would we go for a tile-based movement or give the player free reign to run through the levels? We started early with a completely free movement, but as the bomb-laying and its relation to environment and enemy destruction became convoluted, we changed to a grid-based movement. This turned out to be too rigid for us, and since we were not using tilemaps in the game, the grid wasn’t that useful for us anyway. We ended up with an amalgamation of both; The player having free movement, but bombs and enemies using whole number coordinates, for ease of environment destruction and AI behaviour respectively.
As the art style and core game loop took shape, we started having a more tangible sense of the scope. We wanted to keep things relatively simple to be able to deliver a working game that was fun to play. We had 3 different enemies, a configurable bomb, a simple level and the player character, and early feedback with these drove us refining the core loop further with smoother controls, fluid player movement and animation, and more challenging enemy behaviour. Once this basic flow was established, we could turn our gaze to expanding the gameplay and refining the look of the game with lights, effects, additional animations and even a dedicated story scene.
Our original plan was to give the player some currency from killed enemies and a power-up shop to use it in – either when the player dies, or when transitioning between levels. Difficulties in deciding the exact mechanisms along with feedback given drove us to redesign this part of the game. Instead of recycling the killed enemies through a currency and a shop we decided to drop this idea, and instead give the enemies a chance to drop power-ups directly. Since the bombs were already configurable, creating variation for them wasn’t hard – the difficulty arose from deciding which kinds of power-ups would actually be useful and how players would use and store different bombs and bomb upgrades. We floated ideas between a single special bomb slot to having an inventory of them, and ended up with simply having 3 types of special bombs and a dedicated button and inventory slot for each. The player could only carry a single one of each of these, but they would be complemented with range and capacity upgrades to the basic player bomb.
The idea of endless progression in the game had been in the backs of our heads from the start since we had the concept of implementing something roguelike to the game. At first this was simply adding enemies and changing how the levels looked, but as the enemies themselves were somewhat configurable as well, they ended up getting faster as the player progressed through the levels. At this point we also featured randomly generated levels, but ended up using a combination of presets and randomly generated content to prevent creating dead-ends and unreachable positions in the layout – this turned out to be the easiest solution without using any kind of pathfinding algorithm.
In hindsight leaving the UI and menu mechanics to the end of the project was probably a mistake as it wasn’t as easy or simple as we thought it would be. The implementation of tasks like pausing things and navigating menus became surprisingly difficult because we hadn’t factored them in from the start. Despite this we got everything working and managed to snuff out or avoid game-killing bugs – according to our release candidate testers the game turned out to be fun to play as well, so we are happy with the results!
Eppu Syyrakki: Programming Laura Huovinen: Programming Hannu Timonen: Graphic Design, Animation, Music Niilo Kajala: Graphic Design, Animation, Management Pekka Juntunen: Sound FX Emilia Mikkola: Animation, Level Design