What we have been working on

Oakmound has been a little quiet on this blog for a bit and we wanted to jump on and let you know what we have been working on.

Engine Improvements:
A lot of time and effort has been put into updating Oakmound's (now open source!) engine oak. If you are interested in the internals there has been a focus on a 2.00 release which entails a serious amount of refactoring and to support new API changes. Some fun things to look out for here are the integration with our new branch of the underlying graphics library (shiny), easier/more extensible api for internal oak constructs, and many small features such as screen shake.

Agent Blue Full Release:
We have been working on putting all the final touches together for our first release version of Agent Blue. This means we have been finishing up and redoing art, adding a new enemy, updating enemy ai, adding inter game progression, and fixing bugs. See below for some of the new features and updates we have implemented.

Lowrez Jam

Oakmound participated in the 2 week Lowrez jam 2017, The lowrez jam came with the constraint of only using 64X64 pixels on any screen but it did allow for upscaling. We made the game "A Fantastic Doctor" which is a game about 'curing' alien patients via shrinking into their organs and fighting their diseases. As with all of our recent games this game was built on top of Oak and its source code can be found here.

See below for some screenshots from "A Fantastic Doctor"

 

Agent Blue 0.2.0 Demo

Download the Win64 ZIP here!
Download the Win32 ZIP here!
Download the Linux64 ZIP here!



0.2.0 Changelog:

Version:0.2.0

Bug Fixes:

• Box Physics are more stable
• Levels no longer have pathways to nothing

New Features:

• New Ammo Bar
• Goons have a little more scripting to their actions, and make noise
• Level names are meaningful
• Healing supply points that enemies will now retreat to.

(This is a very early alpha, the game may crash and is has a number of unfinished levels and assets. Feel free to give us feedback here, or you can email us at oakmoundstudio@gmail.com. We have limited machines to test this game on, so we'd especially appreciate messages about any crashes that the game produces!)
.

Oak Engine Open Sourced

Oakmound Studio has been working on Agent Blue for over a year and has developed an Engine alongside the game. Today we are happy to announce that our engine Oak is now at a stable point where we have decided to finally open source it on github. The Oak engine provides the basis for Agent Blue from creating the screen all the way up to the particles and collision system. If you are interested you can find it here.

Interacting with the environment

Stay tuned for the upcoming changes to Agent's collision and environmental interactions. Most recently we added collision to non-characters allowing them to be pushed and push each other completing our basic physics engine. In the next build you will be able to experiment with pushing around boxes to mess with enemies and open new paths for yourself!

Push boxes around to see how enemies, the environment and other boxes interact. Tell us if you find anything particularly great!

Agent Blue 0.1.0 Demo

0.1.0 Changelog:

Bug Fixes:

• Orbs no longer wander (only patrol)
• Goons pathing has been improved (not running into walls as often)
• Level Select room text is now readible

New Features:

• Level Select room is cleaned up, uses different tileset
• Entering a level as a new animation
• Physics system now includes pushing and knockback
• Oil is now slippery
• Goons attempt not to kill eachother
• Goons will throw grenades at players in crawlspaces
• Added animations for attacking while crawling
• Added Music
• Added SFX for being unable to open doors

Download the Win64 ZIP here!
Download the Win32 ZIP here!

(This is a very early alpha, the game may crash and is has a number of unfinished levels and assets. Feel free to give us feedback here, or you can email us at oakmoundstudio@gmail.com. We have limited machines to test this game on, so we'd especially appreciate messages about any crashes that the game produces!)
.

Collision Features

Oak uses a fork of rtreego for its collision with extended features like raycasting and trigger functions on collision with labelled entity types.

One of these features allows a programmer to receive collision events when collision begins and ends against certain labels, and another lets a programmer attach collision spaces to vectors so whenever a character moves around they'll take their collision space with them. These two features are demonstrated in the following code and animation of the resulting compiled program:

Item rarity

In a previous post we described how different items are created and mutated on some of their attributes and today I want to talk a bit more about how this works on firearms. Today we have three rough types of firearms for the player to use each with the following stats: delay between shots (Delay), usable ammo types(AmmoTypes), spread of fire (Spread), ammunition consumed per shot (AmmoPerShot), volume of effect (Volume), current upgrades (Upgrades). Each type of weapon has its own rating system where it gives itself a rarity on a scale from 0 to 1 which is used both in loot placement and to display quality to the user as seen below where the yellower a firearm is the better.

Great Pistol

Below Average Pistol

In fact not only does the inventory representation change based on quality but the item's appearance on the ground changes as well. Currently we do not have models for firearms on the ground, so they show as black boxes, but we do have particle effects to show you their rarities!

Rarity Particles

With our generation system and rarity system be uniquely determined by a given firearm type we keep a consistent metric while also ensuring that our weapon types feel really different. For example while our sprayers (think flamethrowers) are quite different from rifles, our pistols operate in a pretty similar hitscan fashion to our rifles. To distinguish these two weapons and keep their niches separate you will find that pistols tend to be slower with potential for more power while rifles tend to have more Spread with much smaller Delay and less AmmoPerShot.

Thanks for reading, try to experiment with weapon types and keep your eyes peeled for rare weapons!

Devices; Play Smarter

Agent Blue can be pretty hard if you are just running around shooting normally, so which two devices you decide to keep around can really make or break your run. As of the current build version 0.0.2 the player is able to use two devices at a time, find new devices, and find drops that recharge their devices.  Devices can do anything from modifying your form of sight to letting you fake your death

Normal Sight

Night Vision (extended sight)

Faking Death

In version 0.0.2 there are 7 types of devices with another 5 already planned. Try to find/play with them all!

Agent Blue 0.0.2 Demo

0.0.2 Changelog:

Bug Fixes:

• Enemies will spawn out of bounds and inside walls less (maybe not at all!)
• Four-core machines will experience significantly less (hopefully zero) input lag
• Fixed a crash related to windows thinking Oak was not starting up fast enough
• Devices have had a number of bug fixes
• Some color display issues with particles were resolved

New Features:

• Crawl Spaces have unique walls

Download the Win64 ZIP here!
Download the Win32 ZIP here!

(This is a very early alpha, the game may crash and is has a number of unfinished levels and assets. Feel free to give us feedback here, or you can email us at oakmoundstudio@gmail.com. We have limited machines to test this game on, so we'd especially appreciate messages about any crashes that the game produces!)
.

The Oak Renderable Interface

This post will serve as a tutorial through the render package, Oak's largest built in package and the basis for drawing elements to a window.



To draw arbitrary objects to a window, Oak uses the Renderable type, which in short is any type that can be drawn, has a position, has an order for when it should be drawn with respect to other Renderables (a layer), and can be Un-drawn. Particles, as written about a few posts past, are themselves renderables and are in a subpackage of the render package.

Most Renderables are also Modifiables:



So while Oak has a number of built in Modifications involving color modification, scaling, and shape changing, users of the library can build their own Modifications using this signature, and the result will be compatible with most built in Oak types.

Users can also write their own Renderable or Modifiable types, an example being the radar in Agent Blue (although this is 10 months old, and API improvements have made it easier to do some things the radar is doing).

Oak currently has nine Renderable types outside of particles:

• Sprite: the most basic Renderable, a sprite is just an *image.RGBA with a position. There are plenty of ways to construct a Sprite-- lines, boxes, gradients, noise, and of course loaded image files are all built into the engine.  
• Text: anything that implements the fmt.Stringer interface can be turned into a piece of text that can be assigned Font settings on the fly.
• Animation: a sequence of positions on a Sheet animating at some frame rate.
• Sequence: an animation that does not use an underlying sprite sheet, but a list of renderables instead. 
• Composite: a list of other Renderables to be drawn as one unit.
• Compound: a map of Renderables that can be switched between at will, where only one is drawn at any point in time. This is useful for characters that can have one of any number of animations active, like attacking versus moving. 
• Polygon: a list of points drawn as a 2d shape.
• Reverting: a Modifiable that can be modified multiple times, but remembers what it used to look like. This is used for applying temporary effects.
• ScrollBox: a box which wraps around some set of Renderables and draws them inside a small viewport. This viewport can scroll horizontally and vertically, and the renderables inside the ScrollBox can be set to reappear after they've shifted some amount. 

Look for tutorials on using each of these types once Oak is released publicly.

It's worth noting that all of these types are implicitly 2D, and this is at least in part because we don't want to target 3D drawing or 3D games until we've got the current API stable and performant. I have experimented with making 3D Renderables in Oak, and that work can be seen here.

Agent Blue Demo 0.0.1

We've put together a demo release of Agent Blue!

Download the Win64 ZIP here!
Download the Win32 ZIP here!

If you dont know which one to choose, choose the Win32 version, and stay tuned for a potential Linux release in the coming month!

Note that, as this is a very early alpha, the game may crash and is has a number of unfinished levels and assets. Feel free to give us feedback here, or you can email us at oakmoundstudio@gmail.com. We have limited machines to test this game on, so we'd especially appreciate messages about any crashes that the game produces
.

Status Effect Interactions

Status effects and their interactions are a critical component to making Agent Blue fun and most importantly interesting. Effects have two states in which they interact; on entities and on the ground.  In game we have implemented fire, water, oil, agent, sleep, stun effects and made them interact with each other and different enemies in unique ways. In its most basic form each element has an antagonistic element that it counteracts as well as one other element it interacts with. For example oil will be consumed and lit on fire but will be doused by water or crawling.



Take note: If while playing you notice little particles coming off your character it means you are being hit by an effect and if you change color... well then you are affected by some status and should look out!

Particles

For complex effects in graphics engines, using standard drawable types like image files can lead to memory and cpu-intensive operations, and the general solution for this is to use a Particle engine. Particle engines are named as such because their core renderable object, the Particle, is lightweight to draw to screen and update.

In Oak, we have four groups of particles:

• Color particles, which can be assigned a start color and end color for however long they last, smoothly transitioning from one to the other.
• Gradient particles, which are just like color particles but can have their particle be a circular or horizontal gradient, or something similar.
• Sprite particles, which throw away 'being lightweight' and just serve as generators for sprite images or other renderable types in the engine like animations. 
• Collision particles, which wrap around any other particle but contain a collision space so they can react to the game environment. 

Oak's particle engine is based off of CraftyJS's particle engine, with significant modifications (and written from scratch, as we're in a different language). Some settings a particle can have are how gravity affects them, how much they rotate per frame, how fast they move, what angle they move at, and so on. Below is a demo of how most of these effects change a single color particle source:

The code used to make this demo (which is an oak program) can be seen here, (although it needs some documentation!)

Automated Cross Compilation in Go

Cross compilation has been touched on before for Go, but one thing about it was always a little frustrating to me, and that was that the manual redefining of environment variables for multiple compilations took a long time and required manual tuning.

There are two observations we can make that can change this, and can automate multiple compilations in way that's universal across platforms:

1. You can call Go from within Go

 exec.Command("go", "build", "-o", output, packageName).Run()  

2. You can define environment variables from within Go

 os.Setenv("GOOS", "windows")
 os.Setenv("GOARCH", "386")  

With this in mind, we can built a script in Go that automates cross compilation! For each OS/Arch pair we want to compile, we can set the environment variables and run go build with a unique output name. Because Go provides a list of all valid OS/Arch pairs, we can also write a script that accepts variable packages and pair definitions, and you can find that script here.

This doesn't change how long it takes, as compiling for 20 different platforms involves recompiling a lot of the Go standard library every time, but it does mean we don't need to sit around and wait for each compilation to end to write in the next pair to compile for, and because the script itself is written in Go, we know the script will work on all Go platforms, whereas bash would have issues with windows. 

Loot Distrubution

Today we will be talking about how we handle loot distribution and its place in Agent Blue's replay-ability. Loot distribution includes both the choice of loot items and how they are placed across the level which is both the total possible loot and the ease of access. The main goal here is create a consistent yet in the end randomized experience that lets us tailor level difficulty without sacrificing replay-ability.


Levels are created with a total value of items and a range of locations to place potential items. Each zone type has a different base distribution of item drops such as weapon types and consumables which when combined with item values and item locations helps ensure consistent level progression across games. Given these parameters we spawn a series of potential item distributions which we then evolve over a period of generations to get closer to the target item value dictated by the level. We can add new rules to manipulate the item distribution to create a different feel for each level or to mix up the balance later. At the moment we are starting with fairly simple mutation process which will change a single attribute or item per generation but we will also be able to do more complex crossover and mutation chances to create more complex and diverse distributions.

With the levels generated players are given an abstracted view of what a level has to offer and get to choose which path to follow. Having generated a set of items the levels then place the items across the provided locations (which is often in locked goody rooms). It is possible for the player to get all of the loot if they traverse the level carefully. Beware there may be rooms with loot locked by your original keycard color which there might not be a re-encoder for on the level!

Into The Forest We Go

So up to this point, Agent Blue has been using a basic interior design for the terrain. This was helpful for early development since the hard lines and machined patters are easy to do and make look nice using the tiled system that we are using.

A new addition is the forest area. Being a more natural area the hard, straight lines that were used before won’t work but there is still a need to conform to the tile system that is used for level generation. The way that the new forest tiles are drawn currently no two consecutive tiles should be more than one pixel off on the border height so that they flow from one to the other. The only concern currently for this tile set is that they may become too repetitive when there are long stretches of the same tile. As development continues these tiles may get an update or new additions to fix this issue. Until then I hope you enjoy your walk in the park.

 

Enemies First Look

Agent Blue is stealth centric game and as with any stealth game there needs to be a diverse set of enemies to create a rounded set of challenges. Regular levels in Agent Blue are on a sort of timer before Goons from other zones start showing up and systematically sweeping the entire level forcing the player to keep moving. If an enemy sees or bumps into the player they set off an alert which brings other enemies running.Enemies each have their own unique niche/job such that by themselves they are easy to deal with but in conjuction are dangerous. The general niches for enemies are as follows; forcing the player to keep moving, forcing the player to escape from a space, and forcing the player to take a measured thoughtful approach. At this point we have four types of enemies who together build and keep the players pressure up.

VRoomba is the simplest enemy which scours the level for the player so that it can alert its allies. They specialize in forcing players to move out of the corridors and into the more interesting rooms. VRoombas are predictable and blind but fast, catching the unwary or distracted and alerting their brethren to come finish off the player.

Orbs are a standardized damage dealer who patrol a route and deal high damage to players caught in rooms with them. Orbs do not hunt the player and will pass them by in the corridors if they don't bump into them. This helps make rooms more dangerous as many enemies can be especially deadly in corridors. In general terms this means that orbs force the player to move and plan their entrance into rooms in a measured fashion.

Trashcans specialize in hunting the player to the exclusion of all else. They wander around and rely entirely on sound to detect players to zero in on them. Trashcans serve as the main deterrent to players acting too brashly, forcing them to keep moving from any point where they made noise and plan their noisy actions, such as running or shooting, carefully.

Goons are a jack of all trades and perform some of every function. They can hunt the player to force them to move and force them to escape. By fulfilling most functions Goons are a safe bet to up the difficulty with and are added in circumstances such as when the level timer has ticked along sufficiently.

While we may be adding to the enemy set in the future we are being very conscious of keeping our enemies distinct and interesting which means keeping the number of types down.

Title and Failure

Here are two new illustrations for Agent Blue that I have been working on recently.

Agent Blue Logo

Mega Man VII Logo

This is a take on the title card for the game. Once again working with the limited color palette. I tried to have a part of it be referential to classic SNES title screens such as mega man but with its own twist.  

Agent Blue Failure Screen

Zelda II Death Screen

This will be the failure screen. For this I took the minimalist color pallet to an extreme by only using three colors. For this one I was mostly shooting for a feel like the Zelda II death screen but since there is no real big bad other than the factory at the moment I went for a more industrial feel instead of focusing on an antagonist.

Color Palette Choices

When I started to make art for this team I had come from mostly working with paints and pencils. Pixel art was a new thing to me and even though I had read a lot of tips about it, I still had to learn many of the lessons the hard way while building these games. One of the more important lessons I learned was about how to choose the right colors for the art.

It has been a long time since the NES era with majorly limited color palettes and it can seem tempting to go use every color a monitor can generate to work with, but I have found that using a select color palette can solidify the tone of the art and give you a much better overall product. For example, compare these shots from Esque and Agent Blue.

Esque Agent Blue

While the lighting effects are more sophisticated in Esque, I would say that Agent Blue has a more cohesive art direction given that there is a limited range of colors to make up the base textures. Currently all sprite art for Agent Blue is being made using a modified NES color palette.

Agent Blue NES

I removed some of the more similar grays as well as added darker versions of all of various colors in place of the empty hex values. Every sprite I draw for this project uses only these colors and I have found that it has pushed my creativity when coming up with how to depict certain things, even if there are not enough colors to do it in a more traditional manner.

Window Sizing on Windows

Sometimes when you write a piece of code that you think should just work, or return an error, it does neither. As it so happens, sizing a window for an application on Windows is one of those situations.

All three of us at Oakmound use Windows computers, so Oak, while hypothetically compatible with other operating systems, has only ever been tested on Windows as of now. One issue that we've had since the beginning of working on this project relates to this line of code:

 // s is of type shiny/screen.Screen  
 s.NewWindow(&screen.NewWindowOptions{640,480, "Window Title"})  

This code uses Go's built in UI library, shiny, to open up a new window that we can then draw to. It looks like it should open a window that's 640 pixels wide and 480 pixels tall. Until very recently, that was only sort-of true. The window size of the created window was, on some versions of Windows, 640x480, but we were expecting that the client size would be 640x480. The client size of a window is the workable space of the window, without borders given by operating system:

What this meant was if we made our 640x480 window and then tried to draw the player's healthbar at 320x450, it would never show up.

After some experimentation, I discovered that Windows would always reduce the width we were given by 16, and the height by 39, with a minimum size of 120x0. For a quick fix, we increased the dimensions of anything we wanted to create by 16x39, but given we already had reason to distrust Windows we went a little deeper into the issue and raised a issue with golang to resolve the problem.

It turns out, if you really want your client size to be a particular value on Windows, you need to create your window and then immediately resize it, which thankfully shiny now does.

To make sure this doesn't cause issues on other operating systems, we also now scale our internal 640x480 buffer for Agent Blue, which stores all of our active graphics, to whatever size the OS gives us.

Agent Blue UI

Agent Blue has a variety of items, from weapons to ammo counts, that a player needs to keep track of. As we started to get non-engine elements into the game it has been a struggle to balance between the amount of information on the screen and screen clutter. Just for example it's important to know what the exact statistics of a weapon are when deciding if you should throw it away but it's not important to have those stats showing when hiding from an enemy who could sneak up in the screen space covered by the weapon information.

Current inventory screen (not final)

There are alternating phases in Agent Blue, first you get a relaxed mission planning stage and then you are transported to an actual level where you have an objective to complete while pressure mounts. We wanted to give players the ability to choose their items but we don't want them to slow down mid level to puzzle over exact stats, at the same time there are items a player can pick up mid level that they need to be aware of. To solve this issue we added a special function for sliding in specific UI elements.With this functionality we were able to implement both the ability to slide in changed UI elements such as when the player acquires a keycard and the ability to slide in all the nonessential UI if the user holds down a button while not taking over the screen like the inventory screen.

Nonessential UI onscreen (not final)

Nonessential UI offscreen (not final)

The new slide behavior has allowed us to better differentiate between the sections of our game and reinforces the underlying design. To recap we have a larger more detailed view of inventory between levels where a user can really build their character, UI that gets out of the users way and a way to unobtrusively signal that the user has acquired something new that the need to take notice of immediately.

Agent Blue

Agent Blue is Oakmound Studio’s current project, our first since shifting to program in Go. A 2d game in the style of Metal Gear, Agent Blue has the player navigate through levels populated with hostiles, sneaking around and dealing with them in any way possible.



Agent Blue’s levels are procedurally generated and death is permanent, making the game a stealth-based roguelike. It rewards careful resource management and being picky about what conflicts one engages in.



We’re also creating Agent Blue to see what problems come up as we develop Oak, a Go game engine which we hope to release as open source when we are happy with its API. We are updating Agent Blue and Oak every week and we are happy to receive and incorporate feedback as we go.

We will be writing posts about our development process and new features as they are added to the game. If you are interested in our game, how a group like us makes games, or even just how long we can keep writing then please write a comment!

Oakmound Studio

We are a group of three who love games and love making them in our free time. Over the last 1 and a half years we have worked on 3 major projects: Dyscrasia, Esque, and Agent Blue. Starting out we worked with Crafty.js to develop Dyscrasia and Esque at which point we decided to move past its restrictions. Looking for a better performance we moved over to program in Go and decided to make our own game engine, Oak and a single player game for our new engine, Agent Blue.

Dyscrasia

Oakmound's first project was called Dyscrasia. Dyscrasia was modeled after games like agar.io, intended to be an in-browser multiplayer sandbox. It was imagined to be a kind of online version of megaman battle network. It is currently abandoned due to performance limitations of the engine used to build it.

The final version of Dyscrasia, 0.0.3a, is available here. Combat is effectively broken, and it runs very slowly, but you can platform around and mess with settings, and if anyone else comes online at the same time, you can see one another.

Dyscrasia was worked on from June of 2015 to December of 2015.

Esque

From 1/1/2016 to 2/1/2016 Oakmoundstudio created the game Esque which you can find here: https://oakmound.itch.io/esque

We had recently encountered issues with the limits of Crafty.js when working on Dyscrasia and decided to make something smaller. Inspired by the "game in a month" series we decided to sit down and make our own.

Esque had three main goals:

1.  have a simple control schema that maps in a natural sense
2.  have a small time span that has events you can learn from but still be surprised by
3.  have a well constrained scope.

//More to be added later about how and why we chose and met these goals.

//More to add about the development cycle and how constraining our time forced us to cut but also produce what we did.