How about try something that really different, like Entity System? I read about it and now I adopt it (but without any lib, just take the approach).
I can’t find much documentation, you seem to refer to this http://entity-systems.wikidot.com/start ? I’ve seen games being built with component-message-passing designs, but they come with their own problems.
STOP!
Software engineer techniques are for long-lived projects. Programming done for learning are one-shot. Game programs are one-shot. Neither have anything in common write long-lived projects.
Mathematics, pure & applied can only really be learned by getting off your ass and working problems. Physics, engineering, among many other fields, including computer science, are nothing more than applied mathematics. Mathematics is more of an art-form than most hacks want to admit. So you want to write clean-ish programs…write programs. I say clean-ish, because if it’s really “clean”, then there’s a very good chance you wasted too much time working on it.
Sure there are ideas from “good practices” worth reviewing, but you really need to make a bunch of bad-calls before you’ll be able to filter good ideas from the bad. And in some cases what’s good or bad will be context dependent.
That’s too complex a problem for a beginner. Start easy.
This game project: http://wl.widelands.org/
Was started more than 10 years ago.
This one: http://sourceforge.net/projects/freeciv
was registers at Sourceforge 2006, and is most likely even a bit older.
I can list more if needed. Some game projects are long-lived. And knowing about good programming techniques hasn’t killed a project yet. Actually many new members here barely can program at all, and I really would recommend that they first learn proper programming before they try to make games. Games are fairly nontrivial programs often, and good coding and design knowledge will help you.
I know for game development the coding standards are usually set lower than for business apllication “if it works, it’s alright” - and I also code a bit more sloppy on my hobby projects. But it is different if you go easy and sloppy in a conscious decision “because it will be good enough for the project” than if you can’t do better.
The time span is of no importance…it’s still a one shot deal.
Not in my world. Pretty much any big game released these days has tons of legacy code knocking about in it, often going back to the previous hardware generation. Games haven’t been one-shot deals for at least a decade, probably longer.
Doesn’t make a difference. Reuse of existing code doesn’t change the fact that it’s a one-shot. Yeah, including online-games with long in-user hand time spans.
You still need to debug and bugfix games. Cleaner (better designed) code is easier to read, undertand and bugfix. Well, I’d even say, if you have a well designed codebase to work with, you make less bugs in first place.
I think we’re talking at cross purposes, because it seems you have a very different definition of ‘one shot’ to me. ???
Long lived software is big enterprisey things under constant evolution in users-hands.
And you get there by experience, not by boning up on, say, the watershed method.
Accessors (getters and setters) are a big pain in the ass. The Java language should have followed the Uniform Access Principle, but it doesn’t, so accessors are here to stay. They might take up extra space in a program listing, but they shouldn’t be at all cumbersome to generate – every IDE has the ability to generate accessors for you, so learn that feature. That or use Lombok which will generate them invisibly so they don’t even show up in your source.
Following with my theme…I think it’s a better to get an idea of “why” you want to hide implementation details first, before blinding following the "wrap the accessors " dogma. (And yeah, getter/setters should be hidden behind the scenes…but I’ll leave at that or I might start ranting about operator overloading again). Beside, invoke the “refactoring fairy” when you get it wrong isn’t a big deal.
setter and getters are also useful when you always wnat to do something else, when calling a method. For instance, whenever increase the money, I want a sound effect to play; so instead of manipulating a money variable directly, you call changeMoney(40) which plays a sound automatically - crude example
Roquen is quite right.
You should KNOW what good software design is, and what practices are good, which are bad and why and what the pitfalls are exactly.
But you don’t have to adhere to these rules if you don’t think its necessary. Especially in game programming where it is important to get something done.
Almost all these rules are for big codebases with a lot of people working on it, constant evolution and re-use… that sort of thing, the “worst/best” case
Doesn’t mean you should take a dump on your codebase; but especially when you are the only one that will use this code that you are writing, you should do, what you think makes sense.
BTW, business apps are often some of the most hacked-up crap you can imagine. The average piece of open source code tends to be engineered better because the programmer would be too embarassed to release anything less.
Good engineering is as much about being able to understand and work with your own code as it is about being robust in the face of change. One thing the eXXXTREME!!! DøøD! Programming crowd gave us (other than a name I can’t help but make fun of) that’s actually useful is a huge emphasis on the importance of tests. Not just writing tests, but writing them first, or at worst, simultaneously. And not just ensuring complete test coverage, but writing your code in such a way that tests are easy and natural to write. Tests not only help you verify proper behavior, which is nice when you’re constantly changing things around, they also make you use the API you’re designing much earlier, which can clue you in to design problems early, even if all the tests are passing.
Making everything testable has a huge positive impact on your design, because it forces you to modularize things so you can write isolated unit tests with alternate stub/mock implementations of dependencies. Now for games with their heavy graphical component, automated unit tests are probably not so doable. But everything else should be as easy or easier to test than to use in real-world code.
Wow…so blind-esque following on some methodology doesn’t insure well-designed, written and bug-free code?? Who’d a thunk!
Exactly…and in here is part of the “artistic” element. We all develop techniques and styles as our skills evolve. Brilliant code today is likely to be bloody-aweful in a few years time. The bottom line here is there’s no replacement for experience…so get off your bottom and program!
EDIT:
OP: I clicked on your blog where you have a mention of Jobs & Richie. The really ironic thing here is that http://en.wikipedia.org/wiki/John_McCarthy_(computer_scientist) died soon thereafter and is never mentioned in popular press. It’s kinda dicky of me to measure the worth of some person’s life…but McCarthy’s contributions make Richie’s look pretty scant.
the point is that most business software is just quickly thrown together code snippets without any methodology.
And pls don’t give crappy advice like, use this only when working on a huge cooperate software project, because it doesn’t matter for your little game. Let me tell you something, every big software started small and in the beginning a lot of people think like this and end up with some crappy software after some years.
I do work a bit for a little software firm which does software for small industry businesses, there is one project which started small. And the boss told everybody just to finish it as fast as possible, because it was a one time only thing anyways.
Now we ended up making the software at least 5 times bigger and licensing it to several other companies. I can tell you how much fun it is to work with the old l agency code. We had to rewrite a lot of modules just because it is so a big pain in the ass to work with them.
And still your boss was (probably) right. It’s extremely important to publish a product to client #1, even if it sucks behind the scenes. That first client has to use it first, before it can become a success. Trying to get it absolutely right for client, and you probably never get it good enough, and miss deadline after deadline, before the developers deem it ‘worthy’.
Your boss is there to keep the business running, not to win a prize in code quality. That the maintenance is a burden, is just a minor inconvenience - for the business - regardless of what is it to you.
There’s really something to be said for the “worse is better” model.
You should try re-reading what I wrote. I implied no such thing.
I think its only important when lives are on stake or big sums of money.
[quote]On June 4, 1996 an unmanned Ariane 5 rocket launched by the European Space Agency exploded just forty seconds after lift-off.
…
development costing $7 billion
destroyed rocket and its cargo were valued at $500 million
…
software error in the inertial reference system. Specifically a 64 bit floating point number relating to the horizontal velocity of the rocket with respect to the platform was converted to a 16 bit signed integer. The number was larger than 32,768, the largest integer storeable in a 16 bit signed integer, and thus the conversion failed.
[/quote]
Not really so much a software engineering problem, but still makes me angry that a lazy programmer caused this (more than angry obviously);
IMO space shuttle code should be THE most sophisticated code there is. Maybe on par with CERN code.
The problem with software engineering, is that, as opposed to the designs of (structural) architects, there is no margin to work with. It either works or it doesn’t. When you build a bridge, you typically make it capable of handling 3 times the maximum stress it will be subjected to throughout its projected lifespan. There is no such concept in programming. A single typo or brain fart will bring the entire application down, while a rusty bolt will not affect the structural integrity of the bridge to the extend that it will collapse in the next few decades. So, there you go, there is no safety net in programming, and unless we manage to reliably put complex business logic in neural nets, it will stay this way. Forever.