Graphics: Veera Tikkamäki, Jutta Urama
Programming: Joni Tasala, Antti Tuomisto, Joel Vidqvist
Design: Joel Vidqvist
External advisor/comic relief: Maks L. Ouhio (name changed)
The game
4 Crosspaws is a cooperative puzzle game for four players. It was developed for PC and requires four controllers to play. Each player controls their own character, all of which are cats.
The game is set in a tower which the players have to ascend by solving puzzles together. Items that can be found on different floors of the tower play a big part in overcoming these trials. Besides puzzles based on the items found on them, the floors also have their own colour schemes.
Crossbow is the most important of the game’s items and also the only one players have from the start. It can be used as a weapon and to get through puzzles. Mana can be collected to upgrade the bow up to two times. Other items include boots that enable the characters to jump, and a monocle that reveals previously hidden objects.
Development process
The development process took about four months. It was the first 3D game our team, Sloth+, had worked on. The team consists of five members: three coders and two artists. The game was built with Unity Engine. Blender was used as the modelling software for the 3D assets and programs like Adobe Photoshop and Paint Tool SAI for textures and other 2D assets.
It took us a while before we knew what kind of game we were going to make. Eventually we agreed on a Legend of Zelda: Four Swords-like four-player puzzle adventure. We decided to make the characters cats to differentiate it from its inspirer. And also because everyone likes cats. The game’s visual style is simplified, lowpoly, and cel-shaded.
The development process wasn’t without its problems. It turned out that the scope was too big for the time we had. We also learnt that making four playable characters, even if they are relatively similar, causes more work than you’d expect. We had to leave out some of the planned features. For example, originally there were going to be four different items besides the crossbow (boots, monocle, magnet, and sword). We were also planning to have more enemy types and minibosses. The game was supposed to end on top of the tower, but this idea had to be scrapped as well, at least for now.
Having to rethink what was actually going to make it to the game so often caused confusion within the team as to what we should be doing and what wasn’t necessarily needed. In hindsight, we probably should have spent more time planning, scheduling and, once it became clear that everything we intended to make wasn’t going to be finished, reprioritizing features. All in all, our team definitely saw the importance of trying to keep the scale of four-month projects relatively small.
The team gathered at TAMK more or less regularly; some were there almost daily, while others preferred to work at home. The entire team met about once a week. The team also regularly got some external help testing the game.
Forge Wizard is a top-down 3D twin stick shooter, in which an apprentice wizard must regain control of his master’s home. Armed with only a few simple spells (game mechanics), the player has to run, dodge, dash, shoot, and collect his way through four wings of content, each with a thematic boss. From the outset of the project, it was our main goal that we control our scope and present a finished game by the end of the course, and we have. Forge Wizard is ready for release, and will be free on itch.io soon after the submission of this report.
The Process
Our team is proud of the hard work we put in, and the game is ready to publish. We feel it’s on par with some of the indie offerings on Steam, which makes it an ideal portfolio piece. The process wasn’t always smooth, and in fact we made several early changes to our concept that were rather large (setting, camera angle, scene building methods, etc)… but all team members were deeply invested in making a finished, polished game, and that was enough motivation to learn and adapt as we went along.
We used a few basic strategies to reach this point. First, we prioritized gameplay first and fit the art and sound design around working gameplay elements. Second, we avoided feature creep by maintaining the same few core player mechanics at all times… even removing our secondary attack early on in the process, to streamline gameplay. And finally, good programming practices were held up throughout the project, never relying on buggy behavior or half measures. This kept our builds relatively bug free, and made those we found easier to chase down.
There was an initial slow start, as ideas formulated and format changes were made (camera angle, for example). The programmers were familiar with the genre and quickly set about prototyping, but the artist was inexperienced in 3D work and took a couple of weeks to study up, to the point of generating game-quality assets. This caused a little friction on the team at first, but an understanding was reached and assets started to flow soon thereafter. This kind of acclimation period seems normal among new teams.
Feedback was vital to the process, so we’d like to thank the various classmates, playtesters, and of course teachers of the course. The game will be released on itch.io for free in the coming week, pending the creation of a trailer and other publishing media.
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!
