Jump to content
  • Advertisement
Sign in to follow this  
archnem

OK, I've got a game, now what?

This topic is 3498 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all, Without getting too much into the details, I've just recently completed my first version of an XNA game I've been working on for the last couple of days. The result? An ugly-ass pile of code. I've extended MS's examples in weird ways, I've brute-forced some algorithms, I've been more worried about production than adequate commenting...you know...coding. :) Here's my question. It may be an ugly-ass pile of code, but it WORKS. The game works perfectly (for the current version anyway - more features are to be added). All the game rules are being obeyed. But the code itself really could use a good rewrite/reorganization. I'm afraid to monkey with it too much tho, as I don't want to break a working game. How do you pros deal with this type of issue? Just deal with it and keep implementing? Or take the time and effort and do things well? Thanks :)

Share this post


Link to post
Share on other sites
Advertisement
If you're worried about breaking things, make a backup before you change them. In fact, make a backup anyway. Go on. We'll wait. :)

Generally, if you don't like your code, it's a sign it should be cleaned up. You should only ever "just deal with it" if the costs of refactoring and cleaning up the code outweigh the benefits of working with a cleaner codebase. You generally only reach that stage with products that have been worked on for several years by dozens of developers, though, so I definitely recommend taking the time now to clean up what you've made. If you wrote it in just a few days, it can't be too big, so it should be straightforward to break out its components into separate modules and get some comments in there. You'll probably find some lurking bugs as you go.

Share this post


Link to post
Share on other sites
It's called version control and it makes you fear less.

Perforce is my favorite and is extremely expensive, but it has a free license for two developers, so you can experience how source control works with a "team" for free.

Imagine if you and another person were working on your extremely brittle code :P you would not be able to sleep at night with out version control.

Deleted something yesterday and realized you need it today? View yesterday morning's revision, copy the bit you need, paste it in todays revision and you're back in the game.

A popular free alternative is CVS, it's all command line so it can either be very difficult or very easy for the user depending on their background. There're also plenty of graphical interfaces for CVS, one popular one is Tortoise. I guess that works with SVN as well.

If your project is open source, SourceForge.net can host your SVN or CVS repository for you. Then you, or anyone to whom you gave the creditials, could access it from anywhere.

Basically, you have no excuse but to continue working on it, if you stop, you've given up. So if you dont give up, get version control, make it dope, and send me a copy.

edit: Alternate suggestion:
Say you have source control and i just babbled for nothing. You just need to put your balls in the grinder man. Most times you'll just make a note to yourself, "this sucks i should change it, maybe later." No! depth first. no looking back, f that trash, worse case you waste a whole day, best case your broken program is less broken.

This works best between the time you wake up, and the time you eat "lunch." Get out of bed, put on some music, and fix it. Download visual assist for a free month trial. It has a couple features that are pretty nice, others take a while to get used to but eventually become nice. Here's a free extension for Visual Studio which is supposed to do smart refactoring: :Refactor!

Third suggestion:
If you waste two consecutive days, and your brain is mush. Click new project and start over, dont use an example, write your own framework.

Share this post


Link to post
Share on other sites
As a general rule, if I'm not happy with my code I'll try to refactor it as soon as possible. The more you build on top of ugly code the harder it will be to maintain, extend, and find bugs.

When coding a specific module I will generally allow myself a little bit of sloppiness to "just get it working". Then refactor it until it can be considered good code (to me).

An even better method is to be very careful and never write sloppy code. This requires a lot of skills and patience that I don't have.

Share this post


Link to post
Share on other sites
The real solution to this problem is Test Driven Development. Learn to love your unit tests.

Version control and working backups are wonderful, and an absolute necessity to a live environment. But, without unit tests, even refactoring the most beautifully written code will be a nightmare of unintended consequences rearing their head with each compile.

Start writing comprehensive unit tests as you code and you'll never worry about refactoring spaghetti code ever again.

qed

Share this post


Link to post
Share on other sites
Quote:
Original post by c_olin
As a general rule, if I'm not happy with my code I'll try to refactor it as soon as possible. The more you build on top of ugly code the harder it will be to maintain, extend, and find bugs.

When coding a specific module I will generally allow myself a little bit of sloppiness to "just get it working". Then refactor it until it can be considered good code (to me).

An even better method is to be very careful and never write sloppy code. This requires a lot of skills and patience that I don't have.


Sounds about how I like to handle things. Right now I'm in a game development course at my college, and time is running out and that means that crunch mode is making me throw stuff together instead of working hard to make it look nice and be extensible. The end result though is code that works within the limits of what I am able to do. If I had time, I'd probably make it cleaner, but it's mostly ok.

There is definitely such a thing as overdoing it. Generally if you leave code alone for a few months and come back, you'll find some excuse to rewrite part of it. You can repeat that almost to infinity, you'll always find something else you could have done better, or a way to make it more extensible. Sometimes it's best to get the quality of the code to good, but not obsess over it.

In your case I'm not sure what to say, it's going to depend on a few things. How far do you intend to take the game code? Do you want to make it a much larger game? Do you want to reuse parts of its code? If either of those is true, then it is probably a good idea to refactor the code. Probably more than less. It will become a pain to figure out what the heck parts of your code are doing in two months when you've got to add a feature that depends on 10 others with few comments and unintelligible structure.

On the other hand, if you only want to get the game working and learn from it, then it's probably ok to just make it work. Based on your experiences with this one you'll know better how to make a game next time and can spend a little more time getting the code structure right. Every game I've written to date has been superior to the one before it in code quality, save perhaps this one once crunch time hit. That's subjective of course, but either way you'll be better off trying to get the design right if you know more.

Share this post


Link to post
Share on other sites
In reality, the end user doesn't care how a program is coded.

So, if your program is at a working level that both you and the end user are happy with, then why mess with it?

You can spend a lifetime refactoring and tweaking. You have to balance this with 'will the user care'?

If it works, why fix it? :)

Share this post


Link to post
Share on other sites
Because refactoring is something you should practice, and better yet, get in the habit of doing alongside your coding. Ugly unamanageble code that's gotten to the point you're afraid to work on it because it might break the whole fragile pile is really useless. You may think you have a good end product now but you're now in big trouble if there is a bug found, if you want to reuse some of the code, if you want to add to it later or even if you just come back in months to try and figure out how you did something from before.

Programming isn't just about putting together code that can work.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!