Print

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

[strich]

Hi guys,

For a long time I've been a hobbyist game dev whose dabbled in almost all the roles a game needs to be complete (Modeller, Designer, Level Designer, etc) and I'm now taking a good look at programming. I've learnt my way around C++ over the last few months but the knowledge I am currently lacking is a higher level OO design process. That is to say, I'm curious as to how classes are organized and whether games like DF use the 'Model-Viewer-Control' methodology.

Ultimately I should probably pick up a book on the topic and read it cover to cover, but I'd love to have a discussion on how DF was designed from the ground up (Toady?) or how some of you would expect or go about designing and building a game like DF.

[jaked122]

this should go to the general discussion section... but I am also interested in the magical inner workings of DF, I don't need the source just something to show how DF ticks.

[strich]

this should go to the general discussion section... but I am also interested in the magical inner workings of DF, I don't need the source just something to show how DF ticks.

Indeed, I wasn't entirely sure where to put it. Mod - Feel free to move it should it need to. Moved.

About the source - Yeah I have to say I am disappointed that we don't get a peek. But Toady has his reasons, and the ones I've read here I understand completely. I'd also just like to point out that I would rather not have this thread hijacked by any more discussion on this specific topic please as I understand that it has been thoroughly discussed already, and I'd like to invite Toady into this discussion as much as possible.

[Mr Tk]

http://en.wikipedia.org/wiki/Model-view-controller

If you know a little about OO you should know a little about encapsulation and data hiding right? An object has methods/functions which other things can use to interact with the object and the data of the object.

M-V-C is the next logical step of that. Basically what it is saying is that you separate different parts of the program into three main parts:

Model: The data and how you store it
View: UI -  What you see on the screen and interact with.
Control: Manages and process the data.

So what does this mean?

Well it means that you can change parts and it shouldn't break things.

For example if you want to change the UI looked, because the Model and Controller have no knowledge of the UI you should be able to change it without breaking the under lying program. (An DF example would be the SDL/OpenGL project)

Also if you wanted to change the way that the your model stores data (e.g going from an array to a binary-tree) then you should be able to make a new Model without breaking the view or the controller as long as you keep your interfaces (method calls etc) the same.

Also check out: http://en.wikipedia.org/wiki/Design_pattern Patterns are very useful. Do not underestimate the power of patterns.


Oh good all those years of comp sci lectures are flooding back.

[strich]

Thanks for your input Mr Tk.
I have already invested some time into researching the MVC methodology and I believe it would be a great way to design games like DF. But I guess I'm simply attempting to widen my knowledge base by looking into any other processes out there, specially live applications like DF.

I'm hoping to gain some insight into how one would continue to keep such a huge and ever growing game like DF in an organized system. I guess the MVC design would greatly help such a thing. But even still, its a lot of code and a lot of features to implement.

[Shoku]

It's weird how familiar I am with all of this just from having played games.

Ok, I've taken a semester of programming for fun and read this one blog about game design but they didn't really have many gaps left to fill in so it's pretty much just games.

[Mr Tk]

If it's ok with you I'll just start spouting some of the stuff I've been taught and I've learn myself. Some of it will be relevant, some of it won't be and this stuff is no particular order.

(I've also re-read your first post and picked on some things.)

SHORT ANSWER: Planning, data structures, algorithms.


Long answer:
Planning and Documentation. It sucks the balls, but it helps. If I was going to do something the size of DF I would sit down before anything else and just plan. Plan around your core requirements as that is were the majority of your design is going to come from. This isn't DF either. Anything getting into anything more than 15 classes or so (maybe even 10) and things are getting to get real confusing real quick. I find Class diagrams are a big help.

As for how classes are organized... Well it very much depends on what you want to do.

Do you treat everything in the game like things in java in that they inherit from one common class e.g java's class Object. (This sacrifices speed for ease).

Do you use States to change an objects behavior (an units AI or even to change the menus displayed)?

Do you use things like factories or abstract factories to create and destroy objects?

There is no real right way to organize your classes, just things you want to avoid doing as not to make your code.

But again this is where the planning come in handy.

Testing. This one sucks the other ball, but again this needs to be done. If you can block test code, use Assert, then just throw as much malformed and rubbish junk as you can at your code and see if it breaks it. Ok this is harder for games but if you have parts you know what should be coming out when stuff is going in, you can test it.

Also how much do you know about data structures (binary trees, linked list, hashtables) and algorithms (like Depth-First search, Breadth-First search, A*, quicksort, mergesort)? Organizing and finding data is important (depending on what are you doing.)

I don't know if any of this will help you, but these are some of the things which I was taught and learned to be a better programmer.

[strich]

Thought I better reply finally. I'm still working away on learning as much as I can.
Thanks for your input Mr. Tk. There is evidently a lot for me to still learn yet.

[joelpt]

I'd suggest just picking a project and starting it. Preferably something simple and approachable; a Tetris variant for instance.

MrTk's point to plan is invaluable. I suggest sketching up some 'screenshots' of what you want things to look like with your favorite drawing tool. Then assemble them into a document, and add bulleted lists of what specific behaviors you want to implement in different screens. More detail is better.

If you go into sufficient detail, that document can become an excellent outline of everything you actually have to implement or create.


Most game engines use a master "game loop" that processes input, calculates the world, and renders the results to screen.

Wikipedia has a very nice overview article http://en.wikipedia.org/wiki/Game_programming

[Footkerchief]

DJDD: if you want a peek at DF's source to see how it's structured, you should take a look at the Battle Champs source.  Battle Champs was purposely built like a very stripped-down DF, so that community people could take a crack at optimizing DF's rendering code.

[Baughn]

I'd like to add that, most of the time, object-orientation in itself is the wrong way to go about writing code.

It's certainly a useful paradigm, but in my estimate it's only useful about 20% of the time; forcing yourself to use it all the time just leads to headaches. Instead, learning more paradigms helps a lot - logic programming, lazy evaluation, functional programming, relational logic, reactive programming, etc.

Oh. And DF does most definitely not use the model-view-controller paradigm. If it had, the graphics updates would've been considerably more impressive.

What it actually uses is, er, kind of spaghetti code; apparently, the code to update the display is mixed in with the code for updating the state of the world.

[Baughn]

..while I'm waiting for this TF2 server, I figure I'll write down a quick summary of what these various paradigms are all about. So:

Oh, and keep in mind that the "examples" below are languages that, while they are usually made specifically to improve on the concept they're attached to, can also use other models - though with varying degrees of success.

• Object-oriented programming: Model where, typically, you have semi-opaque "objects" that are bundles of data and functions to affect the data. You can call the functions, but not alter the data directly. (Well, that's the ideal.) Also overrated. Example: C++
• Actor-oriented programming: Similar to OO, but here each object represents a separate thread; the threads communicate by sending messages to each other. Often more convenient, in many ways, but costlier. Standard OO is a limit of actor OO, where the thread does nothing but respond to messages. Example: Smalltalk (via library)
• Logic programming: Model where you specify constraints on the solution for some problem, and the system automatically runs through every possible variant until it finds something fitting the constraints. Usually has serious issues with performance, and therefore very interesting (and complex) solutions for dealing with this, but is useful once you understand these. Example: Prolog
• (Pure) functional programming: Modelled on mathematics: You have functions, whose return value is dependent solely on the values of their parameters. They can't alter the environment, or read from the environment. Obviously the entire program can't be written this way, but it makes it much easier to reason about it - after you spend a year learning to use it. Easier if you already know lots of math, but not because it uses math; it's just similar thinking. Example: Scheme
• Lazy evaluation: Refinement of functional programming, where functions are called only once their values are needed. Somewhat hard to learn, but lends itself to extremely clear and concise programs. Example: Haskell
• Relational logic: Database model that lends itself well to storing data in such a way that you can query it in unforeseen ways, without sacrificing *too* much performance to do this. The basic idea is to never, ever store any facts twice; there are semi-complex rules to ensure this. (This means that you don't store both a list and the length of the list, for a simple example; you can calculate the length from the list itself. Some optimizations may be useful.) Example: SQL, almost. No true examples exist.
• Reactive programming: System where programs are modelled as behaviors (time-varying values, over continuous time) and events (with zero or more occurences), and their output is derived by combining these, creating more, etc. until you get end up with either an "event" or a behavior describing the program's output. Um. No examples exist; it's still at a very, very young stage. I'm working on fixing that, actually. ^_^
• Domain-specific languages: Language created specifically for a certain task. Does this task well, but often little else; may not even be turing-complete. Examples: Makefiles, Sawzall, HTML.. yep, quite a lot of variation here.
• Embedded Domain-Specific Language: DSL that is written using the facilities of a parent language, by making its statements valid statements in the parent language, etc. Requires a fairly flexible parent to work. It's very useful, though, since it means the threshold for a DSL being a useful thing to write decreases a lot. Good examples of parents: Every Lisp Ever, Haskell

The point is, object-oriented programming is just one tool in a very large toolbox, and you need all of them to be a good programmer.

[Lemunde]

I'd like to add that, most of the time, object-orientation in itself is the wrong way to go about writing code.

It's certainly a useful paradigm, but in my estimate it's only useful about 20% of the time; forcing yourself to use it all the time just leads to headaches. Instead, learning more paradigms helps a lot - logic programming, lazy evaluation, functional programming, relational logic, reactive programming, etc.

Oh. And DF does most definitely not use the model-view-controller paradigm. If it had, the graphics updates would've been considerably more impressive.

What it actually uses is, er, kind of spaghetti code; apparently, the code to update the display is mixed in with the code for updating the state of the world.

I suppose it's far too late in the game to expect an optimized re-write of the code from the ground up.  I guess this is what happens with a continuous project like this.  When you work on a project for several years I imagine your code is going to start looking like a complete mess.  It's unfortunate that it was started without the tools we have today.

Honestly I think DF would have benefited from being programmed in Rapid Euphoria.  It's not a very popular language and it's a tad bit slower than C++ but considering the massive amounts of data being processed in DF I think it would have been easier to program in.

As far as the work flow for programming a game...  I really don't think there's any right way to go about it.  Well, maybe if you work for a big name developer or you're working with a team of other programmers.  In that situation everybody needs to know what you're doing with your code.  But if you're just one guy doing all the programming, if it works it works.  Maybe it won't be quite as optimized as it could be.  But I think you're better off using your own techniques that's easier for you to wrap your head around than trying to follow some strict guidelines that you might end up messing up anyway.

If you want to learn to program a game the best way to do it is to just start programming a game.  It's best to run through a couple of basic tutorials just so you get an idea of how everything works.  There's plenty of those around for pretty much any programming environment you want to work with.  They shouldn't take you more than a couple of hours to go through.  After that try making something on your own.  Start off with something simple like an Asteroids or Tetris clone and keep google handy for when you get stuck on the physics stuff.  But as far as work flow and design philosophy, just use your best judgment.

[Baughn]

I agree, yet disagree.

On the one hand, you're right - if your goal is to write a particular program, it's best to use the tools you already know.

On the other hand, knowing the right tools is a great benefit, and the only way to learn them is to use them. Which often leads to that particular project going nowhere, which is why many people never do.

It's worth it in the long run, though.

As for Euphoria.. um. I'd agree that it's easier to program in than C++, but then that goes for practically every single language on the planet.

On the other hand, if Wikipedia is right, it lacks a compiler. I can pretty much state in advance that no compiler-less language would ever be able to run DF at decent speed.

Also, that feature list.. okay, I know I'm judging based on very little information right now, but - it would've looked good fifteen years ago, but today it's far behind the curve, and I'd have no particular reason to look closer at it.

I'm open to discussion, though; if you've used it, how about we meet up in #bay12games and chat about the language? I'm Baughn there as well.

[Lemunde]

Sure, I'll be in there in a bit.