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.
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.
I met a team of two enthusiastic game makers, Teppo Hyttinen and Jaakko Takalo during their weekly scrum-style meeting at a coffee house in the center of Tampere. They are working on a promising 3d-game title called Monolith as part of their Games Academy spring semester studies.
The idea for the game called Monolith was born already a few years back when Teppo was mostly thinking about building 2D-games, but then got this idea that he thought might be simple enough for him to implement in 3D even without much prior experience in building 3d-games. Then the school and other projects started and the idea was left to simmer for a while, but after a challenging 2D-game project Teppo felt like he wanted to go all in during the 3D-half of the Games Academy and felt like this idea had a small enough initial scope so that he might realistically get it done during spring.
In December Teppo started looking into Unity and doing some early tests. Jaakko Takalo saw some of those early versions and decided he would very much like to join in on the project. This was more than welcome for Teppo as he felt they would make a good team and he knew about Jaakko’s advanced 3D-modeling skills. With the now expanded team, they decided to widen the scope of the game a little bit from a purely narrative-based game into more of a puzzle game.
Teppo knew from the start that he had to tackle learning Unity 3D in order to realize the game. He started by watching a few basic tutorials online. He went on to build a test level from simple cubes. He remembers having trouble with getting the lights baked and batching which led to the the FPS (frames per second) not being very impressive.
Jaakko was mostly familiar with the 2D-workflow of Unity, but had to now tackle the 3D-workflow, including a proper PBR (Physically Based Rendering) setup. He is using Maya for the 3D-modeling part and Substance Painter for creating the various texture files. The first weeks required watching hours after hours of tutorials online, but with the right motivation even such a task can be overcome. Both team members knew that they are building a serious project and thus there was the feeling that these things absolutely had to be figured out. The hour requirements for a school project were exceeded already during the first month, but since the work was so much fun, they didn’t have to force themselves to perform it.
Teppo had to not only learn the Unity interface, but also how to bring the game together with C#-code. He compliments the drag and drop system of Unity which makes assigning scripts quite intuitive. There are still many challenges to solve though; at the moment Teppo is looking into dynamic parenting. As an interesting detail, he was actually dreaming about a solution for a coding problem, and when he woke up in the morning, he knew how to solve it. This project is big enough to even penetrate the dreams of the team. The famous Stack Overflow -internet community has also proven helpful during this project.
Graphically the big challenge has been getting the various materials to appear realistic, with the right amounts of roughness and glossiness for example. Jaakko has also been learning Z-Brush as a sculpting and retopology tool. He takes the retopologized sculpts to Maya for unwrapping and cleanup, then he brings the cleaned up low poly to Substance Painter along with the high poly version from Z-brush for baking the normals maps and height maps. Substance Designer allows node based parametric texture creation while Substance Painter is the tool for painting in the various textures.
Substance Designer outputs small files that are then used to generate the textures in Unity. This helps to for example keep the installation file size small, since the graphics don’t need to be packed in as bitmap images.
The Games Academy spring semester games will be published during the TAMK International Week on Friday 28th of April. By then this team expects to have their second level ready for gaming. They have been creating this new level for more than 60-70 hours and it’s starting to look good. They will also display a completely revamped puzzle-system, which is more fun than the original.
There will be a chance to test the level during the International Week session, so if you are curious about the game, make sure to head over to Mediapolis during Friday. The demonstrations start at 13:00.
You might also want to check out the Twitter and Facebook accounts of the Monolith team here:
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.
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.
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
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.
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.
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.
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.
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.
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!