Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[sjm9876]

I find sorting the flow of the code on paper actually works really well. I mean, the more complex the game gets the more messy the flowchart becomes, but it still serves the purpose.

As for the actual topic, try to keep the project workable as often as possible - whilst the urge to add an entire attack system can be there, it's generally a worse idea than setting up a single attack with set values, then testing, then taking variables into account. (Whilst that's a poor example, my sleep addled brain can't come up with a decent one.) But anyway, not only does it keep motivation,  it also helps with code busting.

Also, try to keep the project as modular as possible, so that if you get tired of working in one area, you can swap to another without everything being horribly broken. Keep a functioning backup at all times, so that if your changes render it unplayable, you can stop messing with them and move back to something different to solve the problems later.

Another thing, especially with things like roguelikes, is to try and externalize things - look at DF's raws for example. (Disclaimer, I have no idea how to do this.) It cuts down the workload for adding content, and allows you to focus on the core code.

Anyway, otherwise I second Sappho's advice. It's all good and sound.

[HideousBeing]

Another thing, especially with things like roguelikes, is to try and externalize things - look at DF's raws for example. (Disclaimer, I have no idea how to do this.) It cuts down the workload for adding content, and allows you to focus on the core code.

This is far beyond what a small project needs (until later, when you decide the project is actually a good idea to invest in long-term), but... I can explain how to go about this!

This goes along the lines of parsing and to some extent, language design (but you won't be building a compiler or anything). There are plenty of ways to do this (look up grammars); XML (probably your best bet), databases or simply build a simple language. Theres also a rather good reason a LUA interface is tied to many game engines -- it's simply easier/faster to deal with when things are abstracted out. I'm going to restate though: don't do this yet. It's simply too much to start with and your project will fall apart.

As for coding on paper... ewwwwww. Datastructures and general flow and design are useful to put on paper. Code itself? No. Just because somebody (insane IMO) thought it was a good idea for people to code on a whiteboard on interviews doesn't mean it's a good idea. My reasoning? I can code ideas about as fast as I can come up with them, but paper is slow. The best argument I can imagine is to force smaller snippets so people don't get all willy-nilly and have functions with 1000 lines in them (never do this unless you have a good reason and if you aren't in the optimization community you probably don't).

[MaximumZero]

I once asked Howard Tayler (author of Schlock Mercenary, which has updated every single day for something like the last 14 years,) essentially the same thing. His response: "The same way you eat an elephant. You have to do it one bite at a time." It may take a long time, and it will be overwhelming, and there will be some bits you don't like, but hang in there and slog every day and you'll get it done faster than you can imagine.