Trezker, did you use Dia for that UML? Can we have the file to play with please?

This was to provide an opportunity to put more games (or expansions) in the same exe . The first main menu would be the framework's, and could have [PLAY GAME1], [PLAY GAME2] [WEB UPDATES(clickthrough;D)] buttons. It would have its own style (flames for Flamework (earlier typo) is what I'm thinking, done in a slick, corporate style, so if you a) don't read it b) don't press a key and c) only have 1 game in the exe, then after a few seconds it would jump straight to the game's main menu, and you would think you'd just seen a publisher's logo. It's like lilo in a launcher

The Game's main menu would be the individual game's main title screen, with its own graphics etc.

Allegro has full support for UTF-8 built in. Fonts are the only concern.

I made a full Unicode Allegro font from a free one but it's rather plain. I think we should suck it up and let the user select the best font on their system, rather than try and supply a good, complete one with a compatible licence (which would be a huge file anyway) This removes stylistic control from the design team, unfortunately.

On the subject of internationalisation, I've got an evil plan for the Japanese version. Let's do to them what they did to us with Zero Wing. Nobody with any degree of fluency shall be allowed to assist. Otakus + Google Translate = Mirthful Joy Feeling \:)/

Scooby Dooby Doo!

It'll actually use the EDITOR variable on linux/unix which is normally set to vi or something similar, though mine is set to "nano", and I just prefer to pass short messages in, instead of messing with the editor when it launches. Basically I only use it when I have long messages to apply.

Yeah, but it's worth considering before hand-drawing a custom multi-coloured font.

There are still no code ?

Still on your UML thing ?

Move in team ! Go for the Objectives !

EDIT:

Trezker is IIRC.

I've made a second stab at UML. This time I made a god class which is preached against by OOP gurus... But it's simple, and we can split it later.

http://www.allegro.cc/files/attachment/596355

Game has a lot of stuff. It's the manager of everything.

I figure Monster, Player and NPC will share a lot of functionality so I made a Unit base class for them. I don't know why I bunched in trigger with them though...

Sure, but some thinking ahead might make it a lot easier in the long run. It would be nice to be able to just drop a new translation file, pick an option from a dynamic control, and have the game 100% translated. Again, optional, but I think it's worth consideration before starting.

Notice how when KQ was suggested, people started looking into the code, immediately saw that it was overwhelming and ugly (by their standards) and decided they hated it? The same thing can happen to the code written by others if it's not governed by the project. The framework is going to be the foundation of the project and if people don't like it or find it difficult to understand, they probably won't be too excited about the project.

I think we would benefit from coding standards and a thorough design. It might even be a good idea to use an automatic source formatter on the code before going into the repository (i.e. GNU indent). I personally have a compulsion to reformat code that I find difficult to read. This would allow me to hopefully do that without actually changing anything (in theory, GNU indent could put it right back again). It could be used on the client, instead, but then the repository itself would likely end up storing a lot of white-space differences (I think Subversion can ignore white-space, but that just seems like it would grow increasingly messy).

It just seems like some members would rather dig this project an early grave than take it's time and succeed.

I agree. Something like defining coding standards and modelling the application. It's a major part of writing good code. Designing it first. Think of how easy it would be to write the code if all the modules were documented beforehand!

Doing it right takes time. If you disagree with me then you'll be every manager's dream, every maintainer's nightmare, and every user's enemy.

The basic idea is we're trying to keep this from being a "long run". This is a very simple design with very basic mechanics which a single person could probably make easily enough given some time. We have enough of an idea of what we want that we can start putting code down. The last thing I'm worried about is indenting.

It looks like there's still some discussion on how the classes will be organized, and that's fine since it's actually important. But don't sweat too hard over it; agree on a design that works and start implementing it.

Yup, and it's appreciated. My only input is that all the managed objects should derive from a base class but you've got that anyway. If anyone else has a problem with how you're setting it up they can speak now or hold their peace.

I've never written a game like this so personally I don't know too much about the overall design/structure. I'll happily try to critique it though...

The model appears to be missing items/weapons. Are we still planning to have upgrades that the player can find? And what about NPC's and Monsters. Are either of them going to be able to have/use items and weapons?

It think it's awkward that the ScriptGlue and Script are not related at all... I think it makes better sense to have Game -> ScriptGlue -> Script and the game itself will still manage everything, but scripts are then able to communicate with the game (i.e. to control Units, for example). My only experience with a game engine and scripting was with Torque during a short 3-day "class" (?) at the local university. I don't remember the how, but C++ classes in the actual engine were bound to scripting classes in that if you called a method on an object in script it would be called in the actual engine, resulting in the desired behavior. That's how I see this going... Anybody done this before? Is this what we're planning?

Does anyone see value in a SpeechBubble class for managing the text, etc.? This way an actual Unit could just say() something and it's SpeechBubble would take care of the actual drawing. We'll likely need some way to tell it to switch pages though (i.e. say_more()) when given user input.

http://www.allegro.cc/files/attachment/596374

Essentially, CGame represents the actual game (:P). So far the game contains a configuration manager (CConfigManager), save game manager (CSaveGameManager), script manager (CScriptManager), tile maps (CTileMap; though perhaps we also want a tile map manager), and units (CUnit).

CGameObject is a base class that everything derives from, directly or indirectly. Obviously all of these classes will need to be wrapped in a namespace.

UML: PNG (XMI)

There is a lot still missing... Critique/revise! For those of you familiar with the kinds of work that will need to be done (collision detection, path determination, etc.), it might be a good idea to start thinking of how to wrap these things into a framework that can later be used...

** EDIT **

Hacked menu system back into it (Umbrello crashed and I forgot the menu system the next time around). I'm not sure why I went with "System"... I guess for the sake of the model, "Manager" and "System" are synonymous. So we can pick whichever we prefer.

_{UML would be so much more attractive if the software was intelligent enough to automatically arrange entities and relationships so they were readable and didn't overlap... :-/ Trying to do this manually, as demonstrated in the above class diagram, is a bitch. :P}

Personal preference, I guess. I like it because it frees up ClassName as a module-scope identifier, which frees up class_name for limited-scope identifiers. For example...

Which is exactly why we should nail down our coding standards. Odds are a lot of us will be disappointed that the project won't be using our standards, but it's a little bit easier to deal with when it's the "project's" standards as opposed to "his" or "her" standards. And as I said, formatting can hopefully be handled mostly with software (i.e. GNU indent). The naming conventions will need to be nailed down, but that's also why it makes sense to document the entire project model... It won't be individual programmers coming up with names for things. It will be them implementing an already detailed, named, project idea.

I think we're the same here...

I haven't actually used scripting in a game engine before so I'm a little confused as to how it works exactly... I think having to write a separate script for every single action or NPC would become lengthy. It seems like being able to write a single script for a "scene", for example, would be nice and clean. How to do this, I don't know. Perhaps the script will need a concept of a "timer" and "frame" as well so it can time it's actions appropriately (although "triggers" will help with this, they probably won't be able to handle everything).