Disbelief is a game development studio focusing on contracting and consulting services. We’ve worked with both AAA and independent studios to help their projects ship. Notable projects we’ve worked on include Gears Tactics, Gears 5, Borderlands 3, and Torn.
At Disbelief we value work-life balance, and want to create an alternative to the crunch-culture prevalent in game development. We also believe strongly in investing in our talent and our team. Disbelief is a place to puzzle out the solutions to cutting-edge problems in graphics and engine programming, but also a place where people can grow their careers and skill sets as valued members of a stable and close knit team.
Currently, we’re looking for a programmer. This opportunity is for a full-time position in Cambridge, MA. Programmers at Disbelief are called on to develop and debug in a variety of areas from game play to core engine programming. You are expected to learn new systems and projects as you grow as a developer. You are also expected to use your knowledge to solve problems both you and others in your team have.
Key Responsibilities:
Clearly communicate your work to others
Debug code
Estimate task work
Assess impact of issues on schedule
Write performant code and specialized systems
Document your code
Study version histories to guide current problems
Implement new system features
Skills and Requirements:
BA/BS in Computer Science, or equivalent experience
Excellent communication skills, both verbal and written
1+ years of experience in writing software in C++
1+ years in game development, or 3+ in a related industry
Experience with version control with P4, git, or equivalent
Understanding of multi-threaded systems
Location: Cambridge, MA
Remote: Currently all of Disbelief is working remotely during the pandemic. Post-pandemic our plans are to return to a hybrid model where we still live near the office but often work from home. Some of our projects require access to physical infrastructure.
Visa Sponsorship: No
Technologies: Most of our work is C++ of varying standards with a sprinkling of other languages as needed for tooling. We do a lot of graphics programming work, using shader languages and platform graphics APIs. Since we often are debugging the lower levels of systems, being able to read x64 or ARM assembly is useful. Primarily we work with Unreal Engine, but we also work with Unity and custom game engines. Our work uses rendering, physics, audio, VR, AR, and other APIs frequently. Our primary platforms are PC, Xbox consoles, Playstation consoles, Switch, and VR/AR devices.
Whether you’re just starting out, looking for something new, or just seeing what’s out there, the Gamasutra Job Board is the place where game developers move ahead in their careers.
Gamasutra’s Job Board is the most diverse, most active, and most established board of its kind in the video game industry, serving companies of all sizes, from indie to triple-A.
Just a quick reminder today that the early registration period for August’s all-digital GDC Summer event ends Wednesday, June 17th at 11:59 PM Pacific, so conference organizers encourage anyone interested in attending to register now at a discounted rate!
This is one of the best opportunities to save money on your pass to GDC Summer, which takes place August 4th through 6th in a new, completely online format that will be accessible to our global audience of game developers.
This new, all-digital GDC event will offer a smorgasbord of the same high-quality game development lectures, panels, and tutorials that GDC attendees are accustomed to, and the GDC Summer schedule is already filling up with great content.
In a GDC Summer Programming track talk on “Physical Animation in ‘Star Wars Jedi: Fallen Order‘“, for example, Respawn’s Bartlomiej Waszak will show you how Fallen Order‘s physical animation system improves motion fluidity, smooths out transitions and provides a nuanced character performance.
Waszak will provide practical examples of hero traversal mechanics, stormtrooper death performances, and the companion droid BD-1. He’ll also share several solutions for blending physics with target animations, discuss the control parameters and tradeoffs associated with each technique, and show implementations achieved using Unreal Engine 4 and PhysX.
By broadening the pool and diversifying leaders for the future, Carmona will reveal how King has tried to create a culture that is inclusive to everyone and integrates D&I into core people processes, removing barriers preventing the hiring of diverse candidates and the development of women into leading, influential roles.
Roget is an award-winning composer, and those who attend his virtual talk can expect to walk away with tips and advice on effectively using leitmotivs in your own work. You’ll also get a clear breakdown of the differences between leitmotivic and thematic melody, and learn the contextual advantages of diverse leitmotivs and signature sounds over thematic orchestral melodies when scoring for cinematic games.
Part of the GDC Summer Design track, this talk promises to teach you how this method is used to create a new set of stats for blockers that can used as a common design language across all of King’s studios. The new set of stats helps designers, artists, producers, developers, and even players to better understand a blocker’s behavior, and Chen will show you how it also helps King design better blockers.
This talk promises practical, actionable advice on designing games in the hyper-popular match-3 genre, and you can reserve your seat to attend it and many more at a discounted rate when you register for GDC Summer by Wednesday, June 17th!
For more details on GDC Summer, scheduled to take place virtually August 4th through the 6th, visit the show’s official website, or subscribe to regular updates via Facebook, Twitter, or RSS.
Gamasutra and GDC are sibling organizations under parent company Informa Tech
As the next console generation revs up, Microsoft and Sony have both made bets on the fact that consumers are only interested in purchasing one of the company’s consoles for their household.
While this may especially prove true at launch, new data from Ampere Analysis suggests this isn’t the case in the long term. In a report just published, the Ampere states that 32.2 percent of PlayStation 4 owners also won an Xbox One, while 18.5 percent of PS4 owners own an Xbox One X.
The cross-ownership flows even stronger in the reverse direction. 47.5 percent of Xbox One households also own a PS4, and 27.4 percent of Xbox One Households have a PlayStation 4 Pro. That means almost half of Xbox One households are effectively two-console households.
Ampere’s data doesn’t make predictions about how this might the next console generation’s sales, and it obviously isn’t able to measure the incoming economic impact of the COVID-19 pandemic. But for this generation of game console ownership to close out with so much overlap does increase a growing agnosticism toward a particular platform of choice, which may be a boon to game developers.
GTA Online will be released as a standalone title on the PlayStation 5. Although GTA V will also be making the next-gen leap (for the second time) in its entirety, Rockstar explained the lucrative online mode will be getting a standalone release on next-gen machines in the second half of 2021.
Notably, that souped up version of GTA Online will be made available for free to PlayStation 5 users during the first three months, suggesting the studio intends to charge for it further down the line. It will also feature original content exclusive to next-gen devices.
Rockstar didn’t specifically mention an Xbox Series X version of GTA V, but did state that the game will be “coming to a new generation of consoles, including PlayStation 5,” so it seems likely the evergreen title will be heading to Microsoft’s dreamy obelisk in due course.
Despite launching almost seven years ago, GTA Online continues to be a big earner for Rockstar and parent company Take-Two Interactive.
Last year, for instance, recurrent consumer spending increased by 23 percent in GTA Online following the release of the Diamond Casino & Resort update in July 2019, with Take-Two CEO Strauss Zelnick praising the add-on for “delivering record player engagement across daily, weekly, and monthly active users in July, and then again in August.”
The survival horror series was launched back in 1996, and has since grown into a flagship property for Japanese developer-publisher Capcom.
The company has spent the past few years reimagining classic entries in the series with the release of titles like Resident Evil 2 Remake, and yesterday announced the latest entry in the core series, Resident Evil Village, during the PlayStation 5 showcase (where we also got our first look at the next-gen console).
The following blog post, unless otherwise noted, was written by a member of Gamasutras community. The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
My career as an indie game developer got off to a late start.
I spent most of my professional life as a web developer, initially as a general purpose “webmaster” in the late 90’s, before specializing in UI during the dot-com era, then switching to server and database development. It wasn’t until I was in my mid-thirties that I decided to try my hand at game development.
My first game: PlanetDefender
I had a couple of ideas for games, but with no game-specific development experience I decided to start small with a fairly basic “tower-defense” game called PlanetDefender. I built it with Adobe Flash, simultaneously learning ActionScript as well as general principles of game design. It took maybe a month or two in my spare time. I was very happy with how it turned out, despite not being my “dream game.”
Most aspiring game developers have a dream game: the game in their head that’s just itching to get out and is invariably too ambitious for their skills.
Mine was in a venerable genre that doesn’t actually have a name: 2D space exploration action-adventure where your ship essentially is your character.
Screen from an emulated version of the 1971 Star Trek
This genre can trace its roots back to the very popular and very unofficial Star Trek games of the 1970s (and possibly even earlier with influences from Spacewar!, arguably the first video game ever).
But my primary inspiration was a game called Starflight.
Starflight was one of the first entrants in the genre to fully realize its potential by combining RPG elements with a procedural sandbox universe. Incredibly advanced for its time, it inspired numerous others including Star Control II, Escape Velocity, and many others. It had multiple alien races with unique ships and dialogues who varied their disposition toward you depending on your actions. It had a galaxy of nearly a thousand planets, most of which you could land on and explore. It had an engaging story that unfolded through exploration.
Starflight: my earliest inspiration
I wanted to create a game like that: a vast open universe of exploration with aliens to meet and battle, and stories and mysteries to uncover. Unfortunately, one tower defense game under my belt wasn’t quite enough experience to make that a reality.
But I still wanted to try to make a simplified version of that vision.
My initial attempt was relatively modest in scope, but still a big step up from the tower defense space game: it had fast-paced combat with multiple weapons and upgrades, a simple story line and some light RPG elements including ship upgrades. There were no alien races you could talk to, the planets were simply window dressing and the whole game could be finished in about an hour or two. But I was immensely proud of the accomplishment and like PlanetDefender, it was fairly popular among the Flash gaming community.
My second Flash game: Starcom
Since the dominant form of making money from Flash games was ads and sponsorships, which usually paid pennies per thousand plays, neither of these first two games made a substantial amount of money relative to how long they took me to develop. Which was fine because this was still a hobby for me.
At this point I felt I had enough experience to attempt to make a game with the goal of doing it professionally.
After my last web dev contract wrapped up, I set myself on the task of developing my third game: a multiplayer real-time roguelike dungeon crawler called Lost Crypts. It was loosely inspired by the standup arcade Gauntlet that had eaten hundreds of my quarters as a kid, but with rogue-like procedural dungeons.
My third Flash game and first attempt at an indie commercial product
It took a little over six months to develop and I spent $1000 on art and music. Players generally enjoyed it, but my attempts to make money from it failed utterly. At the time, my understanding of both game marketing and free to play monetization were quite limited. I told myself that it was successful as a learning project and portfolio piece, which is true, but privately I felt I was failing as an indie developer. My games had made a lot of people happy and I don’t think people should be valued based on how much money they make, but realistically I couldn’t afford to continue as an indie dev making less than minimum wage. And Lost Crypts didn’t even recoup its external costs.
So I returned to contract work to pay the bills. During that time a few players tracked me down to ask if I had any plans to make a sequel to my space RPG.
In the era of Flash gaming, a developer released a game and if it was popular it would end up being re-hosted on numerous websites. I had the foresight to have the game “ping” my webserver when a player started a new game so I could have a count of gameplays, but there was no way to connect with the many players who might be interested in my next game. Which was a mistake I would later regret, once I learned the importance of marketing in game development. This might seem obvious in hindsight, but since my first two Flash games reached hundreds of thousands of players with no marketing effort on my part, I sort of assumed that if you made a good fun game people would find out about it somehow.
Better late than never, I set up a mailing list so players who visited my website could let me know they wanted a sequel and say what features they thought it should have. A few hundred interested players found the list, bringing with them the hope that there might actually be a market for an ambitious game like the one I’d originally envisioned.
The Meandering Road to Release
By this point, it was clear that I needed a new engine for the project: the writing was on the wall and Flash’s days were numbered. So I switched to Unity, the most reasonable option at the time.
According to my task tracker, the first two chores I completed while working on the game were “Install Unity” and “Spacegame tutorial parts 1-8,” both marked as done on April 5, 2014.
Two tasks down, 8000 to go.
Over the next few months I worked part time between contracts at a slow but consistent pace until I had a playable demo: the controls and combat worked similarly to the Flash version. Unity’s lighting and particle effects made everything seem much more polished.
At this point players would certainly recognize the seed of Starcom: Nexus.
But it was very far from a complete game. The RPG elements were still superficial and without them it was just a top-down shooter with boring pauses between the action. I could definitely see how to recreate a prettier version of the Starcom Flash game, but I was having trouble visualizing a path to “epic open world RPG of space exploration” that I dreamed of.
After being rejected from showcasing the game at a game festival, I became discouraged. I went back to full-time freelancing and put the game on hold. I didn’t touch it again for almost two years.
In 2016 during a lull of contract work, I started on it again. A few ideas, once implemented, started to fill in the gaps in game play: I implemented a discovery system where players could get “research points” by finding new things. I added a Research Tree where players could spend those points to get faster engines, new weapons, etc. I created a system where players could build their ship from modules, increasing the feeling that the ship was their own.
And I started to fill in the game’s content with visually interesting things to find, conversations with various characters and lots of pretty planets. I wrote and re-wrote a backstory to tie everything together.
By March 2018 I’d made significant progress but was getting concerned about the fact that I’d spent several thousand hours and several thousand dollars with no clear sense as to when it would be done. With no roadmap, deadlines, or stakeholders it seemed like I could go on forever and never release the game.
I think this pattern was driven by a fear of failure. As long as I kept it in “experimental pre-alpha side project mode” I never had to confront the possibility of putting my hard work out there and failing completely. With the previous disappointment of Lost Crypts, I was afraid that another commercial dud would effectively be the market telling me: “You’re so bad at this, you don’t even know how bad you are.”
I needed to commit to a decision: Either a) admit to myself that this was just a hobby and return to focusing primarily on contracting work, or b) approach it as a business with the potential to be something that players would love and provide a real return on its development cost.
If I went with the second choice, I decided that it was not necessary that the project be 100% profitable in terms of recouping all external costs as well as the full opportunity cost. Instead I decided to analyze the chances that it could pay all external costs plus a living wage for the remaining development time, while ignoring sunk costs (a “bygones principle” analysis). This was an admittedly low bar, but perhaps not unreasonably low: If I reached it while simultaneously building a base of happy players, it increased the likelihood that I could continue with a sequel reaching true profitability.
As a starting point, I had a spreadsheet of games released in recent years that were in the same nameless genre as mine. Using established heuristics, I verified that there were a fair number of titles produced by solo devs and small teams that seem to have sales at least at the level I was targeting. But with caveats: Survivorship bias made it difficult to locate the games similar to mine that had launched and were never seen again. There was no “starflight-like” tag to easily identify the also-rans.
Also at this point the industry was well into the so-called “Indiepocalypse”: every week a new story would appear on my radar of a developer who had spent years on a game only to sell a few hundred copies (or worse).
To minimize the worst-case scenario risk, I committed to three things:
Get a playable beta of the game in front of real, potential customers by mid-Summer 2018 to verify I wasn’t way off course;
Generate market proof by releasing a version for sale within 12 months (e.g., Early Access), which meant by early 2019;
Make a serious effort to better understand how to market the game.
Design Issues
Before this story plunges ahead into beta and beyond where you’ll learn the outcome of my quest, I’m going to rewind a bit and talk about one of the many reasons it took so long to get from “Unity Space Game Tutorial” to “Playable Beta.”
I had made a fun Flash game that was basically Asteroids with some RPG-lite elements. I also had ambitions of an open-world PC RPG that could evoke feelings of exploring a large and rich universe full of wonders. Actually combining those two concepts in a way that produces fun and coherent game mechanics is harder than it sounds.
Compiling a list of the major design decisions I had to visit and revisit would take longer than I am prepared to spend on this postmortem.
Rather, I’m going to tell the story of a single illustrative feature: what I call “The Planet Problem.”
The Planet Problem
In the original Flash game, planets were just decorative landmarks near where the player might encounter enemies. They looked pretty, helped orient the player, and generally made space seem less empty, but they had absolutely zero game play effect.
A planet from the original Flash game.
One of my high priorities for Starcom: Nexus was to add some kind of interaction to planets. I imagined them like treasure chests in RPGs: having defeated whatever menace was guarding it, the player would be treated to the reward of discovering what was in the box.
As I mentioned earlier, a major source of inspiration in the game’s overall design was Starflight, which had a very sophisticated planet exploration mechanic for its time. The player would pick a point to land, send a rover down (accompanied by an impressive 3D landing animation) and drive around a 2D map collecting resources and avoiding dangers.
Starflight: Amazing for its time, but the planet interactions are tedious and dated by modern standards.
It was a great mechanic for a game released in 1986, but hasn’t aged well. Essentially it boils down to turn-based Pac Man without the maze. Forcing the player to engage in a mini-game that is less fun than the actual game they are playing isn’t a great reward.
What I wanted was something fairly quick: a sense of anticipation and mystery, some agency, then concluding with the potential of a reward.
My first playable prototype of this mechanic was a targeting mini-game. The player right-clicked on a planet, then scanned it. If the scan revealed “anomalies” the player could target them with their lander. If they hit, they received the anomaly’s reward:
It was sort of fun, but only for the first half dozen times. Targeting the anomaly had some skill due to the rotation of the planet, but if you missed with any frequency at all, the whole thing felt frustratingly tedious. If you mastered the targeting, it was just a time sink.
I experimented with several modifications, but it quickly became clear that no variation was going to be fun for hundreds of repetitions throughout the game.
One of the most difficult decisions in game development is tossing a feature after investing a lot of time and energy into implementing it. But sometimes a game mechanic just doesn’t work.
So with some regret I simplified the interaction. The player scanned the planet and was informed if there was something there or not. If there was, they could send a lander down to investigate, no mini-game at all. I also simplified the UI by removing the separate scan window: the player just flew to the planet and pressed a key or controller button.
At this point, all anomalies consisted of a title, an image, static text and resource reward. There was a sense of mystery and the potential for reward. I could tell it would be more fun than my first attempt, and the fun could be scaled up with more variety of anomalies.
The next question became: “how much variation can you have with static text and one of eight possible resource rewards?”
Based on a mechanic I encountered in the game Out There, I added multiple choice options to some of the anomalies, giving more variety and a greater sense of player control to the surveys. I also added the potential for penalties, like the loss of crew.
Next I made it so that some of the choices could open up into a second set of choices, based on the first. Finally, I noticed that anomalies were starting to look more and more like multiple-choice dialogue trees, which I had already implemented for NPC conversations. So I scrapped the anomaly data model and turned all anomalies into “conversations with a planet.”
Hey planet, how’s it going? Got any resources?
Because the dialogue system supports scripting via Lua, and I’d already created API hooks into the game logic, this opened up infinite possibilities for the complexity of anomalies.
For example:
A giant stone structure with a control room inside. If the player activates the controls, a nearby warp gateway becomes accessible.
Aliens with a disabled ship. The player can offer to help if they have sufficient resources.
A rogue trading outpost which requires a password to enter (which the player can learn from conversations with another race). Once inside, the player can trade resources or purchase unique items.
An underwater labyrinth. If the player sends a crew member down, they must navigate through a Colossal Cave-style labyrinth in a limited number of moves before their oxygen runs out.
My first attempt at an anomaly image.
To help distinguish the anomalies, I started creating images for them using a 3D environment modeling tool called Vue and then editing them in Photoshop. My first attempts to create distinct environments for the anomalies were not very good: they looked like the pre-rendered backgrounds from 90’s adventure games. To conceal the low-quality of images, I created a shader that added static and video scanline effects, simulating an image transmitted from the surface (nevermind why humanity switches back to CRTs in the future.) and reduced the display size of the images to 400×400 pixels.
With practice, I learned how to improve the quality of my anomaly images, so I was able to scale up the image display, but I kept the shader effect because it made the images seem more alive.
The scan/survey mechanic in action.
My improvement in creating anomaly images resulted in better-looking encounters, but at the expense of taking more time. While I found the process a relaxing break from other areas of game development, I’m a bit of a perfectionist which led to spending lots of time polishing the results.
Combined with writing the anomaly text, and writing the custom logic in Lua, meant that each anomaly took several hours to create on average. I couldn’t repeat many of the anomalies without breaking the immersion of exploration and a star system with no anomalies feels empty and disappointing. There are roughly 200 unique anomalies in the game and they all took at least a few hours to create including image, writing, custom logic and testing.
An anomaly image after I’d gotten some practice
The Feedback Cycle
Not every element in the game required as much time as the Planet Problem, but almost every major feature took multiple attempts to get right. So Starcom: Nexus didn’t start its first round of beta testing with actual players until early August 2018, after the equivalent of a fulltime year of development.
Beta testers were randomly selected from the game’s mailing list which had been very gradually accumulating subscribers and were about as “in market” as I could expect. If a significant portion of them didn’t like the core gameplay, I had a serious problem.
Initially, I started with small test rounds of a dozen or so players with the goal of identifying the big problems, gradually increasing as Early Access launch approached.
Qualitative Feedback
Qualitative feedback is a player’s subjective impressions of the game. It’s what they consciously report liking and not liking in the game. It could be given in person, email, responses in discussion forum, etc.
For the closed beta tests I implemented an in-game system where players could submit feedback any time by pressing F8, which paused the game and brought up a dialogue where they could put in their thoughts along with a rating for how they were enjoying the game. This was an interface I copied from Subnautica. A reminder was subtly, but constantly visible in the lower corner of the screen throughout the closed beta and Early Access, as well as one of the possible tips that could appear during game loads.
The in-game feedback dialogue
There are a number of advantages of this system:
The ability to give feedback any time allows me to captures impressions that players may forget by the end of their session.
The anonymity of the system makes players less likely to feel that they have to soften their criticisms or they must say something good if they’re saying something bad.
I can easily collate feedback based on the game’s version from the database.
The only significant disadvantage is that it doesn’t prompt players to give their gestalts impression of the whole game as an experience. Some players might elect to give it at some point, but many did not. To help with this I encouraged players to submit their impressions via other channels like the Steam forums.
The qualitative feedback was overall very positive and helpful: players professed to really like the game play and had suggestions on how to make it better.
Analytics Data
Player feedback was probably the most important source of data on what needed fixing, but to reinforce and validate that feedback I also collected anonymous event data to ask statistical questions like “how long does it take the median player to finish the game?” or “what percentage of players who start the first mission finish it?”
It also helped assuage the notion that perhaps players were merely being polite: e.g., having been given access to the beta, they felt obligated to give some kind of positive feedback.
But combined with analytics there was a strong case that some players were really enjoying the game. In the first limited round of beta tests, half of players stopped playing very early on (within two minutes) for reasons I wasn’t immediately able to figure out. But of those who made it past the first few minutes, almost all finished the available content. While it was conceivable that a player might launch a game and give some quick impressions to be polite, the fact that a good chunk of testers played to the “end” was an encouraging sign.
A pleasant surprise was that the game was longer than I thought: I could play through the current content in 20 minutes, so I had guessed new players might take 30 to 45 minutes. Real players averaged 90 minutes. With a goal of at least 4 hours of gameplay for Early Access, I wasn’t as far away as I feared.
Observational Data
Analytics data tells you what players are doing and qualitative feedback tells you what they are feeling. Combined they give you a lot of insight into what is and isn’t working. But observation fills in gaps that you might be missing. For example players may wonder aloud what would happen if they did “x.” Players who aren’t sufficiently engaged may quit in boredom just before something interesting happens.
As a specific example, I mentioned earlier that a non-trivial percentage of players stopped playing very quickly, within a few minutes. Was the game’s performance bad? Did they just not like the genre? Neither the players nor the data were telling me.
I speculated that they missed the instruction that they should head toward a specific objective, so I made the objective indicator brighter and flashing. This change cut the number of players who failed to make it to their first objective in half, from 13% to 7%.
It wasn’t until I observed a player in a live session that I realized some players thought they were supposed to follow the ship that had given them their orders, and had their eyes fixed on it, ignoring the glowing, flashing arrow in the corner of the screen. Worse, once the player was sufficiently far from the objective, it was removed from the radar.
I added a relatively minor change to have the first officer gently remind the player, if they continued in the wrong direction. I also extended the radar range for mission objectives. These changes cut the early drop-out rate from 7% to 5%.
A few players followed the ship that gave their orders instead of the mission beacon.
These fixes to the first half hour of the game were huge: consider 1000 players starting the game. A 13% drop out at the beginning of the game is an immediate 130 players whose opinion will be mediocre at best. They will likely return it and/or leave a negative review. It’s hard to connect minor improvements in the early experience with the overall response to the game, but I strongly suspect they have a more than trivial effect. As an aside, Steam reports the game’s median playtime of 9 hours to be “above average” (although they do not say what the average actually is).
Over the next several months I repeated a loop: release a build, email a batch of fresh testers, gather feedback and analytics, implement the changes that players either asked for or I inferred were needed, create new content, and repeat. By late October things felt good enough that I could launch in 2018 before the Winter Sale, so I announced a release date of December 12.
Marketing
I am probably not unique among indie devs in that marketing is not my favorite game dev activity. I’d much rather just spend my time working on the game than try to talk about it at all.
But all my research has consistently pointed at one conclusion: the success of a game on Steam depends almost entirely on reaching its market before launch. Using Steam review counts as a proxy for sales, review score as a proxy for quality, and pre-launch followers as a proxy for market awareness, the rank correlation between quality and sales is 0.25 (weak) and the correlation between pre-launch awareness and sales is 0.86 (strong).
The uneven traffic to the game’s Steam page prior to launch.
As mentioned previously, when I decided to commit to Starcom: Nexus as a serious endeavor, I also committed to start taking marketing seriously.
I started a marketing journal. I made a list of games in the same “space” as mine, either released or upcoming, and read their reviews. I made a list of YouTube streamers and journalists who had covered those games. I tweeted often. I posted videos and images to relevant Reddit subs.
One aspect of the game that was a problem from a marketing perspective was the lack of clearly identifiable “hooks.” As I mentioned earlier, the genre doesn’t even really have a name. When prospective players asked in the discussion forum what other game it was like, there was no consistent answer.
Explosions are easier to show-off than “an abstract sense of mystery”
The game’s best feature was really hard to communicate in a short clip, GIF or marketing blurb: the sense of exploring a mysterious open universe. In a post-launch player survey in which players checked-off their favorite parts of the game, exploration was the most selected. When players talked about their favorite aspects of the game, it was usually a response to something that was hard to convey visually, like discovering that by aligning a pair of mass accelerators, they could be transported to a hidden star system. The event itself was not spectacular—it was the delight in discovering something unexpected.
I tried to convey the exploration elements by showing planet surveys, alien dialogues and space artifacts, but my trailer ended up focusing mainly on the most eye-catching aspects of game play: enemies exploding in fireworks of particles and pretty space settings.
In the aforementioned player survey, I also asked how people learned about the game. Here’s what players said:
79% saw it on Steam
12% saw a YouTube or Twitch streamer play it
6% played the original Flash game
3% saw it somewhere else
Because I didn’t post the survey until after full launch, it probably underestimates the number of players who learned about it from the original Flash game, since I think they were more likely to have been on the mailing list and bought it in Early Access. But it does underscore the importance of the Steam algorithm working as a multiplier of your marketing efforts.
Note that I say “multiplier”: it has been consistently observed in data and anecdotes that 95% of games which launch with little to no public awareness vanish into obscurity, buried in the avalanche of other titles released that week. Games that achieve sufficient traction are shown more prominently by Steam’s algorithm.
Entering Early Access
From a sales and marketing standpoint, entry into Early Access needs to be taken seriously. For almost all games on Steam, EA or otherwise, their launch week shapes their entire return. Almost all games’ first year sales are a single digit multiple of their first week, generally clustering around 3 to 6 times. E.g., a game that sells 100 copies in the first week could expect to sell 300 to 600 copies in the first year.
From my analysis of visible Steam data, many EA games receive some kind of bump when graduating to full release (sometimes even a big one) but if a game hasn’t found some footing in the market at the start, it will almost certainly fail.
I had personally committed, both to myself and players, not to abandon Starcom: Nexus during Early Access.
But my savings were not inexhaustible. By this point I’d spent 3800 hours over the equivalent of 16+ full time months and roughly $10,000 of my own money. This is excluding the larger cost of, you know, living. I’d been working 60 to 70 hours a week for several months. Combined with the uncertainty about how the game would fare, this was producing a large amount of stress.
Cumulative hours to Early Access
There is a scarcity of hard data to predict a launch success, particularly for EA titles. One analysis done by Jake Birkett estimates that during its first week, a game will sell 0.5 copies for each player who has wishlisted it before launch. But this was a limited survey and there was a range of results: from 0.14 to 1.8. Moreover, the games surveyed had mostly been released at a time when Steam was seeing fewer releases per month.
I felt a worst-case scenario would be the game selling only 400 copies in the first week. Combined with a pessimistic tail model, that could be as low as $30,000 lifetime, and that’s before Valve took their revenue share. If it did that poorly, my plan was to do an aggressive but abbreviated Early Access and start sending out my resume in a few months. I did not believe this was a likely outcome, but it was a possibility that had been magnified in my anxiety-wracked mind, which had begun contemplating “even worse than worst-case” scenarios.
A slightly more optimistic model was 800 copies the first week. With a reasonable tail and a moderate bump on graduation, this could justify the “bygones” decision I’d made, at least in the sense that I would have made more than a living wage from the time of that decision to the time of full graduation. Which is a very forgiving criteria, but also excludes the value of an established audience for future games. In this scenario my plan was to spend 6-9 months in EA and after launch evaluate the possibility of a sequel.
At the most optimistic end, I estimated as high as 2000 copies in the first week was possible based on wishlists and followers.
After nearly 4000 hours of development, I pushed the launch button that officially triggered the game’s entrance into Early Access.
The Button
After an incredibly stressful first day, it became clear that the worse-case scenario wasn’t going to happen: the game sold over 500 copies in the first 24 hours. The sales rate dropped rapidly after the initial rush, but I had expected that. Like the first week making up a significant percentage of annual sales, the first 48 hours usually make up a majority of the first week sales.
One week after entering Early Access the game had sold over 1500 copies and grossed a little over $20,000.
First three months of Early Access
At this point, I’d like to draw attention to a convention in indie PC game development: when developers publicly talk about gross revenue, we are not usually referring to the money we receive before expenses, which is the standard accounting definition of gross revenue. We are referring to the money Valve (or another distributor) receives. Why? I don’t know, probably because it sounds more impressive. But that amount never appears in my bank account. It’s like including part of your boss’s salary when someone asks how much you make. So when I say the game grossed $20,000, I mean that Valve collected $20,000. After various deductions like VAT, returns and Valve’s revenue share, Wx3 Labs LLC (which is just me) grossed around $12,000. Which still sounds pretty good for one week, except that a) I had spent $10,000 in development and b) sales drop off a LOT after the first week.
Even though I had only net $2000 in profit for my 16 months of labor so far, this was a good start and I could at least hold off work on my resume for the moment and focus on finishing the game.
Early Access Development
The beta testing paid off in the sense that nothing went catastrophically wrong on launch. Players were in general very happy: the first few dozen player reviews were all positive, and after 100 reviews it had a score of 94% positive.
But it was still obviously a work in progress. After several patches to hot-fix a few potentially serious bugs, I started work on the first post-release milestone, adding features and content to extend the game from a polished beta to a full game.
I tried my best to be accessible to the players via multiple channels: I checked the Steam discussion forums every day, was always logged into Discord and read the “F8” feedback logs regularly. And, as painful as it was, I read every single negative review on Steam.
Listening to players’ pain points gave me the best insight on where the game needed work. At the same time, I had to resist the temptation to pivot the overall design based on the strongly expressed opinion of a handful of players.
Over the next ten months the game grew. From a few dozen star systems to over 150. The median time for players to complete the game increased from six hours to well over twenty. I added features that players asked for like attacks drones and quick-saves. Towards the end I added an element that I had conceived of and teased in the very first piece of concept art: a mysterious Dyson sphere that the player could enter.
The game continued to be well-received and saw spikes in customers with sales and Steam events, but after the post-launch cliff, average revenue continued to slowly drift downward: it looked like the game was experiencing a fairly typical Steam release life cycle. There was plenty more I could do on the game, but the longer I spent the less overall return I would see, and the less budget I would have for my next project.
I also wanted to make sure that the game graduated from Early Access before I was too burned out to properly support it. The game had a beginning, middle and end. The core features were all in, tested and well-polished. In the Steam Store description I had pitched a 6-12 month Early Access period and that was rapidly running out.
So in late October I announced a December 12th release date, exactly one year after the initial launch.
Graduation Day
In the lead-up to the game’s graduation from Early Access, I had frozen development to ensure that the first version non-EA players experienced was as bug-free as possible. There was plenty for me to do: market outreach to potential streamers, more analysis on the analytics data and even starting preparatory work for the next project by improving my 3D modeling and texturing skills.
I also spent a lot of time trying to guess what would happen when I pushed the “launch button” for the second and final time.
By this point, the game was doing “great” by indie game dev standards but just “okay” by the standards of someone trying to start a business:
After one year in early access it had sold 6500 copies and grossed $98,000. After Valve’s cut, VAT, and other deductions that left $60,000.
During Early Access I had spent another $10,000 in external costs for a total of roughly $20,000. That left $40,000 in net revenue. Divided over the entire development lifecycle so far, that worked out to $16,000 per year. That’s more than US minimum wage but just barely, and not even close to a living wage.
But there was the fact that unless graduating from Early Access actually caused sales to drop to zero, the game had expectations of earnings that would continue to come in over its lifetime, albeit at an ever-diminishing rate. My ballpark guess was that with zero graduation boost, the lifetime return would work out to around $32,000 net per year of development after external costs, before taxes. That’s for the full development lifetime, including both the “pre-commit” time when I had yet to really analyze the prospects for the game, plus some amount of post-graduation support.
On top of the financial return, I had gained a lot of skills, both in technical and design areas, as well as a much better understanding of the business aspects. I had a base of several thousand players with a positive experience who might be interested in a sequel.
And there was the hope, expectation even, that graduating from Early Access would produce a measurable sales boost.
Conventional wisdom among devs is that you only get one launch and you should treat entry into Early Access like it’s your only shot. Anecdotally, some indie developers have reported little visibility boost on graduation, but others have seen a significant increase in sales.
During pre-EA market research, I had been tracking a large cohort of Steam games that launched around the same time as mine. Some of those were also Early Access titles and a dozen of those had graduated by this point. Most of those showed a spike in review counts after graduation that suggested a healthy increase in sales, in some cases apparently matching or exceeding the EA launch over a slightly longer time period. A few of the titles, however, showed no increase at all around the time of their graduation. And again, review counts are only a rough proxy for sales. Guessing from limited data (which was something I did a lot of while wearing my indie market analyst hat) I thought there was a good chance the game would sell at least 30% of its initial launch numbers in the few weeks after graduation.
In my marketing journal, the day before full launch I wrote: “My best guess is that first month of graduation will sell between 700 and 3000 copies, but that’s a wide range.”
A few hours later, apparently gripped with pessimism, I added: “I have now convinced myself after looking at Steam that it will get no boost above a normal sale.”
Those late fears turned out not be realized. Quite the opposite: initial sales were well above my projections. In the first 24 hours of full release Starcom: Nexus sold over 1000 copies, and another 1000 in the next 24. Numbers began dropping rapidly after that, but after a week the game had grossed almost as much as the entire year of Early Access. That sounds a lot bit better than it really is because of how front-heavy game sales are, but it was still fantastic.
Early access launch vs Full launch
So I was wrong in my graduation predictions. It’s the kind of wrong I’m delighted to be, but it was still wrong and it would be helpful to understand why.
Looking back, there were several major causes:
In my examination of recent Early Access graduates, I think I had subconsciously “rounded down” some of the graduation ratios (ratios of graduation week review counts to launch review counts), possibly in a sub-conscious attempt to avoid severe disappointment.
A number of graduates had their graduation review counts spread across a wider time frame. I.e., while most launches have the bulk of their first reviews in the first week, many EA graduates saw the reviews spread over 2-3 weeks.
During Early Access I consistently had around 1 review for around every 30 copies sold. After graduation, that ratio changed to about 1 review for every 40-45 copies sold. If that shift holds true for other Early Access titles, it would explain a good chunk of my underestimation.
As of writing, a little under six months after entering full release, the lifetime results for the game so far are:
Steam gross revenue: ~$460,000
Copies sold: 29,000
External development expenses (music, art, licenses, etc): $26,000
Total development time: equivalent to 30 full time months
The net result has been that the game has so far earned me a bit over $8000 per month of development (before income tax).
That result from creating the game I’ve always dreamed of making is a feeling I can’t describe. I am tremendously fortunate to have had this opportunity.
The bundle was launched in response to the murder of George Floyd by Minneapolis police, with itch explaining it wanted to raise funds to help push back against racial injustice, inequality, and police brutality against Black people.
As it currently stands, the bundle allows folks to pay a minimum of $5 to gain access to over 1000 titles from more than 1300 creators, including popular games like A Short Hike, Minit, Celeste, Overland, and Night in the Woods — to name but a few.
Itch had originally hoped to raise $5 million, but has managed to raise almost $5.4 million with just under four days to spare. Over 500,000 people have contributed to the cause so far, and developers have been rushing to add their titles to the bundle to help generate even more traction.
“We live in a time of racial injustice, inequality, and police brutality against black people. We hope that everyone takes a stand in any way that they can. We’ve partnered with creators from all across our platform to support organizations that are working directly with those affected,” wrote itch.
Twelve people have gotten themselves into hot water with police in China over allegedly selling hacks for the Chinese version of PUBG Mobile. As translated and reported by Abacus, the group used Bitcoin to purchase the cheats from “overseas personnel” before going on to sell them to Peacekeeper Elite players. Kunshan police say the business is worth up to $15 million, which makes me question what I’m doing with my life.
The hacks themselves are relatively standard. The cheats give players the ability to see people through walls and hit as many headshots as they please through the use of an aimbot, which is particularly brutal given it’s a mobile FPS game. The punishment is currently unclear if the group is found guilty, but people have been fined for similar offences. As Abacus further points out, two men were given a one-year prison sentence and a $2,833 fine for creating Honor of Kings hacks.
If you’re unaware, Peacekeeper Elite is Tencent’s Chinese version of PUBG Mobile. Despite initially being available in China, the battle royale game was modified and re-released under a different name to satisfy China’s censorship restrictions. Peacekeeper still looks just like PUBG Mobile, from character models to general graphic texts. In this version, though, there is no blood or gore, and words like ‘kill’ are swapped to non-violent alternatives like ‘defeat’.
It appears that PUBG Mobile hacks aren’t just limited to China, however. A glance at the game’s unofficial Subreddit page reveals several complaints from players in the last few hours alone. There’s even a specific post flare designed to report accounts of cheating.
We’ve reached out for more information and will update this story if we hear back. In the meantime, though, you can check out our PUBG Mobile update guide for more up-to-date information on what’s going on. We even have a guide on the best multiplayer mobile games if you fancy something different.
Sony’s PlayStation 5 game showcase revealed the look of the next generation console and, as with its accompanying DualSense controller, the system makes quite the first impression.
While competing console-maker Microsoft went for a nondescript boxy look for its own next-gen entry, the PlayStation 5 opts for a distinctive silhouette that carries the same black and white motif debuted with the DualSense controller last month.
In the case of that earlier debut, SIE president and CEO Jim Ryan said that a striking visual shift from previous PlayStation products aimed to “[capture] just how strongly we feel about making a generational leap with PS5” and it seems that same philosophy applies to the PlayStation 5 itself.
The debut introduced two different versions of that launch console, one that features an Ultra HD Blu-ray disc drive and one that scraps a disc drive entirely to instead offer its players the option to go all digital when entering the next console generation.
The short hardware preview also revealed a small hoard of new PlayStation 5 accessories, including the Pulse 3D wireless headset (with support for the 3D audio feature PlayStation previously discussed at length), a HD Camera with dual 1080p lenses, dedicated media remote, and charging station for the PlayStation 5’s DualSense controllers.
The rest of today’s live stream ran through some of the games from both PlayStation Studios and external developers that’ll arrive on the PlayStation 5 within the early days of its lifetime, including peeks at Guerilla Games’ Horizon: Forbidden West, Insomniac Games’ Ratchet & Clank: Rift Apart, and IO Interactive’s Hitman 3.
One notable absence from today’s live stream was a price. While rumors have popped up online from time to time, neither Xbox nor PlayStation have yet to officially announce a pricepoint for their next generation hardware despite both consoles being expected to launch in Holiday 2020.
In a followup press release, Sony says that info on both pricing and additional PS5 details will be announced “at a later date.”
As Java Software Developer, you work closely with our game teams to shape the foundation of our next big hits and contribute as a productive member of an agile development team in all phases of the development lifecycle.
Your mission:
Develop features shared across our game backends
Improve performance-critical components, increase the robustness and scalability of our software
Improve our libraries and backend services with your knowledge of software architecture and high-quality code
Maintain and extend our development tools and environment
Your profile:
Degree in Computer Sciences, Business Information Systems or equivalent training and experience as IT specialist
Several years of experience in object-oriented programming in Java with Spring Boot and optimally the Akka framework
Software development with Spring, the UNIX command line and profound knowledge of SQL, GIT, and Continuous Delivery
You love to dive deep into other people’s code which is reflected in your Github profile.
Solid experience in using various methods in software design and a strong belief in automated testing to guarantee and improve code quality in compliance with the company standards
Being a backend geek, you also like to switch to the frontend side with Angular, C# and Unity
Good English language and overall communication skills
Proactive and motivated individual with a willingness to learn
Why join us?
Be part of a great international team in a healthy and stable growing company
Your working device is the latest MacBook Pro with high end hardware
We actively support your further development and give you all needed resources to evaluate new technologies and participate in open source communities
We provide additional training budget to spend on attending conferences, taking hard skill courses or improve your soft skills as well as purchasing books
Our career model is set up equally for an expert in a technical career or a management path
Use opportunities to make your code open source and show your achievements at international conferences
We offer competitive compensation with benefits like relocation support, company gym, smartphone or tablet, company bikes, rooftop terrace with BBQ and much more
Excited to start your journey with InnoGames and join our dynamic team as a Java Software Developer? We look forward to receiving your application as well as your salary expectations and earliest possible start date through our online application form. Cristal Ledesma would be happy to answer any questions you may have.
Apply and #stayhome! Due to the coronavirus outbreak, we switched our operations company-wide to home office and turned our hiring process into a fully virtual one. When hiring, we are also open for our new team members starting their work remotely at the time being or adjusting contract start dates accordingly. Stay home and safe!
InnoGames is Germany’s leading developer and publisher of mobile and online games. The company based in Hamburg is best known for Forge of Empires, Elvenar and Tribal Wars. InnoGames’ complete portfolio encompasses seven live games and several mobile titles in production.
Born as a hobby, InnoGames today has a team of 400 employees from more than 30 nations who share the passion of creating unique games that players across the globe enjoy for years. In order to further expand our success and to realize new projects, we are constantly looking for young talents, experienced professionals, and creative thinkers.
Whether you’re just starting out, looking for something new, or just seeing what’s out there, the Gamasutra Job Board is the place where game developers move ahead in their careers.
Gamasutra’s Job Board is the most diverse, most active, and most established board of its kind in the video game industry, serving companies of all sizes, from indie to triple-A.
