What kind of project management should a solo developer project use?

Question

I’m working by myself on a game project whose development could be separated into 3 independent parts (map generation, the “overworld” engine, and the battle engine), but as the development progresses, I am not sure how I should be dealing with the management of this project, especially concerning these 3 points:

1. Is it worth using a version control system, since I’m working solo?

2. Should I use a formal method to register planned features / bugs (I just remember what needs to be done for now)?

3. The most important question: How can I know what to develop first? Now that the very basics are done, I know the list of features to code, but I don’t know in which order I should do it.

Answer 1

I would use:

1. Code management

GIT (and the awesome reference), a distributed source code manager, for managing my code, and host it on GitHub as a private project if I want to keep it off limits.

(There are A LOT of options here, just google for source code management, you don't even NEED to use GitHub or any other website, Git will work just fine on your local computer, but using GitHub will make the pain of managing backups a lot easier.

If you have two computers you can create a repository on one that you'll call your backup machine, then you clone that repository over the local network and use it for development, when you're done with a feature you can push it to the backup machine and you'll have a 1:1 backup!)

2. Issue & Feature management

I would use Trello or GitHub's built-in issue management to keep track of bugs and things to do.

3. Have a Design Process

I would design my game first;

1. first in my mind,
2. then on paper,
3. then probably use GameMaker or PyGame to prototype my idea, and iterate over 1-3 until I have something that I enjoy playing.

4. Use my Prototype as a Guide and Develop my Game

Then I would put my prototype aside and pick a platform I wish to develop for. Then look for existing engines and pick the one that's the best fit for my game idea. Then I would make clear goals for my project, structure them into small tasks and then begin working to finish the tasks. When you've reached this state, you'll most likely find that you have your own way of working that suits you the best, so go with that!

There are several different methodologies/philosophies that you can apply on your development style, XP, Waterfall, etc. Just go with the one you feel makes you progress the fastest.

5. Have a lot of Game Testers!

When you have something playable, ask your immediate friends to try it out! Make it easy for them to help you by setting up quick installer packages if they're running Windows or write some shell script that can automate the process for them if they're using Linux/Mac. Take much care in the feedback of your testers, and don't forget to inform them about your game design and what kind of game it is you're trying to build.

6. Make a website for my game

As soon as I have something going well I would probably make a website for my game - to keep my creativity and content flowing when it can't be applied to the progress of my game, for instance, if I'm focusing on my studies or need a break from development!

If I use GitHub, I would set up a project page for my game, otherwise host a WordPress/Jekyll blog or something similar and write my posts with that.

This will keep yourself motivated as well as having a place to refer potential gamers/testers to!

7. Join contests

There are lots of game dev contests going on almost all the time. I would try to join one of these with my game if the rules permit. This increases motivation and makes everything even more fun - who doesn't like winning!

(If you are developing under a strict deadline, you can skip this point at least.)

Answer 2

I would strongly suggest using a version control system, even if you work alone. It can save you a lot of time, once you accidentally delete something or make a bigger change, only to realize later it was a bad idea and you have to undo al the changes.

Edit: There are many free source control solutions.

• I have used the VisualSVN Server, which is easy to set up and use under Windows.

• There also are online alternatives like GitHub, SourceForge or Google Code. The upside is you don't have to set up and maintain a repository and your data is in the cloud; the catch is, you can't freely host closed-source projects.

As for bug and feature tracking: If you already have a larger audience that might be interested in beta-testing your game, reporting bugs and requesting features, go ahead.
If, however, there is only a handful of such people (or none at all), it's unnecessary.

And as for development priorities - that's for you to decide. Who should know better what to do in a project than its only developer?

Answer 3

Is it worth it using a version control system, since I’m working solo?

I think so. Its pretty trivial to set up and I've had multiple times I've gone crazy with the refactoring or done something else stupid and the ability to rollback my changes has saved e tons of time. Plus if its hosted on a server then you have a backup of our code in case anything goes wrong.

Should I use a formal method to register planned features / bugs (I just remember what needs to be done for now)

I don't think its necessary. I would keep a written list of what you intend to do though just to make sure you don't forget a minor bug, plus I find it helps you get started again after taking a break from coding.

The most important question: how can I know what to develop first? Now that the very basics are done, I know the list of features to code but I don’t know in which order I should do it.

Take that list above, close your eyes, and randomly poke it. Work on whatever feature you finger is on. Unless items depend on each other its more important just to keep the flow going than making sure things happen in any particular order.

Answer 4

Definitely use version control

Version control is like a safety net for a tightrope walker: it frees you up to attempt crazy things. A big refactor deleting huge chunks of code is no problem if you can easily revert. It's even less so if you're on an experimental branch in your repo and can decide not to merge it back in.

If you don't have this kind of freedom, you're likely to leave commented-out code sitting around everywhere for fear that you might need it.

I'd put in a vote for Git. The syntax is a bit odd, but two great things about it are:

• Low overhead. Change into a folder and type git init and you're ready to start checking stuff in. If you decide you don't want to version control it after all, rm -rf .git in that folder and it's not a Git repo anymore.

• Distributed via SSH. Git is distributed, meaning you can have multiple full copies of your repo (all the history, etc) in various places, and keep them in sync. You can set up another Git repo on any machine where you have SSH access, then add that other repo as a remote. After that, anytime you want to back up just git push to that repo.

  That's a big advantage over, say, Subversion, where the whole repo lives on one machine and that machine has to be running a Subversion server.

Mercurial may have these same points in its favor, but I haven't used it.

Answer 5

1. Yes! Since you are asking I am guessing that you are well adopted with revision control system. Its a must!

2. Regarding your second question, there are formal method of registering bugs and you should use it. For planning features I think taking any less formal route wont hurt(when you are working alone)

3. Do those features first that will make your game come alive. Give a sense of how the final game play is going to be.

Answer 6

1) Yes, of course. I recommend Mercurial via BitBucket and TortoiseHg. BitBucket is free for up to 5 users and since it is hosted in cloud it adds you some piece of mind (no need for backups).

2) Bugs should be fixed before implementing new features. I would use simple accessible TODO list to track things - pending/done. You might just use a plain text file, just do not forget to add it to your source control repository.

3) Do what you want to do on any given day, while keeping in mind that delivering something playable by end-user is a primary objective. E.g. if you are tired of getting physics right, work on rendering or maybe add some missing unit tests for that AI.

Chunks of work should be small enough to be done in about a couple of days. It is crucial to keep yourself motivated and avoid burnout.

If architecture is done properly you should be able to easily add an modify parts of the engine/game without affecting multiple others (otherwise start with some refactoring :).

Answer 7

1) As everybody says: YES (I'd even say, rent a cheap online one)

2) Keep a simple list or if your project grows big and you get beta testers, install Mantis Bug Tracker

3) I don't know, but I'll tell you how I'm doing it: Develop the least interresting and/or hardest things first. Repeat until everything is done. That way development just gets funnier and easier (and you won't hit that problem you just can't solve too late if ever that would happen).

Answer 8

Thanks for asking this question. This is exactly what I am doing currently.

1) Version control: It is must. Right now, I am maintaining manual backup. It is useful atleast when something which was working great has suddenly throwing errors (or not functioning as expected). I compare versions and often find silly mistakes (mostly commenting something)

2) I created a word document and listed all the feature my game going to have in a categorical order and with multi level indents listing sub features (and client/server related or what ever is applicable).

3) After the list I got (which wont be complete usually, keeps get something added to it) I think of my game flow and hightlight all the points which are necessary for me to make the game running and start doing them. I mark yellow meaning work in progress. green when completed. orange to indicate tobe improved or has some known bugs

hope this helps

Answer 9

1.) It is worth using version control for any project. Even very small ones if you already know how to use one. I have used Subversion for years on Linux and Windows with TortoiseSVN. Even when making a small (<500 line) project I'll create a repository for it so I can undo changes, track what I was doing if I abandon the project for a while, etc.

2.) Depends on how large the project is going to be. If you're planning to play-test with a team and distribute, it is probably worth having a bug tracking system. I'm currently working solo (although I have an artist) on a project that is over 20k lines, and I just keep my to-do list in a text file that is also in my SVN repository. Although I don't exactly have a need to share it with others just yet, so not having bug tracking fits my needs for now. I wouldn't worry about it until there is a need. The worst that can happen is you'll have to enter whatever bugs you've already written down and remove/revise the ones you fixed. When you start losing mental track of your notes, get a bug tracker.

3.) Plot it out on paper. Start with what you want your finished game to be, write down the gist of it. Then break it down into what it will take to make it: collision detection? network code? types of players and monsters? class hierarchies? Work backward from your vision so that you get a clear idea of how to build it from the ground up. I presume you're using an object oriented language. The most crucial step in starting off would be getting those class hierarchies set up in a sensible way. Try your damnedest to have absolutely no multiple inheritance (although sometimes it's unavoidable), plot out the class relationships in a diagram editor (I use Dia), etc. Basic principals go a long way in avoiding headaches later.