Milk Carton Games Logo
Brew & Brawl Logo
Baltica Logo
Brew & Brawl hammer hit
Brew & Brawl hammer hit
Brew & Brawl hammer hit

Brew & Brawl - Gnomes vs. Dwarves

Screenshot

Brew & Brawl - Gnomes vs Dwarves is a couch multiplayer party game with MOBA elements, where Dwarves fight Gnomes over access to a magical brew. Conquer your friends and foes in this Nordic-themed, colorful, upbeat brawler!


Brew & Brawl - Gnomes vs Dwarves was made by Milk Carton Games, and released on Steam October 29th 2020.
Brew & Brawl started as an entry for the game jam NM i Gameplay hosted by the Norwegian Film Grant NFI.
Development was supported by Viken Filmsenter.


Øivin did all the programming, UX design, animation, as well as roughly half of the game design. Brew & Brawl is made in Unity and written in C#.


Screenshot Screenshot Screenshot Screenshot Screenshot Screenshot

Character Rigging & Animation

Brew & Brawl is a game with a fixed camera. Not only that, but the camera is far away from the characters. In order to convey character, the timing and exaggeration becomes incredibly important. All the characters in the game have a certain bounce to them, and move their body parts more than required to increase the theatrics of it all. To add to the bounce and dynamic feel, some of the secondary action was facilitated through rigging floppy parts of the characters, like hats, beards and ears. While not extremly noticable in all instances, it ties the believability together.

Because the characters are small on the screen, in order to give the characters weight, and their attacks a satisfying feel, the animations have been further exaggerated in this regard. Again, timing is important. You don't conciously register the extreme exaggeration in scale in full speed, but here in 25% playback it's clearly visible.



Footsteps

Having most of the development on the game on a map covered in snow, not having some sort of footsteps would feel amiss. In the early builds, a step sound was played, and that was that. However, when we introduced new maps without snow, having snow SFX everywhere stared to seem off. To solve this, I wrote a system that bakes a texture map based on terrain data, and looks up what SFX to play in the texture based on the character's position on the terrain. Play video with sound:

The same system can also be used to determine whether to leave a foot print (or what type of foot print) as well as particles or any other data. It uses the texture's RGBA values as a 4-bit bitmask allowing up to 16 different step behaviors. Having proper feedback from the ground under your feet ties the world together more and increases immersion.

UI Design

The UI philosophy in Brew & Brawl was less is more. Why? Because making an action game, the focus should be on the action. Excessive UI would either cover the screen close to the characters - something we didn't want for readability in combat - or be out of the way at the edge of the screen like in a 2D fighter - which takes the eyes away from your character.

To solve this, we make the characters sweat and steam after having dashed to indicate the cooldown instead of showing it in UI. Instead of having a wave timer somewhere, we made the areas where the creeps spawn glow with a particle system some seconds before spawning.

Some elements were so crucial to know the exact timing of however, that we had to have some countdowns. Due to trimming down most other UI, it still doesn't cover too much of the screen. It would have been easy to opt for some generic UI, but that would be a missed opportunity. Instead, Brew & Brawl employs a UI style that ties into the content of the game - a gauge filling with brew serves as a timer, instead of a simple progress bar.



AI Implementation

In Brew & Brawl, the gameplay is focused around the PVP aspect. During development, however, it became clear that the game needed an AI that could take control of players in the absence of humans. This was both for ease and speed of testing as well as useablity. Originally, the AI was not going to be a big part of the game. Just a rudimentary addition to facilitate tutorials and testing. In the end, we found it very enjoyable to play with or against the AI, and among other things it enabled two players to team up against the computer. All this meant that the AI needed to be both intelligent and robust.

The AI is mostly deterministic. In other words, given a certain state of the game, the AI should behave predicably and pursue the most relevant goals. The AI works on a basis of evaluating every objective and player present on the map, and assigning it a priority weight based on the objective's position in relation to the AI (and sometimes in relation to other goals or players). The AI will then pursue the goal it considers of highest value. How it weights different actions is also partly determined by it's difficulty setting.

Example: The AI knows it's nexus has a lot of brew in it compared to the enemy's tank. In other words, it considers itself safe and should go on the offense. Given the opponent is relatively far away from their tank, and slowed by carrying a lot of brew, rushing to their base for an attack would be a good strategy.

The only failure on the part of the AI is that they don't move like players. Their movement can at times be very predicable - for instance they will always run away from a player that has a HP advantage - and at other times the movement is choppy, when the pathfinder is recalculating paths parrallel to the AI evaluating it's targets.

Optimization

Making a game both look great and run on all sorts of mismatched hardware is no small feat. While Brew & Brawl certainly is not as optimized as it could be, some aspects are definitely trimmed down for this purpose.

  • AI calculations only run about twice a second, and the calculation itself is spread over several frames
  • Some collision and proximity checks are run every 4 frames
  • The light is mostly baked with only very limited realtime lighting
  • A lot of objects are manually batched to reduce draw calls
  • Transparent shaders are used sparingly to reduce overdraw, although some is inevitable
  • Reduce physics calculations per second because the game movement is relatively slow

Because our camera is mostly static during play, some special measures can be taken:

  • Draw order of objects are manually chosen to reduce overdraw
  • Most instantiated objects are pooled to reduce heap allocation




War Crimes

My entry for Ludum Dare 44 in April 2019. The theme this time around was "Your life is currency".

War Crimes is a 3D bullet-hell shooter made in Unity. It was made during the designated 48 hours by only one person in all departments. This take on the theme sees the player using fuel for their tank as both currency, health, and as fuel (deducted slowly as you move). In other words, there is only one resource in this game.

The enemies are randomly generated stat-wise based on how far away the player currently is from the central upgrade depot. The enemies can also utilize more or less the same upgrades as you do as the player.

The available upgrades and enemies had to be balanced against each other, as well as the costs of said upgrades. With the very short time available for development, this balance is not perfectly tuned, but adequate in that it provides a constant challenge if the player seeks it.

Readability

Something that must be taken into consideration when making bullet-hell-type games is readability - in other words, does the player understand what the objects on the screen mean?

In this capacity, the game was both successful and unsuccesful. Much care was taken that the objects did not blend with the background, however, as the color of the enemies is randomized, by pure chance, sometimes the enemies are particularly well camouflaged. In the later revision of the game, the tanks have more readable shapes which helped mitigate the problem.

Sound Design

Ludum Dare Compo rules that the contestant has to make everything themselves. This includes - of course - sound. The sounds in this game are important to signal to the player what is going on on- and especially off-screen. Using samples of everyday household items and mixed in Audacity, the sounds of War Crimes serve to give the player spacial awareness. The different sounds signpost an enemy firing, launching a missile, or being hit.

Usability

In the compo version, there were two major issues: enemies spawning off-screen behind the player, and that the player was uncertain whether they landed their shots because of a lack of hit feedback. These two things were later fixed by adding a radar upgrade that points towards enemies, and a function that makes all hit objects flash yellow if they take damage. The system is still not perfect, but plays a lot more intuitively.

Play in browser here!
LD Page


Heartache

My entry for Ludum Dare 41 in April 2018. The theme this time around was "Combine 2 Incompatible Genres".

Heartache is a 2D platformer-meets-tower defense-game made in Unity. It was made during the designated 48 hours by only one person in all departments. The game focuses on balance and fun, while keeping the scope minimal. There are three different enemy types, and four different towers to build. To reinforce the tower defense-mechanics, the enemies cannot harm the player character, only the heart.

The enemies scale as you get further into the game, and the amount of enemies and the amount of coins they drop also scale based on a formula. The game has no win-state and is in theory endless. While this was never intended, some players have completed hundreds of waves in the game.

Game Design

Heartache combines platforming and tower defense. The most important thing in a 2D platformer is the tightness of the controls and jumps of the character. Because of this, a lot of time went into making sure the controls felt right. In a tower-defense game, the whole interest comes from the strategy of placing different towers in different locations. Since time is a precious resource in a Ludum Dare competition, a small amount of towers which played very differently from one another were devised.

Play in browser here!
LD Page


Baltica

Baltica is a cartoony fantasy-renaissace city-builder made in Unity. It was being by a team of 5 Norwegian indies, where Øivin did all the programming, as well as parts of the game design, UX design, graphic design and particle systems.

Baltica is a game about building and defending your city - all the way from a small settlement, up to a proud city state. It was never fully completed, and has currently only some features implemented, including building, resource gathering, and rudimentary combat.

Programming Challenges

  • In Baltica, there are many factions of enemies, and different types of attacks. These are balanced against each other with a tag-based system.
  • Resources are persistent in the world, meaning that a plank put in a specific warehouse needs to be retrieved from that warehouse. A system is in place to make workers intelligently locate and move resources to where they are needed.
  • All characters in Baltica employ pathfinding. The navmesh has to be updated regurarly when buildings are placed.
  • Ranged units need to fire at moving targets. In order to have a chance of hitting, they currently predict where the target is headed based on its current movement.
  • In Baltica there is an emphasis on creativity and building the town you want. This is why we implemented the ability of curving walls when placing them. This modifies the mesh in real-time while approximating its hitbox when the building is placed.


Milk Carton Games

Milk Carton Games is the website for the epynomus development company. It is designed with Bootstrap with a focus on scaling for mobile platforms. The website is static (no server scripts) with the exception of the newsletter, which is actually an iframe to this domain.

Screenshot

Brew & Brawl

Brew & Brawl is the home for the game under the same name. It is designed with bootstrap and Lightbox2. It is focused for mobile platforms and serves mostly as a marketing medium.

Screenshot

Øivin.no

You're looking at it! Unlike the other two, this site does not use Bootsrap. Instead it is designed from the ground up (for better or worse). As a result, it doesn't scale as smoothly on all devices (huge phones or small tablets especially), but on the other hand there is more creative freedom to be had. The galleries still use Lightbox2.



© Copyright 2019