GameCamp Summer 2019: Bug Arena and Rock-Paper-Scissors

Period of Play

Mikko Voima – Programmer
Jari Salonen – Programmer
Gerda Skrūzmane – Artist
Jemina Aittomäki – Artist

We present to you two games, one that we started to work on months ago and were able to finish during this Game Camp, and the other shorter project that we brought together in a week during the summer camp.

Bug Arena

This is a 3D arena brawler, where you play as a moth warrior facing off against droves of ants and beetles, using various weapons. The gameplay is broken into waves, where the previous batch of enemies must be defeated before the next can be engaged. The different weapons are littered around the battlefield and dropped by defeated enemies, and allow variety in gameplay as different weapon types have different attacks. 

Find out more about the game and download it for free on itch.io.

Development

Development for the game started in autumn 2018 and the game was eventually released in summer 2019. Our initial inspiration was the general idea of wanting to make a game with combat mechanics, as our previous projects were more focused on platforming and general puzzling. We took directions from Hotline Miami for the perspective and games like Breath of the Wild and Devil May Cry for the animations. Also inspired by the Devil May Cry series, we wanted a simple combo system along with different weapons.

The primary problem in the project was us underestimating how challenging it would be to implement the core mechanics in full, and making them work together smoothly. Player movement versus enemy AI movement, beautifully blending attack animations versus responsive and snappy controls were all interesting problems to solve. Some features were definitely cut out in favor of polishing existing ones. 

The design of the core fundamentals took a long time to figure out, and we went back and forth on issues of player and enemy interactions. As an example, we ended up deciding that to make the enemies threatening enough, they should be able to interrupt the player’s attack by landing their own first. This encourages the player to observe the enemy and exploit weaknesses. To not make the game too punishing or feel unresponsive, we allow the player to perform an invincible dodge from the ensuing stagger-animation. 

Not wanting to spend too much time both skinning the meshes and making sure they didn’t deform during animations, we opted to build the character models around the same armature from separate mesh parts. This also saved us the trouble of making multiple armatures which would have forced us to modify the animations for each armature or even make completely new animations. In the end, only a few animations stayed the same between the characters, namely the moth and the ant. The beetle itself was too different, looking both big and brutish, of a model to look good using the moth’s comparatively minuscule movement set.

In the vein of Hotline Miami, we had the idea of throwing weapons as a limited form of ranged attack, but we never got around to fully implementing it as the combo system took priority and it would have further complicated the control scheme. Another scrapped idea was environmental traps, that would have used the knockback effect of attacks to launch the enemies into spikes for more damage. The remains of this can still be found in the spiked duck you can find in the finished game.

RPS Switcharoo, or the “developers switch roles for a week” project

After such a long project we felt like having a little fun by switching the programmers’ and artists’ roles for a one week project. A Rock, Paper & Scissors game seemed like a good place to start. For programmers that meant opening Blender to 3D model, rig and animate a hand each. Meanwhile the artists would implement the game logic, score counting and animation controller while the graphics were being worked on.

With just the general idea of “Rock, Paper, Scissors” and a point-of-view of the scene to guide us, we ended up taking with the very different approaches to making a hand. One programmer made a slender hand inspired by photographs with short and sharp, to-the-point animations, while the other made a more blocky, chunky interpretation with bouncy, flailing movements.

The artists-turned-programmers learned the basic flow of code, from using public variables in the object’s components, all the way to checking which of the players has the winning hand. All in all, the code needed two heads and four hands on deck at all times.

Switching roles required quite a lot of hands-on mentoring from both sides but it was worth it. Overall it was a very fun experiment that also taught us a lot about what the other team members deal with in their roles on a day to day basis.

GameCamp Summer 2019: The Sound Guys

The Sound Guys

Fansu Janneh: Music and Sound effects
Burak “Kake” Çağlayan: Sound effects and FMOD implementation.
Pauli Ondruska: Sound effects and FMOD implementation.

All About the Sound

Our teams’ tasks, working methods and goals were quite different compared to other teams as our focus was to create sound effects, music and sound implementation for games.

We were in a unique position because we were able to work with different projects either as a whole team or by spreading to multiple other groups at the same time.

In our collaboration projects we had a focus on using FMOD (a middleware digital audio workstation tool that’s used by various leading game companies around the world) to create professional level immersion and adaptiveness to game music and sound effects.

We also had personal projects that either related to learning FMOD implementation, like learning C# and Unity implementation, recording audio or just creating music and sound assets for other teams.

In indie games or games of small budget the typical sound personnel might have to be the sole audio recorder, mixer, composer and sound designer for the whole project.

Development

Stray Sheep

We did not want to limit our creativeness, so every team member was free to create and join in any part of music or sound production. We still started our projects by dividing the work according to our skillset and interests to keep ourselves from overlapping tasks. Kake and Pauli had their focus on in specializing in FMOD and learning to delve deeper into the world of adaptive music and 3D sounds. Fansu was interested in the raw creation of original music and sounds.

In a game called Stray Sheep, we split our workload to three steps. Kake created 8-Bit sound effects, Fansu created the music and Pauli arranged how the music and effects shift throughout the game in FMOD. Stray Sheep was all about speed and running so we got this idea that the speed of the main character advancing in the game makes the music more intense and the effects like thunder and rain to be more frequent as well as prominent.

Stray Sheep visual style was arcade-y and old school, so we wanted to use bit crushed sounds and instruments. We also wanted the music to resemble the atmosphere of an evolving storm, from slight rain to the full-blown storm, splattered with erratic drums and a more primal lead instrument.

 

 

Fansu composing music for a game and looking awkwardly towards the camera

Tavern Brawl

 

We also worked on a deeply thought-out turn-based strategic fighting game. The development team had specific demands for what they wanted the game to look, feel and sound like so we knew we’d have to get out the big “guns” for this one, and by guns, I mean shotgun microphones, industry standard audio equipment and a solid audio treated studio environment.

We recorded all special effect sounds from the ground up, it’s always a great feeling when you have the opportunity to record everything by yourself.

We went to the Mediapolis to record different audio like incoherent drunken dialogue, tavern background chatter, chants and yells. Also, we recorded and edited things like steps on different surfaces.

 

Pauli is setting a double microphone set up for recording dialogue

 

Eventually we had gathered all the material needed to begin working in post. We went through all the recording, choosing the best ones for our goals in mind, organizing them accordingly. Next the fun could begin.

It’s easy to start messing around and trying out new things when you have a lot of sounds recorded and organized neatly. With the theme of the game and the conversations with the development team in mind, we started to mess around with creating the audible world for the game.

Kake explaining sound recording techniques

You never nail the sound on the first try. You always end up trying out a lot of different sounds, layering them together to find the correct combination. It takes a lot of patience, but after a lot of trial and error we had something the we felt like fit the theme of a tavern brawling game.

 

Example of a dynamic music system within FMOD

We fiddled around with creating a dynamic music system for the games we worked on, because we wanted to be able to give better feedback for the player. Music had to be composed with this specific goal in mind. Using a middleware like FMOD allowed us more creative freedom for creating instances like these with ease.

Even though we understand the basics of C# language, it was not enough to start implementing the sounds into the code itself, so we worked together with different programmers on the course to get a better grasp of C# and to assist them with the implementation if needed. The procedures were painless after we familiarized everyone with the basics of FMOD.

All around a productive summer!

Cheers!

 

GameCamp Summer 2019: Tavern Brawlers

 

Team Mugshot
Rami Sihvo – Design, 3D
Jari Hirvikoski – 3D and animations.
Esa Nord – Code

Tavern Brawlers

The Idea

Tavern Brawlers tells the story what happens when bouncer tells ‘you are not allowed in here.’ The core of it is a turn-based fighting game using the same dice system than Rajakatse pen&paper RPG. Indeed designing the system was the easiest part of the game.

Tavern Brawlers uses WRS system in it’s character creation.

The most successful Finnish Fantasy IP

Rajakatse Fantasia is one of ‘Top 100 Finnish Games’ that are showcased in Finnish Game Museum. With the permission of the organization, we set out to do game on most successful domestical fantasy IP. Rajakatse is LARP organization, LARP meaning Live-Action Role-Play. Their events are tavern roleplay, hence why the tavern brawl idea came to mind.

 

Rajakatse Fantasia LARP at 2012
Rajakatse Fantasia LARP at 2012

Art design

The art style was chosen to be more like World of Warcraft like a cartoon with realistic twists. The main body of art and animations was produced mainly from Jari Hirvi, with Rami Sihvo  doing the additional items to levels. With the final build we noticed everything being quite brown. Well, another thing to fix for the next version.

 

Fierce tavern fight going on

Development

We came back rapidly from the grand plans and settled to make it level (tavern) based fighting game. Just dice rolling is annoying, so we added monster infighting and breakable items mechanics. You can knock people back, sending them colliding each other and NPCs starting fight amongst themselves. Esa was hard-pressed to code the game by himself, in retrospect another code would have made his job easier. Same applies with another graphics designer – could have helped a lot. That said, we see a good future with the game and will continue the project in the future.

 

Onwards to glory (or in this case, infamy)

GameCamp Summer 2019: Valley of Brass 

H-Group 

Viktor Haimi – Programmer
Toni Heinonen – Programmer
Vesa Hovinen – Programmer / Level Designer
Olli Heikkinen – Artist
Fansu Janneh – Music

 

Valley of Brass

Idea

We decided to make an RPG game with grid-based combat system. The combat system was inspired by South Park: Fractured But Whole’s combat system, UI by Final Fantasy VII and overworld by Grandia. In this game you control a Harvester automaton called Jules in a steampunk world. In this world there are no living things anymore (but they are coming back).

At first the setting was steampunk with fantasy elements. But in the end, we did not include any fantasy elements in this game.

 

Valley of Brass town

Development

We had 5 weeks to make this game done, and we managed to get finished product done, although we had to hurry a lot during last two weeks. We had good work flow and structure in development, constantly keeping track of our progress, but we still had few hiccups along the way, for example we had to redo our camera control at the last week and few unpredictable absences during the last two weeks.

Art

Valley of Brass was designed to be a fully 3d experience from the ground up. This was somewhat challenging seeing that what we had learned about 3d modelling and animation was during this course and we didn’t want to use premade assets, but there’s nothing that shear will and couple of handy Youtube videos can’t manage. Seeing that with the past few projects I had learned a little about 3d animation and had done some low-poly models I wanted to up the ante a little. That’s why the models in Valley of Brass are smoother, and the textures aren’t as blocky as they were in our previous projects. The world of Valley of Brass is bleak and rusty, fitting well in to the archetype steampunk atmosphere we were aiming for. This game also features rigged models, which means that each animated model has a skeleton of sorts, that can be easily manipulated to create simple animation. Overall, I was happy with our original designs and how they fit the world.

 

Turn based fighting

Story

The story of Valley of Brass takes place in a post-apocalyptic world in which machines have taken over and live ordinary lives in a mostly non-organic world. The player takes the part of a one harvester droid whose mission is to save all machine-kind.
The trick in writing the story was to have an epic narrative that would also naturally flow with the gameplay. That’s why the game tells the story via traditional dialogue windows a la old RPG games such as in Final Fantasy adventures. The story took approx. one week to write and polish to its current state. A few moments from the story had to be cut due to some constrains with the gameplay.

 

 

GameCamp Summer 2019: Sweating Bullets

Team Salt Mines

Aleksi Kervinen: Programming
Miika Minkkinen: Modeling, art
Tommi Mäkeläinen: Modeling, art
Pasi Mäkitalo: Programming, level design

 

Sweating Bullets

Game Idea

Sweating Bullets is a multiplayer first person shooter with customizable playmodes. Theme revolves around steampunk Cold War, in which U.S. and U.S.S.R. spies eliminate each others.

Players can find different weapons during the match that will help killing the enemies. The host player can customize match rules, like player cap and kills to win. In addition, they can choose between normal and instagib mode, depending on if they prefer steadier action or OHKO duels.

The game has two different levels: Arena Factory and Desert Town. Arena Factory has multiple corridors that connect to the center hall where most of the massacre takes place. On the contrary, Desert Town offers narrow and maze-like areas with an option to take cover more easily.

 

Development

Rather than arguing over different game ideas, our team decided quite unanimously to make an fps game. There were many factors leading to this conclusion: the genre was liked by the team members, we had a lot of time to work on the final game, and our programmer was intrigued by the scripting of client-server feature.

The first idea was to make team battle, considering our theme (U.S. versus U.S.S.R.) but free for all was the gamemode we had to begin with. During the playtesting the game felt pretty entertaining (which is rare feeling with so ‘low-effort’ game) so we left it that way. Addition of custom rules, different guns, player board, level and model designs as well as soundscape made the game feel even more enjoyable.

 

 

To name a few challenges, the player models were somewhat a problem. There were some exporting problems and managing the 3D-model hierarchy. And let’s admit it, the programming of working client-server feature isn’t the easiest job. Despite the difficulties, we managed to put it all together with minimum flaws.

Overall we were more than impressed with our finished game. One could say that making a solid multiplayer fps game during five weeks is a bit ambitious but our team accomplished that. Team’s strength in different areas combined with our daily work helped to make this happen.

 

Download our game in the link below:

https://github.com/salt-mines/Sweating-Bullets

GameCamp Summer 2019: 3D-Racer Extreme

Team Undefined

Heikki Kangas: Coder
Arttu Knuutinen: Coder
Anton Isohella: Artist
Mikko Laitinen: Artist

 

3D-Racer Extreme

The Game

 

3D-Racer Extreme is a racing game(duh). The goal of the game is to drive through a track specified by checkpoints. The game has two levels.

Development

 

The idea for the game came from our previous 2D racer project. Artists focused on creating the terrain and models for the checpoints and various props in the game.

Unity offers quite powerful tools for creating terrain out of the box. As such the process was quite easy. There was a model made for the car but we never implemented it.

 

 

The car we used was a prefab from a free package. It had premade scripts for the driving, which made it easy to modify them to our liking. The coders made the scripts for the camera and checkpoints. Everyone tested the driving to get the feel right.

The game has not been released.

 

GameCamp Summer 2019: Fallout City

Team B-Rap Boys Extreme

Jami Salonen – Programmer
Timo Sissala – Programmer
Kalle Saarinen – Programmer
Saku Pajari – Artist

Fallout City

The Game

Fallout City is city builder game where you try to build city in post-apocalyptic world. As your population rises, your citizen unlocks different “Needs” like safety and healthcare that are fulfilled with new buildings that are unlocked at the same time.

Fallout City isn’t 100% complete yet, for example its missing way you can lose the game and some other minor things.

We had a lot ideas for mechanics and other stuff that never made it into the game, mostly because of the lack of time.

Development

At the start it was kind of difficult to get enough things to do for 3 programmers, also we had a lot of skill level differences in programming so it made it even more difficult at start.

We had some problems with Unity’s own isometric tilemap, but after figuring out how it works, most of the development went without any bigger problems.

At this moment we also had rough idea of which game mechanics we needed to drop out so we would have somewhat playable game before final day of the project.

In the end our game missed some core ideas we had planned, but one of our team’s main focus was on learning game development.

GameCamp Summer 2019: Steampunk Shooter

Members of ‘Työttömät’

Ville-Veikko Nieminen: programmer; player behavior, UI designer
Toni Silventoinen: programmer; physics & enemy behavior
Jouni Lahtinen: 3D artist
Teemu Kivioja: 3D artist, level designer

Steampunk Shooter (working title)

The Game

Steampunk Shooter is an FPS (first person shooter) in which the player tries to survive in a city which has been taken over by robots. Player has two guns to choose from: a handgun, weaker in terms of damage and range but has infinite ammo, and a railgun, a rifle-like gun with greater damage and range but has limited ammo. Player also has a jetpack which allows for a short burst of flight.

The main enemy players face are humanoid robots of two variants; gun wielding and bare-fisted. Robots with guns stand back and try to shoot the player from afar whilst bare-fisted robots try to rush to the player and beat them with their fists. When player kills an enemy they may drop some extra health or ammos for the player to help them progress. At the end of city there is a giant spider robot who serves as a final boss. Player wins the game by defeating them.

 

Robots patrolling in small group.

 

Enemy behavior

Enemy spawn points contains prefabs of enemies and patrol points.
They have ability hear from fixed distance, calculated from navmesh path. Additionally they can navigate to the next corner where sound was coming.

Enemy ability to see have been made with direct raycast to player and calculated angle as see cone, if player is seen enemy comes directly to shoot (or hit) distance and attacks. Hit rate is randomized. If player is only heard enemy checks sound source point and after goes back to patrol points. If player is seen and then not, enemy goes fixed distance to direction where player was seen to go and then starts random patrol there.

Final boss have also ability to spawn little spider robots.

Final fight.
Enemies coming
Railgun scope view

Development

We started the development wanting to make an FPS game but we didn’t know what kind of theme it would have. We settled on a steampunk-ish theme pretty quickly.

Throughout the development we thought of new ideas and mechanics to include and whilst some were included some had to be left out. Originally we wanted to have more guns for player to collect and use but eventually we settled on the two guns available. We also wanted to give player some melee option but as the deadline came closer and no development was done for it we decided to give the handgun infinite ammo instead so player always has some way to progress.

Overall there are lots of things that could be made better and we believe it could be made to into a great game if we were to continue its development.

GameCamp Summer 2019: Flail or Die

Team helpDesk

Elias Pohjalainen – Programmer/ Artist
Santeri Saraluhta – Programmer/ Artist

Flail or Die

Flail or Die is unique multiplayer arena game. Game mechanics are fun and simple to grasp. Player controls a plain character equipped with a medieval flail. Characters are battling against each other atop the tower. The last man standing is the winner. In addition to hitting another player with a flail it is possible to fall to the death from the tower or disarm an opponent.
Game visuals are made clear for a player. Art style is based on medieval era. Props on the tower are minimalistic to help keep focus on the game. Characters are quite colourful to further differiante characters from each other.
Flair or Die has a starting screen where players can join the game. After joining the game a player can identify his/her character by controlling the characters hands. This neat trick opens a new whole minigame for player to have fun with.

Development

Game idea is based on all the similiar top-down arena fighting games. Visuals are simply from generic medieval times apart from the character design. Characters are kept as plain as possible to keep them visually appealing for the audience.
Game is using Unity engine, 3D-design is made with Blender graphics toolset, and some textures are done with GIMP image editor. Sound design is outsourced. Five weeks were spent on the developing of the game.

GameCamp Summer 2019: The Guardian of Dawn

Team Spaghetti Games

Jaakko Panula – Programming
Eetu Tirkkonen – Design, Music
Roni Kähäri – Art
Miika Ronkainen – Art

The Guardian of Dawn

About

Awake again, after eons of sleep. Why now? What came before?

The Guardian of Dawn is a top-down adventure game set in a verdant forest of time long past. You must seek out curious relics to forge your way forward and find your purpose.

 

 

The game features two different items that let you traverse the world in different ways. The holy flame will light up dark areas and let you burn enemies, and the teleporter orb will let you instantly move as far as you can throw. The Guardian can also attack enemies with his fists, as well as block incoming attacks.

The game features two original piano-focused songs to set the mood, amazing colors and environments to explore and a protagonist who, while silent, is totally adorable.

 

Controls

Arrow keys / WASD – Movement
F – Attack
G – Defend
H – Spark flame
H (hold) – Extinguish flame
J – Throw teleport orb