Gettin it done

[CrowdedTrousers]

I've been reading a bit recently about game development (Sensible Software is a belter of a bio if their name means something to you) and thinking about my own project. 

I've had an idea for a while and recently stumbled on the tute written by Jotaf (missing, presumed ascended circa-2010),  I haven't really coded since Uni but I managed to quickly wrap my head around the tute and then extended the code to do the things I was interested in. As I went new things occured to me and I was throwing anything in there that I felt was cool. One of the best parts started as a mistake!  There's a lot of rabbit holes to disappear down, and it's clear I'm easily distract-

SQUIRREL!!...

Oh, I'm sorry, what were we talking about?

Anyway I've decided it's time to start again, but something that has an end in sight.  Reading Jo and friends on the Superhero RL thread suggest the benefits of having a mature vision before starting out...a design document of sorts. My organic style meant implementing ideas I had late in the process sometimes required refactoring to accommodate.  Clearly inefficient. So I'm going to do some design on paper first, and see how I go. A bit of bounded scope should also help contain my tendency to wander.

If you've 'finished' a game before, what got you there?

[Quendus]

Deadlines and planning.
Getting basic display and user interaction working ASAP.
Testing every new feature as it's added so that I don't have to spend hours debugging it later.
Reusing old code and borrowing public domain code.
Developing during a week that's less busy.
Being ruthless and culling any planned features that aren't quick and easy to implement.
Planning to finish by the deadline, but not giving up and dropping tools the second it passes.

[guest509]

There are a few things that need to be conquered for me to finish something.

Basically I need a good game concept, a step by step plan to achieve it and enough long term motivation to achieve it.

I'm much better at short projects because of the motivation issue, I get bored quickly of long projects.

[dscreamer]

Iteration.  Realizing that even if you spend weeks agonizing over the design, it's likely to need some changes once you actually see it in action. So, pick something that sounds good and try it. Change what doesn't work and keep the awesome stuff.

Organically adding things is great, though I do try to keep a vague idea of what I want to add (and not add) in the future. When adding new stuff, try to get an idea of how much code you'd need to change. I'm willing to do some refactoring, but there are some things I won't implement - it would require changing some basic assumptions that are present throughout the entire game. If it'd require that much work, it might be better suited for another game.

And, like Jo said, believing that the end product will be worthwhile is a huge boost.

[Trystan]

Focus on doing one small task at a time. If you're implementing something then implement it. Don't get side tracked by bugs or ugly code or some other cool idea. Do what you set out to do. You can do the rest later. I aim for small tasks that I can finish in an hour or so. Forward momentum is crucial.

Doing trumps talking and worrying and pontificating. It's fun to write up huge design docs, day dream about how awesome something will be, tackle performance and scaling problems before they happen, and argue over what mechanics or features or architectures are better than others. We all do it but after a point it's a waste of time and talent. Start coding. Keep coding. Solve the problems when you come across them. Share your game, code, and experiences with others.

Refactor. There's absolutely nothing inefficient about refactoring - it means you're learning new things. University projects have clear short term goals that are designed for students to meet in a short time. Real projects are nothing like that. When you've learned something new (and changing your mind counts as learning) or some code has gotten too messy (which is also learning), set aside some time later to improve your code. When I think of all the developers I've met and worked with, the great developers who get things done quickly always refactor often.

The 7DRL is coming up in a few months - I hope to see you participate!

[Quendus]

Doing trumps talking and worrying and pontificating. It's fun to write up huge design docs, day dream about how awesome something will be, tackle performance and scaling problems before they happen, and argue over what mechanics or features or architectures are better than others. We all do it but after a point it's a waste of time and talent. Start coding. Keep coding. Solve the problems when you come across them. Share your game, code, and experiences with others.

I think this point is what makes having a start date as important as having an end date. The start date is your deadline for all the design docs, daydreaming, worrying about scaling issues etc. It's good in moderation, but it eats into coding time. After that it's all code, and you can get a lot done in 7 days when you're not worrying about other stuff.

[guest509]

Lately I have been talking and reading about designing and not making anything.

It's an easy pitfall.

[Krice]

The problem with design and planning is that it also can be wrong. You simply need experience from real life programming to find out what happens. However I think there is one really good way to improve planning and it's placing features in todo list by how important they are. When you add a feature it can often require refactoring of engine and usually more important/bigger features require more refactoring, in which case it's easier to program them first and add minor features later. The dialog between the engine and features is the difficult part, especially in later stages when you suddenly realize you need a major rewrite of the engine (for some feature) which can change a lot of other things you thought were ready.

[Vanguard]

I once read that Sid Meier (the Civilization dude) has a policy where if a value needs to be changed while developing a game, it should be either doubled or cut in half.  If a character is too weak, try doubling their attack power or halving their cost.  If a game lasts too long, cut the victory requirements or map size in half.  It's a great rule for quickly establishing where your game is, where it could potentially be, and how far it is from where it needs to be.  It also makes it easy to tell exactly how your change affects the rest of the game.  It can be hard to tell with little +/- 5% changes.

I have a bad habit of making tons of very minor changes over a long period of time, so for me, the double or half rule saves a lot of time.  Maybe it'll help you too.

[tuturto]

Writing the best possible code is sure way of not getting it done 

You'll learn a lot while you work on your program and especially if you happen to read a book or two in the process. Wanting to return to old code and polish it up to level of your new skills will mean that you'll revisit same code over and over again. Sometimes changes are small, sometimes you chuck out whole modules and program them "this time, correctly". Some amount of reworking is to be expected, but reworking alone will not get the code finished.

I speak from experience of not finishing (but the code is pretty, just like a delicate flower).

[TheCreator]

I speak from experience of not finishing (but the code is pretty, just like a delicate flower).

This might indicate that code is not that important, I would say.

[tuturto]

I speak from experience of not finishing (but the code is pretty, just like a delicate flower).

This might indicate that code is not that important, I would say.

If the goal is to get it done, code is secondary. While clean code makes programming faster, shortcuts can be taken and messy hacks can be justified. It's just a blueprint for a running software after all. If the goal is to have fun and enjoy the programming, then clean code starts to be much more important. If the goal is to learn more about programming, then code is even more important. It just all depends on the goal.

[TheCreator]

If the goal is to have fun and enjoy the programming, then clean code starts to be much more important. If the goal is to learn more about programming, then code is even more important. It just all depends on the goal.

If you have any project that has such goal please let me know so I don't waste time trying it out .

[Pickledtezcat]

I usually do a project in stages with each stage ending with a playable "game" that could be considered finished. Maybe just kill one enemy or pick up 8 apples in a minute. Then I add more features an go on to the next stage.
the benefit of the game being ki.d of finished at each stage is that you can attract playtesters to test the game. Also if you ever give up on the project you can consider it finished but with room for emprovement.

[Krice]

If the goal is to get it done, code is secondary.

I think somehow code quality is important in roguelikes, because the size thing. When the source code is getting big it's becoming increasingly harder to maintain. This is where modular design and good programming practices start to show their value. However equally important is to let go of the idea that it's possible to write "perfect" code or engine. No such thing exists, everything can always be improved from what it was.