Hallucina Escape is a top-down hack and slash game where the objective of the game is to escape the mental hospital. Lots of different ravenous enemies try to kill you, so be prepared! You get different weapons and health potions from defeating enemies. You play character called Seven that gets caught in a bad trip and needs to get out.
Progress of the project
The game was developed by team TooBad during the autumn semester of 2016. Development time was more or less exactly four months. During the first month we tried to really find which of our ideas really worked out for our game. We tested multiple styles of movement and camera controlling, until we found out the perfect one for our game. After that we tried to make the game playable as soon as possible. Graphics artists started working on the player sprite and everything else that was necessary to have a real prototype of the game. Markus started working on the inventory system to get that working as well.
After all the necessities we started working on enemies and the bossfight. Also this was the time that Penuel started getting quite bit of animations ready and we managed to put them into the game. We also started to generate the map and different weapons for the player and enemies.
Around week before December we started to add in sounds, make main menu work and really polish the gameplay to be as good as possible.
Timo and Markus handled the coding side of the project, while Zach and Penuel handled graphics. Timo’s main responsibilities were the animations and their transitions, character and camera movement, map generation and design, editing the sounds and various other smaller parts. Markus mainly handled the loot/inventory system, player mechanics, enemy mechanics, boss mechanics and main menu.
Zach’s responsibilities were different enemy sprites and their animations, different floor/wall tiles and props for the maps. He also made blueprints of the maps and quite a bit of sounds as well. Penuel’s main responsibility was to make everything the player needs. This means tens of animations for the player, weapons and icons for the inventory as well.
TEAM MEMBERS
Tommi Hagelberg, Ida Tuominen, Petra Mether, Teppo Hyttinen, Anni Lehtomäki
Fuck, Sand! is a 2D platformer set in an apocalyptic ragged sci-fi setting. The player character is a lonelier and a lone survivor crashed on an abandoned, hostile planet. The original objective for the game was for the player to find four key elements which are missing parts of a broken spaceship before the protagonist can complete their aircraft and player can complete the game, but the demo only includes showcase of the core mechanic of the game. The game mechanic revolves mostly around the jumping action, with the upgrade to a double and triple jump. The levels include a lot of environmental hazards which cause an instant kill if encountered carelessly.
DESIGN & DEVELOPMENT
Our very first and original idea was simply put just huge. We settled with apocalyptic sci-fi setting very early on and our idea of the game world did not experience radical changes anywhere. But originally our mechanics included multiple weapons and actual combat elements. These would have required so much work from both programmer and artists that it would have been basically impossible to get even half of it done by the end of the course. Luckily we did realize our mistake within first week and were very quickly able to adapt our idea to its current form.
We focused on platforming and level design instead flashy features and storytelling. The scope of the project kept changing frequently which caused the end product to be more or less of a demo of the game we designed. The main mechanic which we decided to execute was experimental and caused a lot of problems when we analyzed player behaviors and tried to improve level design. We would have needed dedicated level designer for overcoming these challenges.
Workload of the project divided pretty evenly for three of the members and rest of the members supported the project in different ways. Programming and most of the level and game design was made by Tommi. Visual style, colorization and story behind the game was handwork of our two graphical designers, Ida and Petra. Music is composed by Teppo and both Teppo and Anni helped with level design.
Call Of Valhalla is an action platformer game loosely based on Norse mythology. In the game you play as a champion from Valhalla who is tasked by Odin with preventing the Ragnarok which is the prophesied apocalypse in Norse mythology. To do this the player must travel through three different worlds to fight Loki and his allies – the human world Midgard, the caves of Svartalfheim and the icy hell of Jotunheim.
Development process
The game was developed by a four-man-team False Golem mainly during the fall semester of 2016. Development time was roughly four months. The team had two programmers, one main graphics artist and one assisting artist who also did various other tasks. The game is powered by the Unity Engine. Our original inspiration for the game was the run-and-gun platformer Broforce and other sources of inspiration we’re Metal Slug and Skyrim. We started the development quite early by testing several things out such as movement, weapons and basic enemy AI. The game quickly drifted away from it’s roots and became a more simple and traditional platformer – which was probably a good thing for our first proper game project.
Although the development started early, the pace was slow and steady at the start. We picked up the pace in the halfway of the development cycle and got a lot of work done quite fast. However, there were some features we had to cut such as more weapons and more enemies since there wasn’t enough time. Early december we thought there might not be enough time to make a third world but gladly we ended up doing it. The game shipped with two weapons with two different attacks, three basic enemies, four boss fights and three different worlds spanning twelve levels. There is also dialogue which explains the story of the game and gives the player an incentive. If you would like to play Call of Valhalla you can do so at itch.io. We would love to hear your opinion on the game. You can navigate find our game by clicking this link or by searching Call of Valhalla at itch.io
Janne Forsell – Programming
Veikka Saaristo – Programming
Anna Guxens – Level Design
Mike Bernstein – Graphics
Scamper
Like a rat in a maze, our game is about learning through experimentation. In a mysterious laboratory, scientists observe Scamper the rat as he learns to use telekinetic abilities to solve puzzles. After a little trial and error, each challenge requires timing and experimentation to solve. The goal is simple; pass through the challenge without touching any of the obstacles. With boxes, hinges, swinging ropes, platforms, fans, buttons, levers and lasers, there’s a lot to figure out. The game is played entirely with touch controls, and we specifically designed in for a sharp, readable look on Android mobile.
Design & Development
At the outset, all we had was one mechanic; something Anna had thought of a long time ago. In a short while, we had a proof of concept in Unity. By clicking or touching blocks, they moved in a predictable, physics based way… and it was easy to brainstorm for a long list of other basic interactable objects. But even a catchy puzzle mechanic needs a concept behind it, a narrative or at least a visual style to identify with.
We struggled to find the right concept, and our development efforts were slower than they should’ve been until we hammered out that problem. Despite looming deadlines, we had difficulty finding our motivation.
Our initial idea came in the form of a cat from an internet meme, and it would’ve been a good one, but as we moved forward with our planning, we realized it would be too complicated a story to tell within the scope of our project. A couple of weeks later, we found our solution; a rat in a maze is a familiar concept, and we wouldn’t need to explain everything this way; the player only needs to know as much as the rat, for a simple mobile puzzler like ours.
From that point forward, our progress was relatively fast; with an inspiring concept in mind, our artists were able to quickly build up the visual identity of the game, and from there it was iterative; new art created demand for new programming and vice versa. Fortunately, our scope never ran out of control on a technical level. That said, there were still surprises in store, and underestimations in what kind of work would be needed. There was always something else to take care of that no one had really considered. As in many small productions, and despite knowing this, we struggled to add audio and UI elements in the time we had left.
Though there were certainly features that didn’t make the final cut, we’re proud to say we felt ready and even polished by the deadline. We’ve released the game on the Android market, completely free.
BounceLight is a serene puzzle game centered around reflecting lasers. Players must use their wits and forethought to aim their Lasers of Love™ against unsuspecting stars. Popping all targets in a level grants the player with the fabled three-star rating.
During the development of this game, a single narrative ran through the whole process. What started as big plans for a game after a fall out with a previous team quickly turned into dread over the size of the project. As such, each iteration of the design was an exercise in reducing the game down to it’s core components, and focusing on what seemed good. Gone were the complicated scoring system, messy aiming and pixel-art graphics. The focus gradually shifted on building simple, but engaging puzzles with the existing mechanics of firing bouncing lasers.
It was messy. It was hard. And by the end of it, it was wholly necessary. I feel like every feature stripped was a step in the right direction, and my only regret is not taking out more earlier. It hurt to throw away hours of programming. It gnaws at me that the game could still be better. I learned a lot, and I hope to carry those lessons forward.
Let it go, let it go. The code never bothered me anyway.
Forget Not is a 2D puzzle platformer whose core concept is the ability to toggle between controlling the main character and the light in their lantern. The stages’ obstacles react differently to the light – it illuminates the player’s path, keeps enemies at bay and lights up crystal balls which in turn activate different objects. The player’s goal is to pass the trials and solve the puzzles in each level. Additionally, in every stage, a secret star has been hidden for the player to find.
Design and development
The idea for the game came up while brainstorming as to what we wanted to create in this project. At first it wasn’t the lantern’s light that was controllable, but the character’s soul. It wasn’t long before the concept evolved to its current form.
The art direction was initially going to be more detailed, but in order to reduce the time taken by asset production and make the lighting work better, we decided to go with silhouettes instead.
The levels were originally going to be pitch black – the lantern’s light would have been the only light source for the player, but this was changed to make things more accessible for both the player and the developers. The sense of atmosphere in the game plays a vital role and was something we had in mind from the beginning.
Once or twice a week our team got together to discuss what each of us had done and what was next on the agenda.
Cyber Punchers is a side-scrolling beat-em-up for 1-4 players. The game supports local co-op multi playing. The goal of the game is for the players to take down as many enemy robots as they can before running out of health. Even though the game might occasionally provide a little challenge, the true aim of the game is to act as sort of an excuse for friends to get together and bash some bots in a not-too-challenging and not-that-hard-core setting.
Project
At the start of the project the team decided to make a post-apocalyptic themed driving game where the player was supposed to deliver supplies to different cities while fighting bands of raiders. Everyone was behind this idea but the team realized after some weeks that the scope was too large and was forced to scrap it and start from scratch.
The idea for Cyber Punchers was born: a fighting game with a cyber-punk setting, a robot with a Roomba as a head taking revenge on the evil mega corporation. Wave after wave of evil robots. At first the team started working with an arena type of playing experience in mind, but later on in the development the best option seemed to be to move the screen to provide a little change in the form of quite often changed backgrounds. So, now the robot-arena is not limited to single screen(s).
The representatives of the evil mega corporation are like the player character, robots. The design of the robots is a mixture of riot polices and nazi officers. The style of the backgrounds are urban East Asian cities with heavy influence from Cyberpunk.
Starting from scratch meant that the already short development time of the Cyber Punchers was reduced even further. People falling sick one after the other certainly didn’t help. Even though the team would have liked to implement a million and one cool features to make the game a lot more interesting and fun, the reality of the project was that to actually make the best possible playing experience in this genre takes a lot more time, energy and iteration than was actually available. Oh, and a bunch of assets whether it be code or pictures. This is why the team had to admit, that if Cyber Punchers would some day evolve to a more full experience, work on it would have to be continued outside of the school after the course.
If there’s something to be learned from the development of Cyber Punchers, it’s that in a school project like this the scope has to be kept extremely small, special attention should be paid to team dynamics and communication to make the project go as smoothly as possible and that the expectations should be kept realistic, even if the ideas are quite ambitious. But then again, we are in the Games Academy to learn, aren’t we?
Now that the game has been introduced quite critically, you get to make your own judgements: Ladies and Gentlemen, Cyber Punchers.
Slingy Slugs is a turn-based 2D local multiplayer game for Android devices where 2-4 teams of stretchy animals battle to death. The core mechanic of the game is a slingshot mechanism with which the explosive animals are hurled at each other and around the playing field. The explosions hurt the animals and destroy the terrain, and the team with the last animal(s) alive wins.
After the starting screen, the number of teams (usually the same number as the number of players) is set. After this, the players choose a level to play on and start the game. Each players’ animals are placed on the map and the battle may begin! Taking turns, the players try to slingshot their animals in ways that cause the opponents to lose health or drown.
The game has four animal types, each with their own special ability. The Slug’s functionality is the most basic one, as it soars through the air and explodes on impact. The Snail does the same with a smaller explosion but also bounces a couple of times, exploding thrice. The Octopus heals team members within its “pollenation” radius, whereas the Siika (whitefish) character burns through the terrain, creating tunnels, slopes and openings. Players have the possibility to customize their team’s animal composition (and names!) from the Team Management menu.
Like so
“Angry Worms”
The basic idea for Slingy Slugs emerged, innocently enough, from a brainstorming session where the words “crossover between Angry Birds and Worms” were uttered. Other ideas, even pretty great ones, had been thrown around, but this one immediately caught fire and captured our imaginations. We set out to create a relaxed multiplayer game that was simple enough to just pick up and play but also provided tactical satisfaction.
After a shorter-than-optimal design meeting, the programmers jumped in and started working on the concept the very first day. For the first week or so, things were very experimental (worms were slung around a test chamber), and the team went through all the stages of grief when trying to implement a self-made 2D physics system instead of just using Unity’s integrated Box2D. In the end, it was deemed way to handy to not just employ a system that is already there instead of having to take into account every obstacle we might face with a home-brewn solution.
Another thing that became clear very quickly was that the team simply wouldn’t have the necessary know-how to make a destructible 2D terrain system work within the timeframe of the project, so a bit of plugin research was made. In the end, we decided to go with the excellent Destructible 2D plugin by Carlos Wilkes. As an editor extension, D2D presented the team with the challenge of understanding making good use of the stuff that’s in there, but it was relatively easy to get a handle of the system and modify the well-documented examples to fit our needs.
…but don’t get me started on the Siika
The right art style was found very quickly thanks to the project’s theme fitting the graphic artist’s skills. There was a conversation about using pixel art, but that conversation was a brief one. The first artistic obstacles were presented by the technical design: how to make the characters out of many parts, some of which stretch and rotate interactively via input, and still make the characters look good? However, even this problem was solved surprisingly quickly by the team. Although the end result perhaps isn’t the finest display of prefab engineering, it’s a functional one.
Very quickly, the game started being fun. The kinesthetically natural feel of the main gameplay mechanic made it almost distractingly fun to play around with the stretchy slugs even before there was an actual game to be played, and this of course lifted the spirits up. For some time, the atmosphere was almost too enjoyable, as progress was made in rather unprofessional, “I’ll just add that too” manner. However, this stage of “just doing” things was pivotal, as without that rush of enthusiasm, we wouldn’t have had all that (fully functional) code to refactor during those desperate Sunday nights before a demo deadline.
A snail with some speed
Problems, officer?
The biggest and most persistent, but at the same time the most predictable problem throughout this project was schoolwork that was not directly related to it. The weekdays when project work wasn’t possible were enough to make a huge dent, but also, it was difficult to schedule things or have a clear grasp of how much stuff can be achieved when at any given moment, a huge coursework assignment could be dropped on our necks. Although we understand why the problem exists, it doesn’t change the fact that it’s the no. 1 reason why we’re unable to plan our stuff professionally.
Whether or not the volatile nature of schoolwork was the main reason in this or not, we discovered that we are not very good at estimating the time it takes from us to do things. This was to be expected, as many of the project’s tasks were things we had no prior experience of, but we could have helped ourselves greatly by always implementing the “multiply time estimate by pi” rule of thumb. School, work, personal stuff and unexpected problems will always come into the way, so a reasonable delay buffer is better than overly optimistic expectations.
On the technical side, we ran into some rather weird obstacles with the Destructible 2D system. It seemed to cause way too much lag in even our simplest levels, and it seemed hopeless. However, after several days of dedicated research and experimentation, we managed to find the ways to optimize almost all lag away from the game. In a glorious display of ass-backwards logic, it’s actually more efficient to have edge colliders made from a huge image rather than smaller ones, transparent data in said image around the borders is better for performance, and stamping is faster to calculate with a smooth brush than with a clear-lined, hard one. Go figure.
No more Mr Ice Guy
That’s a wrap!
Our infantile efforts in trying to figure out this game development stuff resulted in a pretty sweet, fun game that we feel proud of. Admittedly, some overscoping was done at the start, but all in all, the removal of unnecessary and/or impossible-in-this-timeframe clutter was painless, as the game feels good to play as is. As usual, the biggest breakthroughs in both the technical side and gameplay feel came at the last minute, but that final rush made the experience all the sweeter.
Although school-wise a deadline has been met, the team sees no reason not to expand on the game and add content to it later on, if such an opportunity were to present itself at a later time. The game is actually fun to play, which was the main goal of the project. Therefore, even with the difficulties we had in the process, we dare call this project a success!
Programming: Hannes Salo, Santeri Mononen
Graphics: Eeva Säilä, Veera Tikkamäki
The game
Our game is a 2D turn-based artillery strategy game for the PC. It is a local multiplayer game for 2 to 6 players. The playable characters are ducks, which gives the game its name. The goal is to eliminate the opponent’s ducks using different weapons; the last man standing wins.
At the start of the game the player can set the amount of players, amount of ducks per player, HP, the length of players’ turns, and the amount of ammo for each weapon. The game has four different weapons. After the setup menu players get to place their ducks on the level. Physics also play a part in the gameplay. Besides just stationary platforms, the levels have structures made of different physics-based building blocks. These include wood, glass, and metal walls which all have a bit different properties. The game has five playable levels.
Design and development
The basic idea for the game was agreed on relatively quickly after some brainstorming with the team. We actually agreed on the team name, Ducktape, before knowing, what kind of game we would make. This gave us the idea of having the characters be ducks. The gameplay was inspired by Worms series, with Angry Birds-like building blocks. Graphical style for the game was kept simple, colourful, and cartoony.
Our team met on Mondays to see what has been done so far and to discuss about the tasks for each member for the next week. Some tasks did take longer than expected and we had to leave out some features we had planned to include (such as more environmental hazards within levels, and hats). However, the most important gameplay features were finished. We also encountered some problems (the scale of graphic assets, for example) that could have been avoided with better communication between team members.
To summarise, our goal was to make a 2D multiplayer game for PC and, despite some problems, this goal was achieved. This project gave us all a bit more experience on what it is like to develop games.
Programming: Kalle Heinonen, Antti Tuomisto, Joni Tasala Graphics: Jonas Forsman Audio: Johannes Leipälä
Project info
In Block Wizard, the player must use their mystical abilities to survive an onslaught of enemies. The player can raise and lower the blocks that make up the terrain, thus changing the paths the enemies will take. The levels also contain green blocks. These can’t be raised, but if an enemy walks over them, the block falls down, sending the enemy down into the abyss. With limited amounts of mana to spare, the player must find out which blocks to raise in order to get rid of all the enemies. However, there are times when there are more enemies than there are green blocks. In these situations, the player can also create turrets on raised blocks, raining fire on the enemies. The amount of turrets the player can create is small, but they might be just the thing needed to take care of some extra enemies.
Design and development
We held meetings every Monday during the first few weeks of the project, until we got to an agreement on all the necessary stuff. Programming happened mostly on Mondays and Wednesdays, with stuff being done during the weekend when necessary. The members of our team enjoy various grid-based games, which lead us to the idea of making our own grid-based game. Various different grid-based ideas, such as a turn-based strategy game, but we eventually settled down on making a turn-based puzzle game.
The game went through quite a bit of changes. In the beginning, it was 100% 2D, but the game somehow ended up getting a lot more 3D look than it was supposed to have. The project was kind of supposed to be a 2D game, but the teachers gave us the permission to continue on with the 3D game. The movement system of the game also changed once or twice, as we found better ways of achieving what we wanted. We began with Unity’s standard Navmesh, but ultimately used an A* plugin for our purposes.
All in all, the game finished nicely. We kept the scope of the game small, but since we had three programmers, we could have maybe enlarged the scope just a bit. We also encountered some small confusion with version management branches, but said confusion caused no harm for the project.
