next »

[structure and design are 90% of the work - do them first and the code will fall into place. Don't even think about implementation until you have a very rigid and thorough design!]

I think there has been far too little discussion about the overall architecture of the engine.  I'm rather alarmed by what I see on the Wiki now, more or less with individual segments of the game being designed independantly of each other.  That might work on a small project, but not here.  We need a definite overall design so we know how different components will interact.  We cannot safely design anything until we know what it will be expected to do, and how it is expected to be used.  I see the beginnings of design for commandsets, but how will the interface use them?  I see function prototypes, but absolutely no design going on.  That's a recipe for a disaster in the near future.  I'm going to say this and I may have to repeat it a hundred times:

structure and design are 90% of the work - do them first and the code will fall into place.  Don't even think about implementation until you have a very rigid and thorough design!


So, I would like to discuss the M-V-C architecture, which was discussed in one of my classes last year.  It stands for Model - Viewer - Controller.  Essentially, the program (in our case, OpenWar) is split into three modules (each with their subdivisions, of course) which are model, viewer, and controller.  The controller gets input (be that from a network device, an external file, or keyboard and mouse), and then uses that input to make changes to the model.  The model is the guts; it manages the game and everything that happens in it.  The input from the controller can make changes to the model, and it will continue operation with these changes in mind.  The viewer takes data from the model and displays it in a graphical and audio format for the user.

There is a nice article here on MVC:

http://ootips.org/mvc-pattern.html

The controller interprets mouse and keyboard inputs from the user and maps these user actions into commands that are sent to the model and/or viewport to effect the appropriate change. The model manages one or more data elements, responds to queries about its state, and responds to instructions to change state. The viewport manages a rectangular area of the display and is responsible for presenting data to the user through a combination of graphics and text

In our case, sound will also be an output which the viewer should handle, and we'll also need to consider input from the external XML files and through the internet. 

We should begin here, and start splitting up the game from the top down.  We must analyze the input expected, and the expected output, of each of these three modules, and build our classes within them to achieve these ends.  Right now, I see a very disorganized mesh of classes with very little order forming.  We need to start here and change that.

you're right, i just don't have a lot of experience with this stuff (yet). i'm at school now but i'll look into it this afternoon

edit: ok we can do this. but where do we start 

Start with wiki discussion pages about the model, the viewer, and the controller.  Discuss the functions of each, and how they will be expected to interact.  Break each component up into sub-modules, and break up these submodules again and again until we have individual classes, then work our way back up piecing them together until we have a complete work.

well since you're the one who had this in his classes (edit: 'classes' as in 'lessons'), maybe you should make a start, and the rest of us can contribute. i don't think anybody else has any idea how to construct such a model 

ok, I've read the article that is linked to.

Let's start with listing the inputs then...

- Keyboard
- Mouse
- Controler (for xbox 360?)
- XML files
- Internet / Network
- The menu's and interface

...don't think there is anything else, you pretty much named them all, unless AI reactions aren't part of the process part

Now the viewports...

- The main playfield
- The mini map
- The interface
- Sounds
- Main menu
- Intro video's / Credit video's
- In game video's
- Unit information screens
- Error screens
- Debugging console

Ok, I've just been brainstorming on the possibilities here, just to get this started

About the process, I dunno, there are lot's of possible models to think of, quite a lot of them depending on what features we want to offer.

Edit:
btw. Here is a more in depth article on MVC structures:
Link

And add a TopView to the viewports list, the top level view module, containing all subviews nested inside it.

Solinx

To be quite honest, I don't have a lot of faith in console controllers when it comes to strategy games.  I'm interested to see how the Wii controllers turns out for RTS, but until I see it done, strategy games belong to the mouse alone.

I don't think AI should be considered input.  Keep them inside the model.

Beyond that, keep in mind we need some sort of hierarchy.  Does the keyboard and mouse input use the interface (which may be a menu or a battlefield screen or a commandset) or the other way around?  Also consider that a menu IS an interface, and a commandset IS an interface.  We have some hierarchies here to design, not just a list.  The same goes for viewports, and hopefully it's obvious that it applies to the model!

Anyways, I'll try to spend some time this weekend on the wiki.  I had a term project due today, and a final exam (it was a lab-course, which is why it's over a bit earlier than other courses) yesterday, so I wasn't exactly in a position to do more than fifteen minutes of forum browsing every so often.

What I wrote was just a brainstorm of what belonged into what category. After reading most part of the document I linked to, it became clear to me that it's not just a group of separate modules, but a structure of modules, forming a hierarchy, like you say. That was after making the post.

Anyway, it's nice to have things going on, but real live goes first. I hope you did well on your test

Solinx

Probably not, unfortunately.  No problems passing the course, but this one's going to hurt my GPA :-(

Actually, having the AI as a part of the controller is probably the best way.  There should be no difference between the AI controlling a unit, or the player controlling a unit.  They come down to the same thing.  If you design the system well, network play just becomes a matter of adding another player controller, and accepting the network input (after making sure it's valid and such).

i'm not sure, but I don't think that controlling units should be done from the 'Controller'. as i see it, the controller handles things like registering keystrokes

i might be wrong though

ps. MM why don't you register

I think we'll need someone experienced with network code to tell us how to do it.  I have no idea how a multiplayer game should function "under the hood" so to speak.

The controller communicates commands to the model.  Whether the controller interprets said commands or the model does is one of our design questions when we tackle how these modules should interact.

I think involving the controller in the AI may be redundant.  The model must determine what actions the AI will take, at which point the AI must make changes to the model.  It makes no sense to go outside the model in order to give input to the model.

The idea behind putting the AI inside the controller is that you should have no more than one way to affect the model (via the controller).  That means that you should treat all accesses the same.  The AI is using the model in the same way a player does, in the same way that a remote player does.  That simplifies the code path, and makes it much easier.  I've done a lot of looking into game engine design, and that was one of the important suggestions I came away with (I believe it's from Game Coding Complete, Second Edition).

The point is that if you put the AI in the controller, then the model has to give output to the controller, which then interprets that output in order to give input to the model.  It would probably be more efficiant to keep the AI encapsulated inside the model, since one way or another it absolutely needs the information stored there.

i say we make a Player interface, which is implemented by three classes, NetworkPlayer, AIPlayer and LocalPlayer. they would do the same thing (control their units and stuff), but in different ways.

tell me if i'm thinking too much in programming language now

I'm wary of simply treating a network player as any other input.  In fact, that's downright dangerous; if any player's model is not IDENTICLE to the others, it's out of sync and it's unlikely the game will be able to continue.  Simply put, in a lag spike my order might only reach another player a second later.  Units may already be responding to my order in my model before my opponent's even knows the order has been processed.  There needs to be some way to make sure that regardless of these timing issues, all players are playing the same game.  Running everyone off of one machine doesn't seem like a good idea, either.

I don't think in a practical sense network can be considered the same as mouse and keyboard input.  We definitely need someone who knows how to get things like these to work right.  The internet is the mother of all bottlenecks (even on high speed!), and efficiancy here counts double of anywhere else.  We need a top-notch design, and this is grossly oversimplified.

The reason I'm opposed to AI input is that it must call functions from the model in order to understand its position.  It will then run its algorithms and produce input for the model in the form of orders.  The problem I have is why seperate this from the model itself?  The AI takes its input from the model, and gives output to the model, hence it IS part of the model.  I feel it's not only sloppy, but possibly inefficiant, to put the AI in the controller.

The same argument could be applied to the Graphics renderer.  It's going to need information from the model to visualize the data, so why not put that in the model as well?  Decoupling the AI from the model has several advantages.  The biggest one is that you won't have to deal with a complex bit of code (the AI will not be simple) mucking about in the model arbitrarily.  You may pay a small performance penalty for forcing it out of the model and into a controller, but you save huge amounts in code complexity in the actual model.  The AI is just another controller, so it should be treated as such.  You want to use MVC, yet you are already planning to violate the core idea for a small performance gain.

You should start by designing the system as completely separate as possible, and then, when performance bottlenecks appear, address them.  There is no point in optimizing before writing a single line of code, or arguing over what will be faster without implementing things.  If the game runs acceptably with everything separated, you've saved yourself complexity, and you're set.  If it doesn't, look first at your algorithms.  Odds are the slowness is due to them.  If they look reasonable, then start considering what design hacks you can make that will speed things up.  If that won't do enough good, then consider redesigning portions.

A big lesson of software engineering is that almost everyone is at optimizing, especially before any code is written.  I don't remember where I saw it, but a study found that something like 80% of programmers would spend their time optimizing trivial segments of the code for a small performance benefit.  When you finally do get to the optimization stage, find a good profiler, and look at where the time is being spent.  Odds are it isn't where you expect.  Don't bother optimizing for small gains (1-5%) but instead look for the places that you can make large improvements (if one function is taking 40% or more of the time, it's a good idea to look at it).  Also, if an optimization will result in much less readable or complex code, make sure that it at least well documented.  Even better would be to keep a copy of the original code in a branch or available easily to see what it does.  It may be that later that area needs updating, and if no one understands it, it is useless.

This got into a rant on a lot more than what I intended, but there is a lot to say about software development.  I don't claim to be an expert, but these are just some of the things I've picked up through my readings, classes, and wanderings of the internet.

MVC architecture splits the design into model, viewer, and controller.  The controller takes input and makes changes on the model with that input, and the viewer represents the model's information.  This is important for abstraction and modularity.  Why would the model send information to the controller, which is then processed, and sent to the model as a command which in turn is processed?  The controller is entirely unnecessary in this setup; the data in the model is already abstracted and would need to be interpreted by the viewer, which would then formulate what input it would send to the model, which again would need to be interpreted and processed. The difference between graphics and AI here is that the viewer doesn't report to the model; the model is independant of what the viewer does (just like the controller is independant of what the model does).

There is no point in optimizing before writing a single line of code

A good design will never be surpassed by a bad one.  If we have a poor design to begin with, it's going to be poor no matter how well we work with it.

You are correct about optimization, but keep in mind that optimization can't help a bad design.  A good design can be more efficiant than a good algorithm can ever be.

The point I'm trying to make is that putting the AI into the model makes the model more complex.  You might as well move it out of the model, into a controller, and use the same sorts of methods for access that the player does.  That way you are dealing with a known set of functions, and a smaller code base to debug.  Strictly speaking it is probably slightly less efficient from a performance standpoint, but it is much more efficient from a coding and complexity perspective.

I disagree; the inputs the player receive come through the viewer.  The viewer has already abstracted the information in the model into a visual and audio form; these are useless to an AI.  An entirely seperate form of output from the model (essentially directly drawing its data) to the controller would be needed, at which point the controller would need to interpret this data, come up with a set of commands, and translate them into interface commands which would then be interpreted by the model.  Why not cut out the translation altogether and just directly feed the model with the changes from inside?  I think it's more complex to move the AI outside.

In any case, I think the answer will become more clear as we design the model and the controller and establish how they will function with each other.

isn't this MVC model already giving us more problems that it would do any good?

but yeah, we need someone with multiplayer experience. it's definitely going to be one of the hardest parts in programming this

What problems is it causing?  Discussion and difficulties regarding organization of the engine should be assumed regardless of what architecture we decide upon.

i feel it's limiting us, more than it makes it easier to design this

Again, how so?  Without MVC, we'd need to split the program into seperate modules and submodules, anyways.  MVC is a very natural (at least as I see it) division into input, processes, and output.  Without it, we'd have to come up with some method of organization and subdivision of tasks in a different manner.  No matter what design we pick, there will be drawbacks, and there will be a need to decide how each module will interface with the others.  If we have a disorganized mesh with little overall modularity it we will pay dearly later in the project, and I doubt it will succeed.  If we have a strong design now with excellent modularity, adding to the project over time will be easy.

You don't have to pick MVC, but unless you forward some alternative, it's the only design that's been suggested so far.  Any architecture will be limiting, but you can't create a skyscraper by piling metal on top of each other, rejecting a foundation and support beams because they're "limiting".

Ok we'll try it.

Morphic, that might be an alternative:

Arguments in favour of Morphic:
it is innovative and powerful:
it is actively supported, and on this list your questions
about Morphic will be answered
Some very interesting applications are implemented
for Morphic only

Arguments in favour of MVC: it is fast
it is small:
it is one of the really important achievements of
computer science and it was done in Smalltalk

Source

The wikipedia link
In depth information about Morphic

This is just what I found after a few minutes of searching for an alternative. Since I'm no programmer, I can't judge if this alternative is actually better for this project or not.

Solinx

i haven't checked that (it's late) but how can a model have source?

With source, I meant the source of the information I quoted 

Solinx

The sources you've found are specific to the squeak and smalltalk languages, and rely heavily on the libraries contained within.  A lot of the information regarding them in your sources is rather useless to our project because we're using a fundamentally different language.  I'll do some more research to see if I can find a language-generic article.

Don't trouble yourself too much if you think it's unsuitable.

Solinx

I can't say yet, I don't have enough information to make a judgement.  That's why I'm going to do some research later.

today i was talking to one of my teachers, and incidentally, he mentioned the MVC model. anyway, it seems to be good, so let's use it (and ignore what i said before)

Some argue on the importance on design. Read about extreme-programming paradigm. One principle in it, that we need to meet our demands on time, and in order to that, we simply start to write a program that meets the first and most important demand. Then we refactor it to meet the second demand. and so on...

Anyway, One thing that I have learned is that trying to do design as group is much harder and less productive than an individual. You should consider letting one of you guy to do most of the design, And then the result will be reviewed by the rest.

Note that, this program is quite large, and I think that it should be divided to logical parts, each one designed by its own (if design is to be done at all, see http://en.wikipedia.org/wiki/Extreme_programming).

    -- yuvi

Extreme Programming is generally the way I work, but I don't often do large projects. When I do, I generally notice that I could have saved a lot of time by thinking trough designs and stuff beforehand (sp???).

I'm not saying that we should design every little bit, every step of an algorithm, but we must certainly design things in advance

I tend to agree. especially on an open-source project, where the participants are less connected, A clear detailed design, and specific task assignment, is important.

If we are alreadyu talking about it, when does the design of the first pre-project start ? Is there anything i can do to help ?
-- yuvi.

the preproject is smaller, i think i'll design that one on my own and then post it up for feedback

About what belongs to the controller:
For me it's clear that keyboard, mouse, network, console interpreter, probably AI, ... should all be part of the controller.

First of all the keyboard itself is not a controller. The keyboard is an input device, when you press a key, you send a message to the keyboard-to-command translator. By taking a look at the configuration and translate the key to a higher level commando such as, move unit. This is exactly what the network does as well, regardless of network characteristics, the high-level command stays the same.

The high-level commands are given to the controller wich does the appropriate calls on the model.
Resolving network issues should be part of the low-level network layer, and has nothing to do with the controller itself.

I already rewrote this text a number of times, even made a graph to show this, but it's terribly difficult to express this stuff in text. Somewhere I should still have code for a game that shows the idea. Maybe I could make some skeleton code if you want.

For a introduction in layered approaches I recomment reading a bit on the OSI model, which is a layered model for networking, but can be applied for other things as well. The basic idea is that you divide your functionality in separate layers, where every layer can only communicate with the layer above.
http://en.wikipedia.org/wiki/OSI_model

but how to keep the model and view strictly seperate. i mean, an object (in the model) has a 3d-model, colour and other options that should be in the view, but it doesn't make sense to somehow weirdly stretch those properties over both.
in the end, i'm not sure MVC can really be applied to games, more for GUI apps

however, we must make use of louse coupling and observers/events as much as possible

actually the 3d-model isn't in the view at all. The view only renders the model in a way that its easy to read by humans.

consider the example of a bank account that's stored in a db:
* The model is responsible of retrieving and storing the data from/in the db, and allows primitive operations on it such as setAmount.
* The controller is responsible for more complex operations on the model. Such as interest calculations that use the primitive operations of the model.
* The view is responsible for showing the data to the user.

If the user clicks a button to perform interest calculations, it contacts the controller, the controller updates the model, and the model warns the view.

If your replace 3d vertices and color by amount you see that it makes sense to keep it in the model.

It's the model's responsibility to prepare the 3d mesh according to position, rotation, animation, ... Once the world has been updated, the view will read the data from the model and render it.

You shouldn't see MVC as a simply dividing your project in 3 parts, it can apply at a much more low level such as classes. The interest calculations could be seen as the model as well, used by even higher level operations.

This is why I mentioned the OSI model.

MVC doesn't mean you split your program in 3 distinct pieces, it can also apply on a much more low-level concept such as classes.

http://www.allegro.cc/forums/thread/592964