Here you’ll find my thoughts on Iron Vice, the primary game I helped develop while at Black Tower Entertainment (2014-2017).
It is a browser-based, cooperative loot shooter that puts players in the boots of a futuristic mercenary tasked with eliminating hordes of hostile machines.
Here’s a trailer I made to get you caught up on the details:
I’ll start with a summary of my thoughts, then provide an in-depth breakdown of the game’s evolution and my experience as lead artist and designer at Black Tower Entertainment. You can also skip ahead to the following topics:
I. Starting Out
II. Art Direction and Contractors
III. The Iteration of Iron Vice & Becoming a Designer
IV. Design Anecdotes
VII. Narrative
VIII. Doug
IX. Release
X. Conclusion
IRON VICE SUMMARY
The basic summary of the game is thus:
Players must navigate 10 robot-infested cities in order to reach the final city and shut down the heart of the machine menace once and for all. Within each city is a set of randomly generated contracts. These contracts are linear strings of randomly configured arenas (called “blocks”), with the final block featuring a randomized mission objective. Complete enough of these contracts and you unlock the city core, which in turn unlocks the next city and a whole new set of landscapes, enemies, and rewards.
To keep the short version short, I’ll lay out the development timeline, highlights, and my personal takeaways as bullet points:
- Iron Vice technically had a development time of just under 4 years, the tech it was founded on being started in 2013. Prototyping of the game started at the end of the year.
- The original dev team consisted of Alex (client-side programmer), Doug (server-side programmer) and myself (art, design, sfx, music).
- We developed the game specifically for the browser, with Kongregate being the primary portal.
- Iron Vice was a 3D game built upon WebGL using a custom engine, with ThreeJS as the graphics library. Game always tied to a server, even in Single-player.
- We chose a Free To Play model with micro-transactions.
- Iron Vice went through 4 major iterations (all online cooperative): City 17 (shooter MMO), Horde (arena shooter), and Gauntlet V1 (linear campaign).
- The ultimate iteration of Iron Vice (Gauntlet V2) was settled upon 1.5 years prior to release.
- July 2015: I stepped up as lead design during Gauntlet V1, a role I continued through the ultimate iteration of Iron Vice (Gauntlet V2) and its release.
- January 2016: Iron Vice goes into beta through Kongregate beta program. Significant technical issues and a lack of international servers result in disaffected player base.
- February 2016: Andrew joined in 2016 to help with development of the level editor.
- April 2016: Doug dies due to surgical complications, resulting in many features being half-finished or cut entirely.
- September 2016: Declining financial situation necessitates the release of Iron Vice. Critical bugs and poor international server setup still mar the game.
- For a month after launch, we continue to deploy bug patches and minor content updates.
- November 2016: Game is declared financially unsustainable. Trump is elected president of the United States.
I’ve thought a lot about the various factors that contributed to the failure of Iron Vice. Here’s a list of them from my perspective, ordered most significant to least. For details on each of these, refer to the long-form analysis.
- Wrong genre of game for the market.
- Significant technical requirements.
- Server communication always required.
- Various technical bugs, some crashing.
- Game progression non-conducive to multiplayer.
- Dearth of content.
- Non-compelling purchasing options.
- Unappealing aesthetic.
If you’d like an in-depth summary of my experiences/thoughts working on Iron Vice, continue reading.
IRON VICE POSTMORTEM
This write-up will serve as a postmortem/biography of sorts… An introspective analysis on the development, release, and aftermath of Iron Vice. Since the chronology is muddled and dense, I’ve divided this write-up into discrete sections, each one covering a certain facet of development I consider meaningful. Each section is followed by a brief list of pertinent lessons learned.
I. STARTING OUT ON UNEVEN FOOTING
What would eventually become Iron Vice (henceforth referred to as IV) started back in 2013. Black Tower Entertainment (BTE), a game company founded by programmers Doug Morrison and Alex Dines, was working on a browser-based MMO styled after Wild Shadow’s Realm of the Mad God. I was brought on to serve as the artist, bringing the total employee count up to three.
The objective for the game was clear enough: A cooperative MMO that would take advantage of the ubiquity of browsers to reach a vast audience without requiring any plug-ins or additional pieces of software.
The challenges to that ideology began before I even officially started at the company.
Upon joining, I learned that the game had switched from 2D to 3D. The logic behind this was, IV could beat out 2D games graphically, and undercut other 3D titles by not requiring extraneous downloads (More on this later). Not only would this game be accessible to a fault, it would serve as a visual and technical benchmark for all browser games and as a statement for what was possible with HTML 5.
Obviously, such a decision had large ramifications. First off, IV was now being built off of WebGL, with ThreeJS as the graphics library. The former, in particular, would be a constant thorn in our side for the duration of development, due to its technological immaturity and compatibility issues.
Another, more personal, scruple was that I had virtually no experience with 3D art. A slight issue for someone who was now the lead artist on a 3D project.
While I had large reservations about the addition of a third axis, the team already had a bare-bones prototype of the 3D engine and level editor. As I didn’t want to overstep the boundaries of my newly attained position—and because I ultimately welcomed the challenge of learning a new art style—I swallowed my anxieties.
What’s more, I had aspirations of being a game designer but wanted to “know my place” as the artist, so that also went unspoken (until later, that is).
So, come July 2013, I officially joined BTE and we began work out of the local Starbucks.
Takeaways:
- Speak your mind and let your concerns be heard. Timidness has no place in game development.
- Matters like 2D vs. 3D need to be discussed with both artists and programmers.
- Before joining/hiring anyone, make sure you can communicate with them effectively.
- Make sure that everyone knows their roles and goals when starting.
- Don’t get swept up in the feelgoods of being wanted.
II. ART DIRECTION AND CONTRACTORS
The very first piece of concept art for the game, complete with pointless lore and fictional robot developer logo
My sole qualification for the job I now had was that I could draw shapes on a computer, but I quickly came to understand there’s more to the art direction of a game than cranking out a few half-baked concept art pieces.
Since the game was in 3D and I was unable to create any assets myself, there were two things that had to happen:
- Teach myself 3D art
- Hire some contract workers to do stuff in the meantime
Fortunately, both Doug and Alex had artist contacts from their time at Digipen. Between them, personal contacts, and the vast expanse that is Reddit, I had a decent starting place. Pouring over portfolios, writing up contracts, and negotiating prices is not what I thought I would be doing when I signed on but it was a mere bullet point in the much larger lesson in helping run a game company.
This process taught me how important it is to carefully choose the people you work with. Good contractors can communicate effectively, deliver assets promptly, and incorporate feedback well. Great contractors make you a better art director and artist.
Reading back over my early day correspondence with some of these artists for hire, it was painfully obvious that my knowledge in 3D was lacking. Misunderstandings of basic concepts like rig structure, a thin grasp of maya functionality, and unrealistic timelines all contributed to what, I can only imagine, were frustrating tasks and feedback.
After a string of poorly reasoned emails, one contractor in particular seemed to take a personal interest in my hardships and offered to help me learn the ins and outs of 3D animation. Up until that point, my entire knowledge of maya was perched on a shaky foundation comprised of several hours of poorly cut youtube videos and opaque autodesk tutorials.
I cannot overstate the value of this kind of instant access to knowledge.
With his help, my understanding of 3D art grew. I went from being “worthless” at it, to being simply “moderately bad,” which was something.
Starting with animation also helped, as it has a sort of backwards learning effect: Animation is typically the end state of 3D assets, so I could work backwards from rigging and skinning to modelling and texturing.
Very first rig, skin, and animation job
It was also during this time that I started to find my footing as an art director. All contractors were remote and so email was the primary form of communication. In the early days, wanting to show myself as competent, I would write truly vast novels explaining, in excruciating detail, my expectations and needs.
Average word count for feedback emails was 750, with every single discrepancy being found and commented upon. Ultimately, this cultivated a paranoid and creatively suffocating atmosphere for my contractors, mostly over details that would never even be noticed.
Over time I learned to a be a little more “free form” with my specifications. Feedback emails turned into 150 word bulleted lists, always with redline images attached for clarification. I started to see both better asset quality and delivery time as a result. Now, any issues that didn’t warrant lengthy feedback emails I could simply fix myself.
The quality of my concepts also increased, which can be attributed to both the feedback from my contractors, and a clearer idea of the art style.
Later concept of the “Vector” enemy
Takeaways:
- Be honest with yourself about your abilities and ask for help when you need it.
- Take advantage of subject matter experts in your field and celebrate that expertise where you find it.
III. THE ITERATION OF IRON VICE & BECOMING A DESIGNER
IV started out as a riff on the browser MMO shooter game, Realm of the Mad God, albeit with a few crucial differences. While RotMG had extremely simplistic 8-bit pixel art, IV featured “cutting edge” HTML 5 powered 3D graphics. While RotMG’s core gameplay was a traditional bullet hell that derived fun from simplistic AI with interesting shot patterns, IV was conceived as a top-down “tactical” game, featuring intelligent enemies with whom the players would engage in firefights. During this initial iteration, IV was known as “City 17“ after Doug’s favorite game, Half-Life 2.
A multitude of practically insurmountable design conundrums arose from City 17‘s scope and general concept, resulting in an overall game shift about 4 months into development.
Wanting to maintain the idea of “tactical” street battles and the sizable cover system that had been built, Doug suggested we try for a top-down version of his favorite multiplayer game: Mass Effect 3. This lead us to prototype out a cooperative arena shooter, wherein the player would be assaulted by waves of enemies within a confined map. This version of IV was called “Horde” and was both powerfully un-fun and lacked long-term engagement potential.
Once it became readily apparent that Horde wasn’t going to work with our small team and rapidly dwindling resources, team morale began to tank and our situation started to feel directionless.
It was in this time that I communicated my desire to be lead designer.
Taking influence from SAS4: Zombie Assault (what we saw as our main competitor on Kongregate), I proposed a more linear, progression–based game design. Small teams of 4 players would navigate through randomly generated levels composed of small arena-esque rooms, with intermittent save points and harsh penalties for dying. This iteration became known as “Gauntlet V1,” and formed the foundation for IV.
It was also utterly terrible.
I do believe IV‘s final form had structural merit and was suitably compelling and ultimately pretty good for how much money/time we had.
Gauntlet V1, on the other hand, was a nightmare of composition and pacing. I wanted a few things out of this iteration, foremost being a real sense of progression by which players could very visibly see the product of their labor. Gauntlet V1 failed in two ways:
- Progression was evident, but not meaningful. Players would dump significant time into besting the gauntlet, only to unlock a checkpoint (i.e. a button with an incremented number). No unique rewards. No compelling UI. Streaks simply yielded money multipliers.
- Inconsistent rewards. While unlocking the first 5 checkpoints happened with regularity, the latter 25 became more and more grueling. Play sessions of 10 minutes or more would yield nothing but some in-game cash, as checkpoints (the real sign of progress) kept getting farther and farther apart (my idea of difficulty amplification).
From these main failures, I learned one of my most important design lessons: Always provide consistent, reliable, meaningful “victories” and rewards for the player. Scale of the victory and reward can vary greatly, but it needs to coincide with the audience and the overall engagement level your game requires.
And so the final iteration of IV, Guantlet V2, featured an all new progression system built around Contracts: short, 5-8 minute missions of variable difficulty that always ended in a new chest, progress to the final mission, and resources.
Final version of Contract System
Fun fact: Each city has a google maps background of a real city, just with bunches of custom visual filters applied to it. I fetched a library of 5000 city longitude/latitude coordinates and we dynamically cycle those city map backgrounds.
If you’d like to see some examples of the design docs I wrote, you can view them through the links below. Keep in mind, they are written for a team of 2-3 people, not the internet as a whole, so my language may be a bit… coarse in spots. The latter two docs present some “interesting” mechanics, in the same way the aftermath of a horrific car crash is “interesting.” The looting phase doc, in particular, has some pretty heinous concepts… Temp pot? Really, Mika?
GameProgression_Redesign(GauntletV2)
Takeaways:
- Prototype, prototype, prototype. Be able to recognize when something is not working out and shift directions quickly.
- Communication and compromise is key. Courage to speak up will save you a lot of time.
- Audience engagement depends on consistent, compelling victories and rewards.
- While ambition and innovation are crucial, try to balance both with a practical sense of your time/money/experience constraints.
- Feel out your audience’s tolerance for #3. Case in point: browser players are typically more fickle than PC and console players, requiring more immediate and regular incentives.
IV: OTHER DESIGN ANECDOTES
Coming up with the campaign structure, weapon systems, and story layout were all fun and games, but alas, video games are more than exciting broad stroke design concepts. Many more hours were spent tweaking numbers, formulating scaling equations, balancing boosts, buffs, and cooldowns, and generally getting all the mechanics and systems to play well with each other.
The game data Text Editor. My loving mistress.
This is not even mentioning the numerous poorly thought out concepts of mine that I foisted upon the team.
One of my crowning failures is what were known as “Chest Bullets.”
Due to various reasons, we wanted to simultaneously limit the amount of loot players were getting, increase the number of in-game pickups, and maintain a high volume of post-mission rewards. Weapons and armor were obtained via chests which could, in turn, be either purchased from the store or obtained from contracts.
The “Vault,” where players open their chests.
Enter “Chest Bullets,” random (though somewhat common) in-game loot drops that were necessary to open all chests. You would place the chest you bought/found into a specialized opening area called the “Vault”, then shoot it with these chest bullets in order reap its succulent contents. Chests required different types/amounts of bullets, depending on the rarity.
Reading that back, the issues seem so obvious. Our alpha players voiced long and loud (and with very colorful language) their frustrations with the system. Consistent, measured rewards now had to be validated by a randomized drop, completely decimating any sense of satisfaction with getting a chest, and padding out the loot loop with a random variable.
We pulled a hard course correction and I came up with a more standardized, rote system of loot distribution, but the time we spent developing chest bullets was largely wasted (and not insignificant). There are still remnants of this system, notably the Vault itself, which now simply functions as a pointless step between receiving your chest and getting its contents.
For a time, I considered trying to justify the vault’s existence, perhaps with timer based chest opening or a reduced version of chest bullets for only special chests but, in the end, we decided that we didn’t want to impede players’ loot acquisition and so just left it alone.
Takeaways:
- Test your damn game. Seriously… Christ.
- Just because a concept works on a purely mathematical and logical level, doesn’t mean it’ll work in practice.
V. THE COST OF FREE TO PLAY
On the topic of chest timers and bullets, it bears mentioning the problems that arose from IV being a F2P game.
Being a browser game required the need for a F2P system, as did the BTE vision of “ultimate ease-of-access.” However, none of us really played F2P games, or were completely familiar with the mechanics behind what made them work.
Our logic was simple: Make a fun game, charge for some cosmetics/premium gear, and the rest will sort itself out. I wasn’t really interested in ways to separate players from their dollars, I just wanted to make the best game I could.
Unfortunately real life doesn’t really work like that, and people won’t pay for something if they don’t feel they have to. For too long the game was overly generous with handouts and unlocks. The positive reinforcement we got from players who liked the lax stance on micro-transactions was pleasing, but didn’t help with filling the BTE coffers.
We took a twin-pronged approach to making our money. On one side, simple product purchasing. Spend 2 bucks, get a rare chest. Spend 4 bucks, get a silly hat. Spend 5 bucks, unlock the Railgun schematic. As you might be able to imagine, weapon schematics and accessories sold more often than chests (which offer weapons and gear that will eventually be outlevelled). The problem is, those products are very finite, resulting in a very non-scalable purchasing model. On the other side, we had crafting. 
With Crafting, you could customize/upgrade your weapons with in-game resources. The catch was that you could accelerate the process with real money. I was hoping that this would provide a renewable expenditure that players could consistently engage with, since they were always getting new guns and gear…
The problem, however, is that crafting never really entered the main gameplay loop. It sat isolated in a sub-menu, 3 screens deep and was never explained, and was thus a red-headed step child mechanic that I don’t think a large percentage of players even knew existed, let alone utilized.
Ultimately, working around F2P systems were some of my least favorite parts of IV. All designs and mechanics had to be checked against our lines of income, making any additions an incredibly restrictive process. I regret to say that fun was sacrificed to the great beast of profit more than once.
Takeaways:
- Being generous typically doesn’t pay.
- If you’re going to make a F2P game, make sure the financial system is thoroughly intertwined with the main gameplay loop. The player shouldn’t be able to go more than 5-10 mintues without being confronted with a payment opportunity.
- Designing around F2P adds a whole new layer of complexity.
VI. TECHNICAL CONUNDRUMS
Over the course of development, IV was subject to a host of technical issues, ranging from hilarious animation bugs to crippling export problems.
The main source of agony though, can be traced back to WebGL and some of the tack on effects it had to game design.
Foremost among these was that the game was always online, even in single player. If I had to point to one of the largest contributing technical factors of IV’s failure, it would probably be this one. What this meant was that, god forbid that players had a sub-par internet connection, they couldn’t even play by themselves without running into lag and rubber-banding. Many browser players do not have great internet connections and, as such, IV was practically unplayable for them. Granted, the game was intended to be played in multiplayer but, when starting out, many people try out single player to get their bearings. Running into connection issues on initial play, by yourself was, I believe, a truly damning outcome.
BTE could only afford to spin up 2 servers for IV: One in Houston, Texas. The other in Amsterdam. If you had a substandard internet connection, or were a good distance away from either of those places, IV would be very unpleasant to play, even alone.
The game was also simply technically demanding. On my i7 GTX 660, I would ping pong between 40-60 frames. What’s more, advertisements on Kongregate’s game page would tank the fps even further, mandating the use of an adblocker. Andrew, a coworker who worked on a mac book pro, never saw passable frame rates, with his machine consistently orbiting 20-30 fps.
IV was also the victim of a lengthy startup load. We tried to curtail this by letting players access a reduced menu layout after an initial, shorter load, but players could be faced with wait times in excess of 3-5 minutes depending on their connection. A damaging issue, particularly in the fickle browser market.
And then there were the various bugs, many of which were in the launch version due to a rushed deployment. Black screen on load. Black screen on return from contract. Black screen on completion of tutorial. Gradual fps decline over several consecutive games. Many of these were patched out post launch, but the damage they did to the initial player base was both permanent and significant.
In summary, in order to have a good experience with IV, you had to be on a powerful desktop/laptop, be in the continental US or Europe, and have a good internet connection…
So much for “ultimate accessibility.”
Takeaways:
- When thinking about technical compatibility, think of the lowest specs that can possibly run your game (well). Then half that. That’s your target.
- Don’t base 3.5 years worth of work on unstable tech.
- Is 3D necessary? Like, does your audience even care? If it wasn’t 3D, what would be the worst thing that would happen? (Applicable with many other substitutes as well)
VII. NARRATIVE
IV had what, I guess, can be considered a story.
It was always the assumption that we’d take the laid back approach, inserting bits of lore here and there to tease players. Intrepid fans would conspire on Wikis about the true meaning of the hostile machines and the roles of the player character.
After extensive personal play sessions however, and some supporting feedback from the beta community, I came to the conclusion that such an approach was not working. The overarching objective felt pointless and player motivation was weak. I took the few dissenting players as an excuse to pen a narrative line for the game.
Ultimately, the implementation was too light, with no consistent link between players and on-goings of the story they were supposedly a part of. Players would complete a city, get talked at by their commanding officer, then BAM! Off to the next city to rinse and repeat.
I think the story had potential, especially if we had added some supporting gameplay mechanics. However, for the amount of time we had to implement it (about a month, right before release), it turned out as well as can be expected.
You can read a synopsis along with the post-city debriefings by clicking the link below.
Takeaways:
- For the story to not feel tacked on, players need to see the results they have on the characters/world
- Lore != Story
VIII. DOUG
Doug was half of the founding team of Black Tower Entertainment. While technically I am a founder due to the company reforming into an S-Corp a few months after I joined, it was Doug and Alex who came up with the idea of BTE back at Digipen.
He was an extremely talented programmer with an ironclad work ethic. It takes a special man to rally a bunch of sleepy 20-somethings around a prompt, 9AM start to the work day. Doug Morrison was that man.
Being in charge of the server side of IV also meant that he had a wide swath of responsibilities. Since IV was always online, everything always went through him. AI, in particular, was his specialty. He loved tactical shooters and the strategy involved when playing them. His brainchild, what he called “street battles,” was his idea of bringing that same tactical action to a top-down game like IV.
He was also a very opinionated man, with said opinions often clashing with my own. We would have lengthy, multi-hour discussions about art and design, and not always did they have meaningful resolutions. Sizable design shifts would always be accompanied by a long explanation and reasoning session, with me writing verbose documents attempting to convince Doug. Such was the conversation about the removal of his street battle system.
Ours was an oft contentious relationship, but was tempered with what, I hope, was a mutual respect and friendship. He and I had our own projects we worked on together too. New enemies were always a joint effort between the two of us, as was the “Mission Mod” system, a concept that we came up with to inject contracts with more surprise and chaos.
When I stepped up as designer, he also served as an invaluable foil to my various plots and schemes. I always needed to thoroughly explain my latest machination, lest I be met with his trademark thin-lipped scowl. I would plan for hours after work, scribbling diagrams and notes on the bus, coming up with some irrefutable piece of logic that not even he could deny. I would heartily complain about having to substantiate every little decision that I made, but the fact of the matter was that Doug made me a better designer, as well as a better team player.
He died April 29th 2016. Post-surgical complications.
Needless to say, his passing had massive ramifications for the team and IV. Many features that were in development or planned were unceremoniously dropped. Mission Mods, the Siege Lord boss enemy, the Vector assassin enemy, mission types, weapon functionality, visual effects… The list goes on and on.
There too, were the emotional effects his death had on team. Morale tanked and the development of IV took on a sour taste. Alex, now our sole game programmer, inherited Doug’s server responsibilities. All focus went to simply releasing the game.
Longer hours, higher stress, fewer game features. Less goofing off.
However, amid all of the sorrow and pain, one thing was for certain. Iron Vice was getting made, come hell or high water.
5 months later, Black Tower Entertainment, now 3 instead of 4, released Iron Vice 1.0 to Kongregate at large.
IX. RELEASE
IV released to site-wide Kongregate on September 22, 2016. Prior to this, it had been in Kongregate’s Beta program since February.
The game was still deeply flawed upon release. The aforementioned bugs, performance inconsistencies and connection issues were still there. In addition, the game was lacking some crucial gameplay mechanics (equipment recycling, exclusive offers, post-city debriefs) necessary for player understanding and stickiness.
IV’s ratings were largely split, particularly for this first release. Ratings were either 1/5 or 5/5, depending on if the game worked for the player or not. Our player conversion rate was 6%, meaning that 6% of players who clicked the game made it through the tutorial, the first contracts, then returned the next day for another play session. We saw massive falloffs at the initial load, the first seconds of the tutorial, and the first test contract.
All time ratings (1-5). Average 4.00.
Launch day was utter madness. I was constantly in IV chat, addressing player concerns, playing customer support, and weathering a hail of verbal abuse.
One interesting anecdote: One incensed player left a combative forum post, calling us all manner of nasty words. I sent him a private message asking how I could assist him, and offered the reasoning behind some of the decisions he had lambasted.
I received back a message that was of completely different tone. He was understanding, firm in his convictions, but sympathetic to my reasoning. He wished me well and said the game had a lot of potential. He then deleted his forum post.
It was enlightening to see how his fury was directed at this unfeeling, digital mass of code and art, with his temperament completely changing when confronted with an actual human being. This experience gave me new reverence for community managers.
In summary, the release went as well as can be expected. The game was unfinished, buggy, and non-performant. We hemorrhaged players to to bugs that would later be fixed, but the damage was done. Being a multiplayer-focused game, every player matters, whether they pay or not, and the loss of those release day players was a death knell for IV.
Despite all the issues that plagued the earlier release versions, we managed to pull in a small knot of extremely dedicated fans. These people were our light in the darkness, urging us to keep our heads up and keep on improving the game. We had 6 players complete the game fully, an endeavor that must have taken in excess of 70 hours. Several players also purchased $50 premium currency bundles.
Watching these players go through IV, experience its systems, form tactics and play styles, discuss weapon preferences, driver upgrades, player levels and all of the game’s various systems and mechanics was truly a saving grace.
I got to experience a product that I had helped create bringing joy to total strangers. At risk of sounding sappy, it was an inspirational experience, a creation-driven euphoria that I don’t think I can ever give up.
Personal Takeaways:
- Take a serious, numbers driven analysis of your market. How many games of your genre are there? What is their annual earnings? Player base? Average playtime per player?
- A dearth of games of your genre on a platform does not mean that yours will succeed on said platform. On the contrary, it probably means the opposite. The deployment plans of IV were substantiated by the lack of top down, realtime action games on Kong. It was thought that, through lack of competition, IV would secure the market niche (SAS 4’s audience). Couldn’t have been more wrong. It simply meant that no one on Kong wants to play top down realtime action games.
- Commitment services are usually a good idea. With F2P games, this means (typically) subscription services. Things to make the player continue investing, live up to an ideal that you’ve set, or that they’ve set upon themselves.
- ARPU vs. ARPPU. Both are important, but ARPU is probably more so. IV had a relatively high ARPPU (~$4) but abysmal ARPU. What this means is that, when we captured users (got them to pay), they spent a lot of money. It just didn’t happen very often…
X. CONCLUSION
Three and a half years I gave to Black Tower Entertainment, the majority of that spent on Iron Vice. Stress, Happiness, Frustration, Anger, Sorrow and Elation were all in great supply, some more than others.
Looking back on it all, I’m proud that we were able to release the game. I’m proud of my team members, Alex and Andrew, and I’m thankful that I got to be a part of it. I think Doug would have been proud with what Iron Vice eventually became, even if he didn’t really like the name…
I learned so goddamn much. Not just about art and design, but about communication, team management, and morale. There’s so much more that goes into a game than photoshop and C++, and I got to witness it all first hand. There are many mechanics and systems that I wish with all my heart had made it in, but such is the nature of game development.
About midway through development of IV, I didn’t really consider myself a game developer. That arbitrary title was reserved for professionals… People who knew what they were doing and had been forged in the fires of long hours and little sleep.
At the end of it all, I’ll make no bones about it:
I’m a goddamn game developer. I don’t think I can be anything else.
If you’ve made it this far, I whole-heartedly commend you. You just read 5000 words of run on from an indie game developer. If you’d like to see some of the art that went into Iron Vice, go over to the Art page. You can find the music I made for the game over on the Music page.
Thanks for reading, and I’ll see you all for my next game!