The Moosader Community

Visit the IRC at #Moosader! Community dedicated to programming and game development!
It is currently Mon Feb 24, 2020 1:00 pm

All times are UTC - 6 hours [ DST ]

Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: Project Management
PostPosted: Tue Jun 05, 2012 2:55 pm 
Site Admin
User avatar

Joined: Wed May 14, 2008 4:43 am
Posts: 2328
Location: Kansas City
Does anyone feel like it'd be helpful to talk about Project Management and the Software Development Lifecycle before the competition?

It might be handy to discuss iterative development, and trying to work in a way that you will get at least a baseline of features done quickly and within the time frame, even if the final product isn't what you had originally imagined.

Additionally, the virtues of not over-designing. :)

Android apps by Moosader! - Open Source projects -

 Post subject: Re: Project Management
PostPosted: Tue Jun 05, 2012 10:48 pm 
Smushed Goomba
Smushed Goomba
User avatar

Joined: Fri Feb 24, 2012 7:47 am
Posts: 11
Location: Dominican Republic
Yes, please and thank you ^_^

Boom goes the dynamite...

 Post subject: Re: Project Management
PostPosted: Wed Jun 06, 2012 4:56 pm 

Joined: Tue Apr 10, 2012 6:07 am
Posts: 41

 Post subject: Re: Project Management
PostPosted: Wed Jun 06, 2012 5:17 pm 
Rather Dashing
Rather Dashing
User avatar

Joined: Sat Feb 06, 2010 5:06 am
Posts: 378
Location: Australia
Yes, this would be a great idea. I usually write two lists with a few headings:

* Necessary
* Expected
* Hoped for

* Preproduction
* Prototyping
* Alpha
* Beta
* Release 1.0
* Release 2.0

That's just my brain dump though.

My blog:

 Post subject: Re: Project Management
PostPosted: Wed Jun 06, 2012 7:23 pm 
Site Admin
User avatar

Joined: Wed May 14, 2008 4:43 am
Posts: 2328
Location: Kansas City
In my own words... (I'll try to find some articles later)

ONE: Use Version Control
What is Version Control (Source Control)?
Use version control. If you don't know what that is, read about it.

Have you ever lost work? Have you ever made a bunch of changes which totally don't work, and you want to go back and try again from an earlier version? Do you ever work with other people on projects? Do you ever lose your code long after a project is done? Ever work from more than one computer and have to transport your code?

Using version control allows you to commit your changes to a repository, and pull those changes back out. You can make a branch as you work on a big new feature without messing with the core project code that already works- just merge when you're done.
Two developers can have the code on their computer locally and merge and push to a repo after they're done with their respective areas.

Plus, there are a lot of tools out there to help you view, check differences between files, and manage your projects, and they go along with source control solutions.

You can view a list of all your previous commits, so you can track down a feature much easier.
You can view changes between two files made by you or another user
You can make a branch as you do a major change, so you can keep committing comfortably to back up your work, and then merge the changes back when you're done with the feature.

Source Control options
So sounds good, what do you use?
Each of these have GUI versions ("TortoiseSVN", "TortoiseHg", and "TortoiseGit" are most common on Windows) and a command-line interface (ala, runs in DOS or the Terminal).

Well, if you're new, you might start with SVN. It's generally considered the easiest of the three main version control systems.
I also consider Mercurial pretty easy, and it has more advantages, so you might read about the difference.
Git is closer in similarity to Mercurial than SVN, but is a bit more complex.

Visual Studio also has its own source control called TFS (Team Foundation Solution), but I generally consider Mercurial and git to be way better.

Where does my source go?
You have the option to host your source locally (it's not hard to set up an SVN or Mercurial server locally), or you can set up a repo online, with a few free options.

If you want to host online and want your source code to be private, BitBucket gives students unlimited free hosting. Also, if you have a team of 5 or less people, they will also give you free private hosting.

If you're into OpenSource, a lot of sites will let you host your OpenSource projects totally for free. Some choices are:

GitHub is pretty much just for Git, but others will host other types of repos and alleviate any difficulty with setting up your project.
Also usually these hosts have ways for you to log issues, to help you with project management.

TWO: Develop in Iterations
Waterfall is an awful design methology.

Also, I dislike the idea of completely and wholly documenting every aspect of a software project before coding anything. I think that's really unrealistic. Document and design, but...

Work iteratively.

Read up on iterative & agile development and scrum. You don't have to follow one thing or another, but pick up a few things here and there. At Perceptive, we use agile scrum, and I love it.

The core idea is to work iteratively: At the end of each iteration, everything should be building, and you should have a relatively complete game. Maybe it doesn't have all the features. Maybe you can only walk around and pick up coins, but you have a game.
Rawr's first Iteration Plan

You can set yourself some deadlines, but this is a hobby, so don't be overly zealous. I miss all my self-imposed deadlines. :)

Additionally, limit the scope of your project. Figure out what is the core part of your game, what is absolutely required. Once that core is done, spread out nice-to-have features across other iterations.

THREE: Use tools to track progress
If you're using something ilke GitHub or Google Code, they will have some free ways for you to manage your projects. Both have Wikis and both have Issue tracking (I use the issue tracking just as a general feature-and-bug log). If you come across any bugs but don't feel like fixing 'em right away, log 'em.
Set up issues in your project to document what needs to be done, and what is done.

It gives you an easy list to check whenever you can't remember what needs to be done (or don't feel up to doing the next big feature, and want to tackle something smaller). It also gives other people ways to report bugs. You don't have to fix them right away, but you have a log of what has been found.

If you aren't using project hosting that has project management, keep some Google Docs, or throw some LibreOffice documents in your Dropbox.

It also helps being able to visually see what your "% completed" is.

You can even set up Excel or Google Docs to take tasks marked as "1" and set up a graph to show your progress.

Watching your project gain "Levels" gives you a bit of the same feeling as gaining exp in an RPG. It's just another small way to stay motivated.

Also, give some time to bug fixing, play testing, and just general refinement and polish!

FOUR: Design ahead of time
While you can't design every aspect of your game ahead of time, most of the time, you can definitely flesh out your ideas for gameplay elements, settings, characters, items, spells, and such.
Make sure to prioritize which features make up the core game and what is nice-to-have. Split these into several iterations.

Keep It Simple. Your game can be really basic at first, but there's always room to add on to it later.

Think of how your code will be structured ahead of time. Give yourself a roadmap to follow, rather than trying to grind it out with no forethought.

FIVE: Refactor any time you smell something
Refactoring refers to reorganizing and recoding, but the end result having absolutely no changes from an input or output perspective; the inner workings may change, but what the users (or programmer using your api) sees, everything is the same.

As you program more and more, you begin to gain a knack for sensing "bad smells", as they're called. Things in code that don't feel right, whether you can explain it or not. Sometimes it's functions that are too long, or passing around a parameter way too many times, etc.

Early on in the competition, you'll have extra time. When stuff starts feeling icky, take a few hours- or a day- to sort out your technical debt

SIX: Use placeholder assets
It is too easy to get hung up on trying to make your game look good, it can get in the way of actually finishing the game.
Maybe getting the graphics causes some form of burnout, or you're just thoroughly distracted. Try to ward this off as much as possible.
Use placeholder assets until the end.
If you're waiting on an artist to make your stuff, don't let it stop development. Draw some rough tiles or badly animated and keep going.

SEVEN: Keep us updated
Keep your project thread up-to-date! The hype that builds during the competition is a lot of fun!

Post YouTube development logs!
Post screenshots!

We care a lot more if there's something to look at. :)

EIGHT: Stay updated on other peoples' entries
Check out other peoples' threads! Make little comments on what you think of their project so far! Get excited!

Android apps by Moosader! - Open Source projects -

 Post subject: Re: Project Management
PostPosted: Tue May 07, 2019 6:25 am 

Joined: Wed Mar 13, 2019 4:37 am
Posts: 28392

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 6 hours [ DST ]

Who is online

Users browsing this forum: No registered users and 0 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: