Jump to content
XCOMUFO & Xenocide

Moving On


guyver6

Recommended Posts

Since from programming point of view the new release is pretty ready (at least I don't see anything to do, since tasks have been assigned or completed), I've started to think of the future, and how to accomplish certain tasks.

 

Last days I took a trip around game SDKs. I looked at Quake and Quake2 source code, I briefly looked over Quake3 Game Source and I looked at documentation of HL2 SDK. I was researching data driven designs and modability (since when game/engine is designed to be pretty data-driven, then modability is enormous).

 

One may ask why I've been looking on FPP games, while we're making Tactical/Strategy. If this is a question you want to ask then ask yourself first which game's gerne is most moddable, which gerne's community produces most mods and improvements? I think now you don't have to ask the first question, becouse you've just answered it yourself.

 

You may wonder does having game.dll (or whatever it's called) that drives the game is really a data-driven or just a plugin-driven design? First I thought of data-driven game as having bunch of files with numbers and statistics, that allow changing game behaviour without recompiling. Nice, but not so much. Why? Becouse everything else (like how those statistics or numbers are used) has to be coded. And recompiled. That's why programmers started to use scripts, consoles and plugins: to ease making changes not only to variables.

 

That was rationale why I was looking at FPP gerne. Now what I've decided.

 

First of all we need is console. This is the greatest thing Carmack (I think it was him, but if I'm wrong feel free to correct me :) ) invented and the greatest helper for developers. I believe that console is "a must" for data-driven design, since it allows changing things without even leaving game, also it allows the best (becouse in-game) debugging. I have an pretty Console class interface (not too complicated, pretty simple I'd say and should be enough for what we need for in-game manipulations, but that's becouse of the second thing I'm writting of below). The console has all the simple things it should like setting variables, binding keys and executing more complex console scripts (or configs, since those are just one console command per line files).

 

The other thing is scripting. I've choosen python for two reasons:

1. Very simple language designed to learn programming (maybe not only programmers can do some programming work in Xenocide... :) ).

2. Pretty easy integration (since we're already using boost, and boost::python is the easy way to integrate python as scripts language into application).

 

I've looked at angelscript and it's my No 2 choice if some great problems arrise with python integration. You may ask "Why not LUA?". Becouse it's harder to integrate, and luabind doesn't look like it's maintained, and at last I don't like LUA syntax (LUA comments are the strangest thing I've ever seen btw).

 

Python scripts can be run from console as well as python commands (ie. you can write "5 ** 2" and this will be interpreted as python command and result "25" will be printed, you can also write "runfile script.py", and then you can use anything that was in that file defined like "script.functionName(1,2,3)" or "newObj = script.ObjClass [newline here]newObj.method()").

 

As I said console has it's own commands (which are not python functions nor variables). Those are:

    wait - holds commands execution for one game frame
   echo <text> - prints <text> to the console
   set <con_var> <value> - sets python variable (residing in ConVars class) to a given value
   bind <key> <command> - binds key to a command that can be understood by console
   exec <filename> - executes console commands from given file
   run <python> - runs python interactive command (ex. "run 5**2" returns "25")
   runfile <filename> - runs python script
   <python> - this is the same as "run <python>" (if Console can't recognize command as it's internal one, then it executes it as python command and returns what python returns)

is the special type of variable (console variable), that is defined in ConVars object in python, and is visible as it was is main namespace. Those can control anything you like, but I'd suggest to use those only for very important variables, like screen resolution settings, renderer, debug informations etc. since any other variables used by game objects (like Earth rotation speed) can be made as properties of object, that can be exported to python, and then that property can be accessed like "EarthPane.earthRotationSpeed = 0.02".

 

Ok, that's all from me for now, I'm getting back to work on console and then on the UI part for it (we need to have some sort of window to see the console, since Console itself is the mechanism that binds variables and commands forwarded by user with the game internals; the console in quake that drops down is just an interface that displays console output and allows user to pass commands to it). Feel free to comment on this and do it please, becouse I want to now what I'm planning to do wrong. It's easier to correct design than to correct design and implementation.

 

Here's Console interface:

class Console
{
   YAKE_BUILD_SINGLETON(Console);

public:
   Console();
   ~Console();

   /**
   */
   void initialize(Uint32 consoleLines = 256);
   void shutdown();

   /** @brief Updates console commands execution every frame

       @param dt Time passed from last frame (this is available as per-frame updated convar "delta_time")
   */
   void update(Real dt);

   /** @brief Prints out text to the console
   */
   void echo(const String& text);

   /** @brief Runs simple, one line command (can be python script)
   */
   void command(const String& text);
   
   /** @brief Adds text to execution buffer.
   */
   void addText(const String& text);

   /** @brief Executes execution buffer.
   */
   void execute();

   /** @brief Runs python command (interactive interpreter)
   */
   void run(const String& command);

   /** @brief Runs python script file
   */
   void runFile(const String& fileName);

   /** @return false if there's type incompatibility or if there's no var with that name
   */
   bool getReal(const String& varName, Real& value);
   bool getInt(const String& varName, Sint32& value);
   bool getString(const String& varName, String& value);

private:
   TDeque<String> execBuffer;
   TDeque<String> consoleBuffer;

   Bool isExecuting; //< True when execBuffer execution has been fired
   Uint32 consoleSize; //< How many lines does console remember
};

 

RedKnight: I was thinking about C# and .NET scripting but it's not worth it, since only think I've found about running managed code from unmanaged one is COM-centric and since COM is Windows-only technology, it'll make xenocide unportable. Maybe there are ways of doing it portable, but I haven't thought of it too much, becouse there are other scripting languages that are already easy to integrate like python (thanks to boost::python) and angelscript (and LUA, but see above), so making Xenocide scriptable with .NET would involve inventing pretty new technology, and since it's our spare time, I don't think anyone would try to do it (in a portable way of course!).

 

Guyver

Link to comment
Share on other sites

If i'm not wrong there is about 1% of code completed at the moment :) so there is always something to do :)

 

About console, i was thinkig about it already :) yes it would be a good help. even now with gui making (you don't have to close game to move "that window 1 pixel to the right" )

 

I'm currently digging into cegui ( byg #71) but i still have problem even with compiling it :Brickwall:

 

IMHO we should at first make all GUI work ( batleview, baseview, graphs, soldier and craft customization, console and much more) beacuse without them we cann't see what are we coding :)

Link to comment
Share on other sites

Guyver: Yes I had been looking arround the same thing, if we were doing a Windows only version, C# would be the way to go, but as all that we use is platform independent it is not a good idea to tied us up with .Net because of that.

 

About doing all the UI, I concurr with beetle we must finish the GUI, but adding just the console would be in the next step. Another thing to add is the Music Playback. I think that with all that we have enough for a 0.0.7 release.

 

Greetings

Red Knight

Link to comment
Share on other sites

GUI is the Art departament job. They don't draw it - we can't code it. And I want Art and CTDs to work on glueing everything. Why we are making the whole dirty job? If I wanted to create and design and layout gui widgets I'd go to Art departament. I can code functionality, not draw GUI. And I'm planning on moving the GUI code outside, to scripts, since this is what we wanted: data-driven design. Oh, and personally I'd rather like to be able to send a ship to intercept another ship, or to see them flying around earth while I'm looking at theirs speed etc.

 

Anyway even if we want to do next GUI screens, then first we have to drop yake states, since they're not giving us any good (even Yake has dropped it). We need a simple gui framework to have it right, since now it's kinda messy now. Anyway, console and that finite state machine switch are priority No 1. We won't make much further without them.

 

Btw, we should release very soon, since pre-release stagnation isn't motivating (before every release there's a point where development stops to fix bugs and test the whole thing, but it stops and bores people also, so faster we release, faster we have fresh energy to work futher :) ).

 

Guyver

Link to comment
Share on other sites

You could start converting entries to XML. And you could take a look at various other xml files in data directory, like layouts in example. It's very easy to tweak widgets, but that's probably more Art Dep job. Anyway from CTD I'd like to see the XNet filled to it's capacity. And from what I know you have pretty much material out there. And you have one example entry in data directory to follow the pattern. And you have english.xml to fill in. And layout buttons texts to convert to STR_* pattern and put translation into english.xml. That's the job for CTD I think :).

 

Guyver

Link to comment
Share on other sites

i don't mind doing the GUI overlays, since it's something i can handle and i like to see the results :)

though imagesets and layout should be handled by Art, they make the textures so they can easily make imagesets for them and have the tools to easily edit the standard Taharez layout, while all i have is ms paint which really messes up PNGs with transparency :P

Link to comment
Share on other sites

GUI Design and implementation is necesarily an art job, I would put SupSuper in charge of working along with the Art Depatment if he wants to take care of the dirty job. As a first step I would suggest to start training the Art guys (while you do stuff) in how to fully use the current system. CTD guys like RustedSoul where able to handle Xml pretty well after having a validation tool.

 

Come on guys we are very bright people, we can find a workflow that help us all. We just need to know who are active. And members should pick tasks and try to fulfill them (even if they have to PM the whole senior team and more people to make them work), in short try to be more proactive and dont be shy (Contact me directly by PM or MSN if necesary). But, Who can I count for that? And furthermore, CTD, Art and Sound guys, dont be shy you can help in "kind of programming", Layout design is pretty simple to be done just a file with images coordinates and a couple of easy to follow Xml Syntax, you can give it a try.

 

About the internal testing only 3 or 4 guys post about it. What do you think about releasing with the known defects in there? I dont care, what I do not like too much is release less functionality than alpha 0.0.4, but that is not an option so that is out of the question (I had get used to it). So if it is for me, set as release time Monday 1300 GMT is good enough. (I dont say Sunday because I dont have time, but if either guyver or rincewind can do the release before monday, contact mindstormmaster and do the release.).

 

@Guyver: We have to define what is the scope for a quick 0.0.7 release, What should be done, and what we should show. My top list is visual stuff, that means the State Machine redone, more GUIs from the art department, the AI Technical Design ready to start implementing for 0.0.8 and Audio stuff (at least be able to playback music).

 

Greetings

Red Knight

Link to comment
Share on other sites

@Red Knight: I'll try to have console (with UI) ready by the end of this week, maybe the next one (since it's exams time in poland now so I got some tests to pass ;) ). In the meantime (while doing console) I want to do some Visio drawing of state machines for UI. I found lately that boost::fsm could be very good choice to handle FSMs, cuz it's very scalable (simple machines are simple), I want to do more research on it. If it works like I expect it to, then we'll have pretty stable framework that we can work with and implement rest of the GUI. Another thing is that I'd like to investigate the possibility of binding GUI events using python, to move the event binding outside the C++ scope, and to let us think more of functionality of the GUI and use cases (what user can do with it), then expose those functionality to python where it can be bounded to widget events (Crazy Eddie did something like that with LUA, Meta from Yake also using LUA, so I think this will require some copy-pasting and some assimilation, thou far less effort, than it looks).

 

I know it's not much of visual stuff, but that's only my TODO list :). Maybe other coders can do some visuals :unsure:

 

That was the TODO stuff that I want to take after Alpha 6.

 

As to the release I've probably fixed that shiny point that seamed to show on poles, and I've fixed globe.mesh (there was lot's of vertices that shouldn't be there), and made normal maps flat on oceans. And we have something more than 0.0.4 I think. We have working XNet (we just need to fill it :) ). I'll contact mindstormmaster about those changes and I'll try to collect what CTD and Art have for XNet.

 

Guyver

Link to comment
Share on other sites

...

I want to do some Visio drawing of state machines for UI. I found lately that boost::fsm could be very good choice to handle FSMs, cuz it's very scalable (simple machines are simple), I want to do more research on it. If it works like I expect it to, then we'll have pretty stable framework that we can work with and implement rest of the GUI. Another thing is that I'd like to investigate the possibility of binding GUI events using python, to move the event binding outside the C++ scope, and to let us think more of functionality of the GUI and use cases (what user can do with it), then expose those functionality to python where it can be bounded to widget events (Crazy Eddie did something like that with LUA, Meta from Yake also using LUA, so I think this will require some copy-pasting and some assimilation, thou far less effort, than it looks).

 

Just had a look at boost::fsm and it looks very promising. What it does though is implementing entry and exit into states by instanciating and deleting the state-class.

This will probably require us to write some form of wrapper(-template) that wraps the singletons.

Also I'm currently thinking on a pattern to have better resource allocation (I don't think we need to keep the Planetview-resources in memory while being on a mission, but at the same time, you don't want it to reload all the textures for the earth every time you enter or exit xnet or some other screen...

 

Having scriptability should also be not to hard, we could probably have a facility to subscribe to CEGUI::buttons and then to trigger events for the state-machine. Should give quite some flexibility...

 

I think python is a good choice for scripting language. Easy to learn, forces you to have well structured code and very portable.

 

And a console is a very good idea, I want to have god-mode :naughty:

 

Rincewind

Link to comment
Share on other sites

I'm re-installing VS.net as I type this, but it should be done in a couple hours, or later today. When that's finished I'm ready to do a release. I haven't had a chance to play around with using torrents to update only the changed portions of the release, so this will probably be a full installer again. (Sorry to 56K'ers)
Link to comment
Share on other sites

GUI Design and implementation is necesarily an art job, I would put SupSuper in charge of working along with the Art Depatment if he wants to take care of the dirty job. As a first step I would suggest to start training the Art guys (while you do stuff) in how to fully use the current system. CTD guys like RustedSoul where able to handle Xml pretty well after having a validation tool.

ohhhh, i get to boss people around! :whip:

 

"Alright you artist maggots, keep drawing! I want to see you sweat until I get some pretty nice looking buttons!" :P

 

ok, enough joking around. i'll get the Art dpt to work on it after we get this alpha released. though, do we have some sort of document outlining what UI screens and windows we need, and maybe their design? so we (i and Art dpt) have a better idea of what to work on.

Link to comment
Share on other sites

×
×
  • Create New...