engient Engient is Engineered Entertainment


Rigonauts Android Incoming to Snapdragon Devices

I am excited to announce that Rigonauts for Android has been pre-released to Verizon customers (find it here) and will have a general release to all Snapdragon powered hardware on October 23. We hope you enjoy our blend of building, battle, and mind twisting puzzles.

Of course some people have wondered why we are only supporting Snapdragon based hardware at this time. The reason is that initially Rigonauts was only targeted at PC. We are a small team (only two permanent members) and Rigonauts is our first game. Therefore, we had our hands full getting our first product out the door and were not even considering multi-platform. However, Qualcomm had seen the game and liked it enough that they offered to help us with the porting process. This was an exciting opportunity for us so we jumped at the chance. We are grateful to the team at Qualcomm for supporting our unique little indie game and helping to make Rigonauts for Android a reality.

Full Steam Ahead!

I hope you give our game a try and let us know what you think. If you can’t get it on Android then you can find it here on Steam for PC. And please keep an eye out for us on here, Twitter, Google+, or Facebook. We don’t yet consider Rigonauts a closed project and there is a bit more on the way.

Until next time,



Post Launch Thoughts I – Score

Dear Friends,

One of the comments we get a lot is about the scoring system. For example, one user wrote:

You are "rewarded" with additional pieces and weapons, yet penalized if you dare use them all.

This is a fair critique and one we agonized over. Therefore, I think it might be nice to give some explanation why it ended up that way.

The score is here, but why?

When we started coming up with the scoring system we really wanted something that measured how much butt the player was kicking. We had two very simple design goals:

  1. Earning a better score should be fun. Obvious I know.
  2. The player should be able to iterate towards a better score.

The first thing we considered was Time. Unfortunately, small changes in the ship would result in huge swings in time. Therefore, violating rule #2.

The next idea was to measure how much Health the player’s ship had when the battle ended. Initially, we thought this one worked very well. After all, if you killed the enemy faster you would take less damage. If you placed your armour correctly you would take less damage. The Health of the ship at the end of the fight says a lot about how well you did. We were happy.

Then we started testing.

The first hurdle we encountered is that a lof of people didn’t understand how to take less damage. See in our game there was no way to completely avoid getting hit. The enemy was always going to hit you with a salvo or two before you were going to start taking down their guns. Therefore, the ways to avoid taking damage was to kill the enemy faster or to place your armour so that their attacks would lose strength. But that required an extra step of thinking that proved hard for a surprising number of people. When they thought about reducing damage, they thought about avoiding hits which just isn’t possible for how the game plays. This was disappointing, but may have been workable if it wasn’t for the next problem: Piece Overlap.

When you make a game that is a bit experimental there is always the chance you will make some mistakes. Building the ship around overlapping pieces is one of those mistakes. It might not seem like a big deal, but it had some big effects on battle and completely upended the scoring system. How could something so innocuous lead to so much trouble?

For starters it meant we had to give most weapons a blast radius. If you could just make a more armoured ship by putting wood beams on top of each other the game would be very dull. Therefore, the blast radius of most weapons drives the player to push pieces apart. That caused us a few headaches, especially in feedback to the player, but mostly it worked as intended: put two pieces too close together and they both get damaged, move them apart and only one gets hit.

Of course one side effect is that if your ship gets hit near the joint, then two or more pieces will be damaged. Now, when it comes to destroying the structure of a ship this isn’t a problem. If it takes four hits to sever the link between the Caplin and the gun, then it doesn’t matter if those four hits take out two pieces or one.

Until you start scoring the player on Health.

Suddenly, we have an Aliasing problem: if an enemy bullet lands in the center of a segment it will do half as much damage to your score than it would if it landed at the joint. Now this didn’t violate goal #2, that player could iterate towards a better score. Unfortunately, it caused havoc with goal #1, fussing with the minutia of placement to get enemy bullets to land at juuuuust the right spot was irritating.


Hitting the joint does double damage, which would hurt your score twice as much.

For players who didn’t see the joint problem, their score would fluctuate a bit unpleasantly but they would otherwise play the game as intended. However, for players that did see the issue they would be sucked into a game of making these miniscule irritating changes to maximize their piece placement. And with each tiny tweak a bit more fun factor was sucked away.

And that left us with Resource Minimization.

Oh that was a hard choice day in the office. We wanted players to have big crazy ships, but we also wanted scoring for a number of reasons. Thing is Resource Minimization just worked. Everyone understood the rules and the goals. The player could iterate towards a better score. And in the end it is fun. Of course, being efficient isn’t the same kind of fun as laying into the other guy with all you have, so it wasn't a perfect choice. But given the difficult constraints we had, we think we made the call that would provide the most fun to the player.

So now that you know the reason, do you look at the game a little differently? Or if you haven't played it yet, perhaps you might like the challenge of finding the most efficient solution to a given level. Or do you think we missed something and should have made a different call? Please, let us know on anti-social medial: Toot on Tooter, post on Gooplus, or even face the Book.

Until next time,


It is a little controversial, but a lot of fun if you like a challenge.


realDevelopment: The Cold Hard Truth

Ah, yes Dear Friends its time for another communique from the heart of Engient Command HQ. Today my mind is on the weather. The San Francisco Bay Area has a mild climate but as winter turns to spring it still holds a special meaning for us here at Engient: we no longer will have to freeze.

Now many people come from places that get much colder than here, but there is a twist: we work in an unheated warehouse. Yes, a 47 degree high might not sound all that bad to our fans in the Midwest or East Coast. But when you are sitting at the computer, for 8+ hours, (and it hasn’t warmed up to 47 degrees inside) the cold starts to get to you. What is the face of game development then? It is this:
It is cold.
That Dear Friends, is me last February doing my best to keep warm. Layers of thermal underwear, sweaters, and extra shirts were used to try and hold back winter’s bitter bite. But still worked slowed as my frozen fingers refused to move at full speed.

Now things are looking up. The weather is turning and we are pushing forward on Rigonauts: Broadside with full speed. These are exciting times indeed!

However, if anybody asks you “Who do think is the most INDIE of developers?” point them our way. Sure goofy art and crazy ideas are pretty indie, but when the only thing to keep you warm is the waste heat from your graphics card AND THE FIRE OF PASSION BURNING IN YOUR BELLY, well then you know your indie on a whole new level.

As allways you may become one of our followers by finding our sociopathic media at twitter.com/engient or facebook.com/Engient.

Until Next Time,