Game Architecture for Diverse Clients and Budgets

No matter the client’s budget, we want to work with them– auto-scaling, efficient, and re-usable tech makes this possible.

Arbor Interactive Funding / Business Model

Like many small / medium-size studios, Arbor Interactive funds itself partially through contract work with diverse external clients. Are you a youtube brand celebrating childrens meal prep? Here you go–

For the super-small budget, I’m fairly proud of this one. It has a unique timing and combo mechanic that makes it somewhat unique among match-3’s.

Are you a federal agency looking for a way to advertise a dangerous new disease to the public? No problem–

This one became a unique little mix of Plague Inc and Civ. The original version had you piloting robot drones into caves, before we realized it would send an eco-unfriendly message.

Are you a research group seeking to shock conference goers by showcasing your discoveries via a video game? Are you a health insurance company looking to provide a digital take-home game? Regardless of who you are, or how large you are, Arbor Interactive wants to make your game, but having diverse clientele with diverse budgets isn’t easy. You can win more contracts too if you pursue the following objectives–

Step 1: Keep Access To Your Technology

…so you may maintain, expand, and re-use it! While not all of the above projects allowed us the right to re-use and expand the tech we created for non-related projects, most did. These technologies would be reworked to make them as flexible and re-usable as possible, allowing development on fancier games to continue despite a staff roster of precisely 0.5 people (I’m our only part-time engineer) and some freelance musicians and artists.

Step 2: Make that technology Reusable.

Here’s a fancier, more-traditional, original-IP game–

It’s an RPG / RTS / Tower Defense game with high player-character mobility (kinda like a Moba, maybe?). Wait, where are the towers in this gif??

Hey! It’s a new RPG / RTS / Tower Defense engine. I say “Engine” and not game, because it is almost trivial to create a new title with different levels, enemies, story, etc.

This one has a beach theme, and all-new characters, towers, and narrative elements.

If Arbor Interacive’s accessibility goal is to be met– if we are able to keep costs low and accomodate clients and projects of diverse scopes and budgets, we must make heavy use of the re-usability of our tech. The spreadsheet system discussed above gives us the power to quickly create games that feel unique, even if their underlying mechanics are similar.

Step 3: Make Your Technology “Auto-Scaling”

Let’s say we’re working on a low-budget game, and we can only afford to represent our game characters with a single sprite–

That’s ok! We can still give that single sprite a satisfying, charming, and juicy walking animation through a bit of rotation and vertical displacement (use the absolute value of the sin wave!). This method of movement will work acceptably for movement rightward, leftware (just mirror the sprite), towards the camera, and away from camera. It evokes a paper-mario approach which some players may find nostalgic or charmingly minimalist.

In the spreadsheet database that powers our engine, we see this–

Let’s say the budget is a little bit higher though, and we can now afford one idle sprite, and one idle-back-to-camera sprite, like so–

The character is just that much more lively! This is how it looks to configure an “away” sprite for a given unit in the spreadsheet database–

)

Something important to note, is that this just works™️. The single component that handles the rendering of every unit in the game (“HasUnitVisualization”) knows to check for existing and non-existing sprites when the unit spawns, and will use the appropriate rendering and animation techniques to “make it work” with whatever assets that unit has.

Let’s say we have time and money enough to support 5+ sprites per character–

Currently, this extra time and funding would go into attack, damage, pre-ko, ko, blinking, victory, and jogging poses. With each new pose, some “moment” in this unit’s gameplay becomes juicier and more satisfying.

For instance, if a particular unit’s row in the spreadsheet database has been given jogging sprites, we see this…

Pretty effective for just 2 frames– the rotation, displacement, and cartoony art style is a big part of why.

Instead of just this…

Still effective, if a bit cheap-looking.

The change between these two walk “styles” is handled automatically by the game engine– artists simply upload their new sprites to the spreadsheet database, and that unit gets the more luxurious version.

Another example– If a unit gets KO’d and it has a Pre-KO and KO image supplied, here’s what happens in-game–

Mario and Sonic always had the cutest, most dramatic ways to “die” non-violently, so here’s a mix of the two.

If a unit is missing these poses, then here’s what happens instead–

Here, Villy has a damage-sprite, but no pre-ko or ko sprites, so rather than do the surprise-fall sequence above, she goes flying like a piece of cardboard to the wind.

And this scalability extends to many other elements of the game engine– from continue screens to intro cutscenes to audio to loading scenes to items– the game engine is designed to “deal with” a lack of assets, and make the best of the situation through clever placeholders, default animations, etc. The philosphy aims to make projects shine in the presence of reasonable budgets, but cope well in the event of strained resources. It’s more “Amazon” than “Apple”– more “accessible” than “amazing”. It’s easy to see some players and devs not being a fan (but gosh do I love it).

Subscribe to Future Devblogs!

Subscribe here to be notified when we publish future devblogs, tutorials, etc.