AuraQ has vast experience helping organisations find the gaps that can be filled to enhance their business. This could be to improve efficiency, integrate legacy systems or deliver new portals and strategic applications to create competitive advantage. Contact us to request a free, no obligation Gap Analysis.
25th Jan 2018
Five lessons an independent game developer can take away from working in software development
It’s been a long standing dream of mine to make computer games, and this has lead me to learn to code and eventually get a career in software development. Before starting my career I had spent more time than I am willing to admit on failed computer game projects. I had no problem coming up with an idea and prototyping it, but I have never been able to develop a game to completion, always running into difficulties and eventually getting bored of the project. I reasoned that my inexperience was the problem, that I’ll just need to become a better programmer and I’ll finish the next one. I was right about the inexperience but my failure couldn’t be put down to any one reason, rather a myriad of bad decisions that doomed my projects long before they even started. I won’t go into detail on what all of these were, but I did carry some of them over with me when I started working in software development, and it wasn’t until I started to work on real projects in a team environment that I started to see just how badly I was approaching things. These are five lessons I’ve learned over the last year and how they apply to independent game development.
1. Schedule and scope your work
I used to come up with an idea for a game, write up a brief description, and just start coding away. I had no plan and would just work on whatever aspect or feature I felt like working on at the time. This resulted in many unfinished components in varying states of completion. When a component relied on another one I’d have to stop and work on the other and eventually come back to the first. This meant that it would take a long time to see results as no one component ever got finished which really sapped motivation, and if I returned to the project after a few days or weeks break, it was near impossible to pick up again as I could not remember where I’d gotten to on any one part of the project. At AuraQ we use the SCRUM agile methodology for our software projects. What this means for the scope of this blog is that we break up our work into timed sprints, usually two weeks, and each sprint has a broad purpose, a main feature, or list of features relating to a specific aspect of the software. As a game developer, ask yourself “what feature am I working on, and how long for?” The answer should look something like “for the next two weeks I will be building up the inventory system”, and stick to it. The soft deadline gives you an idea of where the project will be in that time and gives you milestones to work at. These milestones will also give you a much better sense of the progress your project is making.
2. Define specific requirements and use cases
As mentioned above, I would write a brief description of the game before starting coding, and this would be the closest thing to ‘requirements’ I had. I would have something slightly more specific in my head, but it was always vague and open to interpretation. This meant that I would often have to decide while coding how something was going to work without really thinking of the bigger picture, sometimes having to stop in order to figure it out and instantly killing motivation if I didn’t come up with an answer quickly. For example, I knew I wanted an inventory system in my game, and that monsters and shopkeepers will have an inventory much like the players, but do monsters need the ability to trade? Will a shopkeeper behave like a monster when attacked, if that is the case will he drop all his wares when defeated as loot for the player? If so, do monsters and shopkeepers need to even be different class? Oh, but now I need a faction system to decide if a creature is going to attack the player or not and probably a reputation system to decide if the shopkeepers trust the player… and what about reputation between the creatures themselves?!
It can quickly spiral into an endless cycle of creating more systems to support more functionality that you didn’t plan for.
A vital part of the SCRUM methodology is writing very specific requirements called user stories. These cannot be vague or open to interpretation and must cover every aspect of the sprint. A user might have to fill in a profile page, but what does this profile page contain? Exactly what data must he or she fill in, how does the user mark that they are done? What happens when they navigate away from the page? Does an administrator need to verify the data or does it just get saved? How is the data viewed once saved? What is public information and what is just seen by the user? What validation is required on every bit of data?
The requirements need to be written in such a way that any developer can join the project, be given this list and start working away without having to question a requirement or come up with their own interpretation. Each requirement must also be weighted against the size and time it will take to complete, also giving you an idea of whether it will fit in the current sprint.
In game development, especially when you are working on your own, this will often feel like unnecessary extra work. And it is a lot of extra work as creating these requirements will take a lot of time. But this highlights the importance of designing a game before building it, and the benefits far outweigh the extra time. While it’s unlikely you will genuinely cover every possible aspect and potential question, covering as many as possible gives you a nice checklist to track your progress with. It will also give you an idea of any dependencies on other components you might have before you actually start coding and give you ample time to prepare for them. On top of all that, if you fail to keep to the time schedule set in the previous step, it’s easier to come back a week later to a very well defined list, knowing exactly where you stand. Finally, it let’s you focus on building the system/feature itself as all the decision making has already been done.
3. Use the platform’s strengths
My programming language of choice is C#. When I started working with Unity3D I treated it as little more than a level editor and 3D renderer, choosing to code practically everything myself. Why bother learning how to use shortcuts when I’m such a good C# programmer and Unity3D supports it? I wasted so many hours coding my own gravity, physics, movement system, net code etc, when the tools were available to me all along.
At AuraQ I work with the Mendix platform, a web application development tool that allows you to build logic using it’s own visual programming language (microflows) and java for more advanced features. Java is a great way to extend functionality, but is not meant to be the primary way to define logic in Mendix. Using Mendix the way it’s meant to be used results in much more easily being able to set up security, validation, the database etc.
This applies to the game engine you are using. Unity3D for example, comes with it’s own very deep physics system, and applying a rigidbody to an entity, moving it around appropriately (using add force rather than directly manipulating it’s XYZ Coordinates) will automatically handle things like friction and collision detection. Taking the time to learn what the engine can do will not only save you a lot of time in the long run but can also inspire you to add features that might have seemed too difficult or time consuming yourself.
4. Do not hesitate to use existing code
This is more of a pride issue than anything. But as a solo indie developer I wanted every bit of code to be my own. I also didn’t want my game to ‘feel’ like other peoples games so if it was a choice between coding my own inferior character controller or downloading one off of an asset store I’d always go for making my own. This was very time consuming and almost always resulted in a worse end result.
Mendix comes with a built in app store where extra functionality can be downloaded. This functionality can be created by other developers or the Mendix development team themselves. Even with a lot of the same modules being shared among different projects they are still used in such a way that each application still has its own flavour, especially after a customer’s branding has been applied.
Unity3D comes with the asset store which contains anything from custom code, to engine functionality and 3D models. Overuse of the asset store should definitely be avoided, but downloading and using someone else’s work is nothing to be ashamed of. It speeds up production and lets you focus on working on the parts of your game that make it yours, not getting bogged down in systems that have already been done for you while you just reinvent the wheel.
5. Best practise DOES apply to you
Somebody once told me that best practice is the collective experience and knowledge of generations of developers much smarter than me, distilled into a list of rules. You don’t always have to know why something is best practice, but have faith that it became such for a good reason. It’s very tempting when adding a new feature, especially if it’s a small one, to just put it together with no regards for future expandability. Besides, it’s just you working on your project right? So why worry about readability to other developers? The truth is that it doesn’t take a whole lot of effort to build things with best practice principles in mind, once you adjust to putting yourself in that mindset by default, and the benefits of doing this are completely worth the effort. Even if you don’t plan on reusing code you never know when a similar feature might be using identical logic and can adapt the code to its use. Not to mention that readability is a big part of coding, even when it’s just you. If you come back to fix or enhance the code weeks or months later, you will not remember what you were thinking when you put the code together.
At AuraQ I use best practice mainly because I work with other developers, and I need to build my code in such a way that they can take over at any point should I not be available to finish what I was working on. But other benefits include reusable, easily maintainable code that’s compatible with external add ons, or at least easy to adapt to them. The benefits in game development are pretty much exactly the same as with software development – the main issue is that it’s very easy to assume that when working alone they do not apply to you. Having seen the benefits in action on some pretty massive projects I assure you that no matter how small the project, they will always benefit you in the long run. It takes discipline and dedication to develop a game on your own. In my experience the biggest project killer for solo work is running out of motivation, and keeping up your motivation is a skill in and of itself.
These lessons should eliminate a lot of difficulties that can arise when working on a game (or any software project) alone, whether as a hobbyist side project or profession. Working up the motivation and scheduling work on a side project after a regular 9 to 5 job is another skill entirely, but that’s a topic for another time.
Related Blogs
Drag