Did you ever stop to think that a game’s downloadable content (commonly known in the game industry as DLC) and the overall game development scene currently have a lot in common with software development? No? Well, let me tell you all about it!
Game development: an extremely abridged summary of its history
Game development used to be well thought out, designed from beginning to end, with intensive weeks of testing and fine tuning, bug fixing, and all the things you’d expect from a software company. Then, the game hits the stores, everyone buys it, it gets good reviews, happy customers, happy company.
In the last 5 years or so, the video game industry has seen a major change in its time-to-market. Fans and aficionados demanded that games be released as soon as possible since they are way too eager to try them out and beat all 500 levels in 20 different difficulty settings (your mileage may vary).
But that’s the customer side of things. What happened on the product/development side? If the customer demands it, we must deliver! Right? Well, that’s where things started to go wrong…
When some game studios decided to go down that road, it was well expected that some cracks would start showing. Let’s consider the following scenario:
- The final deadline is in 3 weeks
- You and your team have 30 tasks/features to do
- You have estimated that this deadline is a bit tight for all the development (and testing!), but you can pull it off
- Then, PR/Sales chimes in and says: “Guys, we really need to have this ready in 1 week, at most!”
- chaos ensues
Some video games faced this exact type of situation, due to which they ended up getting bad reviews because of bad graphics (cinematic vs. in-game footage), plot holes, bad animations, buggy controls, etc. What the companies ended doing was releasing bug fixes and all the missing features as DLC, which contradicts what DLCs are: new game content!
Software development
Can you see how this relates back to your project? On the first meeting with the client everyone gets to know the project: scope, main features, obstacles that may arise when developing, the usual stuff. Based on this, you and your team outline a roadmap with sprints or a list of checkpoints, whatever flavour of project management you prefer. But one thing has to be set in stone: the deadline. The deadline should be a fixed date, far off in the future, and it is advised that the week before the deadline no major feature or redesign is implemented, since this has a huge cost on tracking down new bugs and testing the application end-to-end.
So, what can you do when the client wakes up one morning and says “This needs to be ready next week”, when it was supposed to be ready in three? Neither of the following answers are satisfactory (for you or the client), but here they are:
- Cut down on project scope — let’s face it: it’s extremely hard to accomplish in 1 week what you had planned to do in 3. So, the easy thing to do is cut down on features. It’s better to have 15 fully working features than 30 somewhat-working-but-only-on-a-given-scenario features. The client may not like that the project doesn’t have all the sparkly stuff they wanted, but at least it won’t crash during the live demos.
- Push the deadline forward — this is what may first come to mind when approaching the original deadline and acknowledging you can’t make it (if only I had more time…). This is hard to discuss, because now the client has to rethink their marketing strategy and PR stuff, as they have announced their project would go live sooner than expected. If they stick to this idea, then you’re gonna end up in a situation similar to one from the previous solution (30 buggy features vs. 15 working features).
If, however, you end up releasing the product as scheduled by the client without any changes regarding which features are included and feature completeness, then you’re probably going to be creating DLC-like updates, finishing up on your previous work and fixing bugs all the time.
Conclusion
None of the solutions presented above are ideal, nor should they be applied at all times as if they were a panacea. Feature status and deadlines should be something you discuss with the client regularly, to keep them informed on how far ahead/behind schedule you are, and to keep you informed of any schedule or feature changes on their side.
Whether it’s frontend, backend, mobile or DevOps, at Runtime Revolution we have a spot for you!
Top comments (0)