GlestNG: ambition is my middle name

[will]

https://github.com/williame/GlestNG/wiki/Engine

of course nobody will be surprised if this project is like most projects I start - unfinished

[Mr War]

8.XML-based units and resources and such, based on the existing Glest structure. Things that are loaded from XML can be parsed and reloaded in-game, and an in-game XML editor and editors for other attributes are provided, so you can tweak things in-game to adjust balance and try things out and such.

In-game modding??? awesome toolset if you can pull it off!

This project sounds interesting.

[will]

In-game modding??? awesome toolset if you can pull it off!

awesome is my other middle name:

[Gabbe]

nice progress, but are you sure this is "Off-Topic" and not general disguission or mods?

[Omega]

^{Moved to General Discussion.}

Wow Will, I think your idea is great. Even if you don't finish this completely, I'd love to see its features implemented in GAE. The concept of modding while playing (again, I'd rather see that merged with GAE, though) is great. It'd be nice to be able to tweak units to perfection without having to open Glest, start a game, wait for it to load, create the unit with Lua, then see if it's good (and rinse and repeat).

[will]

I'm pleased at the encouragement but dismayed at the fixation on the xml-editing part

This is very much a game engine and not focused on an editing engine.  For me, the fun is the graphics and path-finding code.  I go into the project not knowing much about either, and hopefully that will change.

I am trying to load the XML for the units and I haven't found a good definitive guide to all the parameters I might encounter.  So to reverse-engine it, I wrote my own XML parser that, among its many things, 'paints' those nodes in the XML that it visits.  I then wanted to show this in-game rather than dissect HTML dumps of this info.  And then the viewer became an editor widget, since that was a fun distraction from the actually fixing some of my frustum code...   So you see that's why I have an in-game editor to show (the code is all in github at the above link if anyone wants to run it themselves even now, just to see the editor demo).

That units can be reloaded (actually, MG supports this so you could run in windowed mode and keep reloading the INI - at least it seems to assign a key to that, so it must be implemented!) is a by-product of supporting 2-phase construction (losing RAII is a big deal but seems necessary) so as to resolve dependencies over the network.

I must add my thoughts about the syncing client versions to the GlestNG wiki - it might influence MG/GAE too you never know...

[Mr War]

I hear you but us modders are preoccupied with current challenges. I heard that in thereal world they have living entities which do not require XML but such amazing things only exist past my nose, which is the limit of a modders perception;-)

I like that it is still rooted in glest , or at least glest mod compatible. That is key IMO

I do worry that so many features could raise the bar for modders though, especially the extra animation expectations- can cover this offline

[silnarm]

...since that was a fun distraction from the actually fixing some of my frustum code...

I know it nots as much "fun" as rolling you own, but if interested, you can find working code to extract the frustum planes in GAE's SceneCuller::extractFrustum().

Interesting 'little' project you have here ... not so little of course... best of luck!

[Psychedelic_hands]

I don't really understand a lot of this, but maybe I will once I see the finished thing  

I hope you have fun with this project, and the other Glests benefit of this aswell  

Edit: did you base this off VG, MG or GAE? I assume it's GAE as that's what you seemed to be more focused towards.

[Mr War]

P_h,
I'm not technical either but my understanding is that this is a separate strain of development alongside GAE and MG. It would have lots in common, especially compatibility, but the fundamental 'engine' underneath is different, particularly the graphics engine. It's a massive project but Will has proven a lot of it.

[Psychedelic_hands]

P_h,
I'm not technical either but my understanding is that this is a separate strain of development alongside GAE and MG. It would have lots in common, especially compatibility, but the fundamental 'engine' underneath is different, particularly the graphics engine. It's a massive project but Will has proven a lot of it.

I mean which Engine is he starting from.... I'm sure he isn't  starting from the original glest again... that would just be pointless.
I know it's not part of the development of any of the forks.... and it will be extremely different to nearly the point of being unrecognizable to them...

[Mr War]

No, blank slate start by the looks of it, building in glest code/logic if needed along the way. Will can correct if I'm wrong on that. He could write a whole new game but in spirit of glest, is keeping it compatible

[will]

Its completely new code, all of it, so far.

I like your new Imperial Faction logo Mr War!

[will]

Seeing as how there's wonder at the xml editing bit, I uploaded a micro-video (click on this link to go to the player):

http://sites.google.com/site/williamedwardscoder/glestng

(if you have problems playing it in Flash itself, you can download it from that page and view it in a proper viewer like VLC or ffplay)

In it you can see that some hotkey brings up an in-game modding menu.  From this you can click around and edit the various parts of the techtree.

In the XML editor those parts in bold have been read by the engine - you can see that my engine is not reading very much of the units XML yet.

The xml editor validates as you type, not just that it's sufficiently well-formed but also that it provides all the bits that the engine needs.  So you can see that the height in the unit XML is read, so its modified the loader no longer finds and an error is reported.  It would also highlight if it expected to read an integer or float or something but the value was malformed, and so on.

The editor could be extended with lots of fancy stuff - from scrollbars (it is scrollable, of course, but there are no handy scrollbars) to reporting errors, diffing versions and saving your changes (applying them in-game, even in multi-player) and so on.  The engine also knows what is a file path and so on, and so could have media editors and such too.

But I really built it to show me which parts of XML files my engine loads and such.

_{Edit by Omega: Your link was not working, possibly due to the strange image URL or the HTTPS protocol. At either rate, reverted to a stand alone link to the page with the video so people can see it.}

[Mr War]

great stuff Will. So basically this is the continuation of https://forum.megaglest.org/index.php?topic=6354.msg64836#msg64836 ?

[ultifd]

Awesome! How's the progress? Also, do you mind if I upload that video on youtube? 

[will]

Thanks for prompting.

Game engine projects are like icebergs - and only the tip of it, when you have something pretty, is newsworthy it seems.

There have been lots of micro-tweaking this last couple of weeks, as the source control log shows.

The next bit to get attention will - hopefully - be the world navigation with the mouse and moving the camera.

I'd be most happy if you uploaded the video to youtube

[ultifd]

OK, I'll upload it after I get some sleep. When do you think we can compile it ourselves? Or can we, already? 

[will]

OK, I'll upload it after I get some sleep. When do you think we can compile it ourselves? Or can we, already?  

Linux/*nix users ought to be able to compile it already fairly straightforward.

Its been a while since I compiled it on win32 with mingw, and the libraries it uses are a hassle.  I tried to make it static link, but still.  Anyone who wants to hold my hand on making it compile easily on windows (whilst avoiding cmake or other meta-make systems) is most welcome

What you do is clone it from the source code repository, or download a tarball from there, and then make a link in the data/ directory called Glest that points to your normal Glest (MG/GAE) base folder - it looks for techs/ and other subdirectories in there.

When you run it right now the focus is on the XML editing, and changing the colours for them (better colour schemes and UI interaction feedback most welcome!)

Discussion about the engine, about lessons learnt in the Glest engine, about the games I (we) want to make with GlestNG all most welcome!

[Mr War]

at a time when we are so happy to hear of MG and GAE strains converging, it seems odd to be making a new fork. but what's a fork without three prongs? cool.

black background is better than purple.

how does the 'virtual' grid work for buildings? how easy is it to auto-align buildings?

[ultifd]

Sounds like it's going to be hard for me to compile on Windows. 
Anyways, I uploaded the video. Do you think I should add the glest intro and/or menu music to it? Or should I leave it as it is...

[John.d.h]

What am I looking at here?

[will]

It looks like you have successfully compiled it, and successfully got it to find your glest data.

What you see on the screen is whatever graphics test code - view frustum culling code to be precise - that I happened to be testing last time I commited to the repo.  so nothing pretty right now, sorry.

Pressing the 'm' key will let you click around in the xml editing code that's being prototyped.

at a time when we are so happy to hear of MG and GAE strains converging, it seems odd to be making a new fork. but what's a fork without three prongs? cool.

fork is not an accurate term?  This is a new project.  It just happens to strive for at least basic data compatibility with VG/GAE/MG.

how does the 'virtual' grid work for buildings? how easy is it to auto-align buildings?

A good question.  The code is nowhere near there yet, but my thought is this:

Buildings can be placed arbitrarily anywhere on the surface.  Now the surface is naturally slightly convex - its flat if all corners of of the faces of the mesh you are placing the building on have the same distance from the centre of the planet.

The planet generating code will have to ensure there is plenty of flat land, or perhaps the engine supports terraforming.  Terraforming obviously has to be supported as a modding tool, so that you can generate a random planet and then terraform it to suite a scenario, and then save it and that saved game becomes the basis for a map or scenario.  But terraforming in-game as part of the game?  Reminds me of Populous.  I could imagine that the land around a building placement be auto-flattened if its within some tolerance of level perhaps.

The alignment is a trickier problem still.  I particularly don't want an up and down and a grid, but within the locality of a settlement that makes sense - at least in glest compatibility mode.  So when you place a building you have free rotate.  And when you place a building near another building, it auto-rotates to align (rather like snapping in powerpoint prehaps) but you can overrule that.

Navigating on a globe is a fun problem.  The engine will have to remember the camera you last viewed each distinct settlement at, and allow you to tab through all your settlements (and other points of note such as ongoing battles or wandering scouts) and show each in an appropriate orientation, otherwise you'll not recognise anything   Ideas on this front most welcome.

When we use the same engine to load classic Glest maps, all these decisions are eased, but we already have engines that can do that...

_{Edit by Omega: Merged double posts}

[will]

The red circles show where the user clicked.

I've been thinking about how the user will lay out walls and roads and such.  (Trenches, hedgerows, terrace housing, etc)

The radius inside the turn will all be configurable, as with the curvedness of the sections between curves.

With a radius of 0 and a curvedness-factor of 0 you'd get straight sections, suitable for roman roads and walls and such.

With a large radius and a high curvedness-factor you'd get a winding path suitable for country lanes and tracks.

I am now thinking about how best to build wall on such a path, with automatic towers every so often and gates when crossing paths and so on.

(in the GlestNG repo under prototyping/roads.py)

[charlieg]

That is seriously cool work.  The possibilities...

The name "GlestNG" might not be ambitious enough.