next »

[Christian Knudsen]

Hmmm, I've never had much trouble rolling back to an earlier version with Dropbox. Being able to add comments and see differences definitely sounds nice, though.

[Moczan]

Hmmm, I've never had much trouble rolling back to an earlier version with Dropbox. Being able to add comments and see differences definitely sounds nice, though.

My main problem with it is actually finding the right version to roll back. It's easy when you want to roll back to version of one file from 5 minutes, but if you ctrl+s all the time like me, getting few files to version from few days will be pain in ass, cause (unless it was changed) Dropbox lacks a good interface for checking out versions.
Also with DVCS you can easily clone, merge and branch your code, which is not something you do often as a solo developer, but if the time comes, it makes everything easy. AND it let's you integrate with bug tracker/to-do lists and all that stuff, which was the main feature discussed here.

[RudyTheDev]

... how often do you commit and push changes ...

Every day (that changed anything) with a brief summary of what was done. The repository itself is also in the Dropbox folder.

[nikwing]

I don't know if this question is OOT but i forgot to add in in the original post.

How you guys decide when to ship the game? and avoiding feature creep?

thank you

[VDZ]

As for versioning, I just number the builds released to anybody not directly involved in creating the code sequentially - version 1, version 2, version 3, etc. At least that way the order of releases is perfectly clear.

Version control: I commit whenever I make a major change and everything works again (code compiles, feature that was just added works properly), and at the end of the day if I have any uncommitted changes.

I like to use version control (SVN is my version control system of choice) even when working solo because it allows me to charge right ahead and implement something hard to undo that might mess up the entire thing, because I can just right-click and select 'revert' if it ends up not working. It also allows me to read deleted and replaced code, which can be useful for finding bugs (bug X appears after you changed Y, what was it like before?) among other things.

[James Coote]

and avoiding feature creep?

Don't write expandable code. If you catch yourself with generics and templates and object oriented hierarchies far larger than is really needed, you are subconsciously thinking about all the great features you could add in later using them. Also, by doing that, you're actually wasting time making overly complex structures that are harder to maintain.

[ColeyWoley]

I've spent my career working on license titles that no-one really cared about, so long as they had something to put in the box, so I was determined not to release until we felt good about the game.

That said, the financial pressure is pretty high, and if you work on it until the sight of it makes you want to threw up, its quite hard to put your heart into marketing the thing.

btw I really like your blog Chris.  Thanks.

[Chris Koźmik]

Don't write expandable code. If you catch yourself with generics and templates and object oriented hierarchies far larger than is really needed, you are subconsciously thinking about all the great features you could add in later using them. Also, by doing that, you're actually wasting time making overly complex structures that are harder to maintain.

Yes, yes, yes. I could not agree more.

Plus, after a while you *always* learn your previous template was not optimal and you could do it better now so you want to recode the template in your next project as well, which defeats the original purpose of generic templates

[RudyTheDev]

Don't write expandable code.

This should be stamped on a wall. Hardcode stuff unless you are actually planning on expanding. And by planning I mean "this was designed and decided before code started happening".

[bateleur]

Hmm... can't say I agree, personally.

I prefer all my code to be modular, expandable and as reusable as possible. That way it's much easier to modify the game in the light of playtesting. This is, after all, the way to make good games - get something working and then iteratively change and improve things.

If you ever catch yourself making game design decisions based on the capabilities of your code you should stop and think about whether or not those code limitations could have been avoided with a more flexible code architecture.