Questions About Preparing to Write Code

Feb 28, 2013

Today’s entry is in response to questions I received from a student preparing a short speech about small-scale coding practices.

Q: What is the first thing you do when beginning a new project?

Assuming this refers to beginning the code part of the project, as opposed to the path from having no idea of what I want to do leading to starting to code (which is a different discussion, and one about design, innovation, exploratory preproduction and such), I usually begin by figuring out:

  1. What programming language or platform would it make the most sense to release this on? Which will reach the quantity and type of players I’d like to reach, with minimum inconvenience to them, and/or which will be fastest/simplest for me to develop the project in at a good level of performance?
  2. Do I have another project I’ve done before using this language, library, and/or platform that has enough in common in its core functionality that I could save time by duplicating that project, trimming it down to the core essentials, then building it up from there?
  3. Assuming it’s programming to create a graphical program, which is typically the case for me, I figure out where will everything go on the screen, in terms of scale, format, and layout of information presented. I usually work through this by doing an at-size mock-up in Photoshop of what a screenshot might look like later in development.

Q:What methods do you use to come up with your solutions/algorithms?

I take a tiered approach, depending on the circumstances:

  1. Is it simple, straightforward, or infrequent enough that I can quickly and easily write unimpressive though easily understood code to get it done? If so, that’s often preferable, as it avoids tying up too much time on something which may have no impact on performance (avoiding premature optimization), and may not even wind up being kept in the game (part of building to explore the overall composition of what I’m building). If it seems impractical performance-wise to do that, for example when I’m noticing slowdown because collision detection code at first was checking every object against every other object…
  2. I look up how others have addressed this issue: is there a known solution to this pattern or situation? In many, many cases, someone else has tackled a problem of this sort before, smart people building upon the work of other smart people. In the case of collision detection optimization there are many algorithms and implementations out there, and I’ll often try to see if I can find one that makes sense for what I’m doing (quad trees, for a generic example) then root around for an existing write up or pseudo code to use as an example or guide to integrate that approach for my situation. Even if it’s something that I probably could figure out how to do on my own beginning from the basic idea, there may be common implementation pitfalls to avoid, edge cases to account for that I might not have identified, or other benefits to working on it based on an outside source.
  3. If it looks like I may need to be clever and invent (or just reinvent without realizing it, because I can’t from a practical amount of effort and time manage to find or make sense of what others did for similar situations) a new solution, then I think through (yet another list – my last for this reply!):
    • What’s the minimum amount of information that needs to be considered to determine the result needed?
    • Is there any needless redundancy in what’s being evaluated, and/or are there ways to group evaluation into chunks, where for example a periodically intensive algorithm could eliminate many more frequent checks between updates?
    • Are there ways I can avoid allocation/deallocation of memory while this process is going on, to avoid performance hit from that overhead?
    • Lastly, if I’m getting desperate for ways to improve it or if it’s something that really gets called a ton of times very frequently and is still posing an issue to performance, I’ll begin to focus on really low-level optimization considerations like arrangement of variables in memory to benefit from caching, whether function call overhead is adding up for some reason, whether there’s some way a very core part could be redone in assembly, etc. These are last resorts for the most part though, and in many cases I’d sooner “design around the problem” (cut/rethink the feature) than lose too much time on a wild goose chase trying to get a computer to do in sufficiently quick time something that it may not be able to do well enough to keep in the project anyhow. When doing this type of optimization it’s really helpful to have benchmarking, framerate, or other processing time measurement means to diagnose where the issue is coming from and whether attempted solutions are making any difference.

Q: What is the best way to keep track of all of the plans and notes for a new project?

For a solo project: I keep things simple. Usually I’ve got a plain-text file that I jot notes in, and bubble to the top things I mean to do sooner rather than later. The lower something falls on the list, the less worried I am about remembering it, as it couldn’t have been too important if it sunk too far. If I have an idea about the project randomly during the day I’ll promptly e-mail myself a reminder of the thought, then about once a week I go through any e-mails I’ve sent myself to see whether anything said in them still seems sound. If so, I transfer those points to my text file.

I’ve tried other project management software, generally it seems to me like needless overhead for a solo project, tending to get in the way more than it helps.

If it’s a group project: Trello boards work well, otherwise on a very small team a simple Google Doc (or Google Drive folder with several Google Docs) might be sufficient.

Q: What are some key details to be aware of and plan for?

If it’s a creative project (ex. a videogame) direction is likely to change throughout development, and sometimes that will mean tearing down or throwing out or rethinking something that previously seemed done. Don’t sweat it, accept that some things can’t be known until tried, and when what’s being built is known to potentially be an exploration that won’t stay, don’t burn too much time or effort getting it stood up just well enough to determine whether it’s worth keeping.

On a related note: spend some time refactoring, but don’t get lost in it. Once code’s functionality has more or less settled and stopped evolving, go through it to clean up variable or function names to reflect their current usage, add some brief comments in the code where needed, and order things in a way that makes some sort of sense. It can seem silly to spend time fixing code to do the same thing, but not doing that can become a big problem later in a medium to large project. But don’t get so caught up in writing pretty code that you lose track of the fact that your real deliverable is (usually) a compiled program, in which the customer’s main concern is does it work, does it work well, is it (virtually) bug-free, did it become available on time (or at all on their platform of choice), and does it have all the features they wanted.

When something comes up that blocks progress, it can take time or daylight to figure things out or reach and hear back from folks that might be a©ble to help. Anticipate that and always plan for a bit of turnaround time to dig or wait to hear back in case something goes wrong.

Expect to lose data at any moment. Try to never be in a position to lose more than a full day of work in the event of an arbitrarily epic disaster – hard drive failure, home burglary, fire damage, mugging, etc. Regularly keep remote backups of anything you’d be really set back from losing. Avoiding working on a file that is the only recent copy of that file, so that if you overwrite it with an incorrect or blank version you’ll be able to undo the damage (obviously source control is a good answer for this – I’ve been using Assembla and GitHub recently for several team projects).

Q: What kind of revisions, or final checks, if any, do you perform before you start coding?

Specifically for the contexts in which I do most of my programming – creative projects, small team or solo projects, minimal or no financial investment, minimal or no more senior programmers or supervisors to please, writing code to test out ideas that may get torn right back down – I don’t actually spend much time on being very careful to plan before coding, I start writing code, but with the expectation that it’ll get chopped up soon, rearranged a bit, refactored in the process as I become more clear about what I’m liking or keeping, and so on. In those specific types of situations I’m cautious about the dangers of overplanning, overengineering, putting too much faith in someone’s ability to understand how something will feel in play before trying it (“the brain is not an emulator” being one of my oft-repeated arguments), procrastination by over preparation, and so on.

That said, I’m not writing high security banking software, telecommunications code, military tracking systems, or other really intense applications of those sorts where the target requirements are much more firmly understood and inflexible from the outside, and for which the stakes of performance and reliability are completely dissimilar. Any approach to software development is going to have some pros and cons, and in my context I find the benefits to this adaptive, highly iterative approach tend to outweigh the downsides, but it’s definitely not the best way to necessarily deal with other types software challenges.

For a medium-size team project, final checks would be in making sure that there are pretty clearly defined interfaces between the work being done by different people, or ideally, already placeholder functions being called for any code yet to the written, so that there’s no ambiguity in spec over what parameters they’re getting, where it’s being called from the code that isn’t theirs, etc.

Good luck with the speech!

Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.

Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!

All contents Copyright ©2017 Chris DeLeon.

Site production by Ryan Burrell.