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.