Jump to content


Photo

Moving On


  • Please log in to reply
11 replies to this topic

#1 guyver6

guyver6

    Captain

  • Xenocide Programming Department
  • 599 posts

Posted 15 January 2005 - 10:53 AM

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)
<con_var> 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
Posted Image
Sourceforge: guyver6
LinkedIn: Andrzej Haczewski
"A good business idea, they say, can be explained in one sentence. Similarly, each program entity should have one clear purpose."

Join #xenocide at irc.freenode.net.

#2 Beetle

Beetle

    Programming Department

  • Xenocide Inactive
  • 350 posts

Posted 15 January 2005 - 02:01 PM

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 :)
Posted Image

#3 red knight

red knight

    Xenocide Project Leader

  • Xenocide Inactive
  • 3,310 posts

Posted 15 January 2005 - 05:25 PM

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
Sourceforge Nick: flois - Federico Andres Lois
Visit my blog at: flois.blogspot.com

Posted Image

Pookie cover me, I am going in.

#4 guyver6

guyver6

    Captain

  • Xenocide Programming Department
  • 599 posts

Posted 15 January 2005 - 06:50 PM

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
Posted Image
Sourceforge: guyver6
LinkedIn: Andrzej Haczewski
"A good business idea, they say, can be explained in one sentence. Similarly, each program entity should have one clear purpose."

Join #xenocide at irc.freenode.net.

#5 tzuchan

tzuchan

    Xnet Proof Task Force

  • Xenocide Creative-Text Departmen
  • 502 posts

Posted 15 January 2005 - 06:59 PM

Art and CTDs to work on glueing everything.

<{POST_SNAPBACK}>

*Holds up stick of glue...*
Er.... Whatcha want me to stick together?
Seriously, what can CTD do to assist the prog. department right now?
tzuchan - the last sane CTD writer
- Writer of the Anti-Astyanax Gun CT
- Read my X-Com Profile
Main reason I've got no free time anymore:
Posted Image
Be the Ultimate Ninja! Play Billy Vs. SNAKEMAN today!

#6 guyver6

guyver6

    Captain

  • Xenocide Programming Department
  • 599 posts

Posted 15 January 2005 - 07:10 PM

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
Posted Image
Sourceforge: guyver6
LinkedIn: Andrzej Haczewski
"A good business idea, they say, can be explained in one sentence. Similarly, each program entity should have one clear purpose."

Join #xenocide at irc.freenode.net.

#7 SupSuper

SupSuper

    Programming Department

  • Xenocide Programming Department
  • 2,418 posts

Posted 15 January 2005 - 07:32 PM

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

too bad, now you will never know the ancient secrets of supsupers long gone avatar ;)

Posted Image


#8 red knight

red knight

    Xenocide Project Leader

  • Xenocide Inactive
  • 3,310 posts

Posted 16 January 2005 - 12:32 AM

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
Sourceforge Nick: flois - Federico Andres Lois
Visit my blog at: flois.blogspot.com

Posted Image

Pookie cover me, I am going in.

#9 guyver6

guyver6

    Captain

  • Xenocide Programming Department
  • 599 posts

Posted 16 January 2005 - 04:40 AM

@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
Posted Image
Sourceforge: guyver6
LinkedIn: Andrzej Haczewski
"A good business idea, they say, can be explained in one sentence. Similarly, each program entity should have one clear purpose."

Join #xenocide at irc.freenode.net.

#10 rincewind

rincewind

    Programming Department

  • Xenocide Programming Department
  • 541 posts

Posted 16 January 2005 - 07:09 AM

...
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
Posted Image

I love boost!!! The next best thing since the invention of C++.

#11 mindstormmaster

mindstormmaster

    Programming Department

  • [Xenocide Senior Members]
  • 402 posts

Posted 16 January 2005 - 11:47 AM

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)
Posted Image

#12 SupSuper

SupSuper

    Programming Department

  • Xenocide Programming Department
  • 2,418 posts

Posted 17 January 2005 - 04:32 PM

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.

<{POST_SNAPBACK}>

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.

too bad, now you will never know the ancient secrets of supsupers long gone avatar ;)

Posted Image