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.
Fox Thief is a 2D platformer game in which the player aims at gaining high score by collecting treasure, fighting enemies and surviving in the dangerous mazes of various locations.
We have created a simple 2D platformer game in which the objective to get a high score by collecting treasure on scattered around in a level. The player can move quickly around the level by jumping off the walls and sliding on the ground in the level.
The stages are “endless” meaning that the game ends when the health of a player reaches zero. The actual level layouts however have boundaries. The layout of the two levels in the game is randomly generated during each play. There is also one collectible diamond to which an arrow on the edge of the screen is pointing to
There are different types of enemies in the levels which will keep becoming more powerful as long as longer the player is alive. The enemies will also start spawning faster the longer player stays alive.
After the player dies, their score is recorded on a local highscore board. The second stage is locked and will unlock if player gets 10 000 points on the first level.
Game Design and development progress
The game design decisions were discussed and decided in team meetings during Mondays. After that the game was developed further during the rest of the week.
Even if we did our best with trying to get the project going right from the start, the workload built up towards the end. In addition, we had to make some compromises on our game in order to keep on schedule.
As a group we felt like having a project manager would have made a huge difference with time management and would have made the progression of the overall project a lot easier.
