a thread with shocking and amazing information about GOOF

commence the shocking!

Hehe.

I intend to put together architectural and functional descriptions of GOOF soon, but here goes:

GOOF Engine is a game engine, and GOOF Editor is an editor. Both are built on top of plugin frameworks so you can plug new tools into the editor and new objects into the engine easily.

Ignore what you've probably seen of the MapEditor - it was originally written by another developer specifically for editing PLM2 terrain. I started using it as a base and then completely rewrote it from scratch. Both the engine and the editor are not coupled to the PLM2 scene manager at all, in fact each tool in the editor can use whatever scene manager it wants, and the Engine also works on any scene manager.

One of the tools for the GOOF Editor is a plugin tool that lets you build scenes for the GOOF Engine. It has all the user interface for doing things like inserting new objects, selecting them, move, rotate etc. The key here is that the GOOF Engine is actually running inside the editor, so that you're actually editing a scene inside the engine. I won't get into specifics of the engine but there's a lot of fancy stuff going on. One of the most important things about this plugin for the Editor is that you don't have to create user interface for each type of object. All objects inherit from GameObject and expose properties to the editor - the editor dynamically builds the user interface for editing those properties. I can see this being used for almost any object. Booleans are displayed as checkboxes, strings as text boxes, ints and floats as spinners, vectors and colours, etc.

Object types are plugged into the GOOF engine using a factory system. MeshGameObject, ParticleSystemGameObject, LightGameObject etc. all expose properties via a function called enumerateProperties, and the editor calls setProperty once the user has changed a value. Also, each object that can be dropped into the scene is defined in an XML file, which specifies its default properties. For example, if you have 2 meshes, rock.mesh and tree.mesh there are two corresponding xml files that specify it's a "MeshObject" and its properties, its mesh name, whether it casts shadows, etc. Then you can drop the rock into the scene multiple times, and for each rock you can change its individual properties in the editor. The other cool thing is that the objects all refer back to the original xml file so if you want to change all rock meshes in the whole world to a different one, just edit the original definition file to change it to a different mesh. Same goes with any object.

Objects are plugins into the GOOF Engine, so it's very easy to add new types of objects. Current ones are Mesh, Particle System, Light, and Marker objects, however adding more is very easy. I have a custom Tree rendering object in the works, and plans for tons of others.

The idea of the GOOF Engine is that you base your entire game scene management using it, however once I put in the ability to export to other formats such as DotScene and oFusion, you can use the GOOF Editor to create scenes and then not have to use the GOOF Engine to load them and run them if you don't want to.

The GOOF Editor also has a plugin for editing PLM2 terrain. This is an example of a tool that is written specifically for a scene manager. It has UI for raising/lowering terrain, generating terrain, painting terrain, etc.

Like I think I said in my other post, the systems are built so that the user interface is separate from most of the logic, so adding a new UI in addition to CEGUI won't be very hard. The UI is the easy part in my opinion, the stuff that goes on in the background is the hard part. I have some docking functionality in the app for some of the windows - they snap to the boundaries of other windows, etc. I don't think that docking is a big deal, but what I have a problem with is CEGUI in general as a tool GUI because it's a bit sluggish compared to true windows controls.

I have set up a SVN repo with all of the source, dependencies, etc. including full source for Ogre, OIS, PLM2, GOOF, and binaries for Libnoise, Boost, and OpenAL so it should be no problem to download and compile GOOF without needing to work through problems with PLM2 etc. I want to make it as easy as possible to get it and work with it. At the moment the SVN repo is being graciously hosted by a user here, wolfmanx, but I may have to move it because he's not sure if he can give out anon access to the SVN server.

Did I miss any of your questions?

Clay

Awww, no reply from the_cx? I was looking forward to waking up this morning and seeing "wow, that editor/engine sounds like crap" or "hmm, intriguing, sounds pretty good".

hehe. sorry, i wanted to reply last night as well but only had time to read over your response once. i ended up reading it a few times over before i felt comfortable that i understood it correctly.

indeed this is new and interesting information about GOOF - its engine and editor, and it did answer some questions. however, with new knowledge comes new curiosity, so now i have some followup comments/questions!

i.)
i think the idea of automatically building a user interface based on querying the GameObject's properties is a clever idea. however, .NET does this out of the box in the now popular Control.PropertyGrid.




ii.)
i understand that the user interface is separate from most of the logic, so adding a new UI in addition to CEGUI won't be very hard. how will adding new logic be? which leads me to my next question...

iii.)
how does the GOOF editor handle new user interface components that arent merely just setting properties on entity types? like, an all new 'foliage painter' tool, upgraded sky manipulation, realtime LOD creation/manipulation on meshes, animation viewing on meshes, etc - things that arent just properties on entities. you have already said how the GOOF editor will handle that, it may work using a plugin, but now we are back to the user interface question. the editor will build an interface for properties on an entity, but for all new functionality, is it back to trying to hack together a user interface with CEGUI. in terms of the learning curve to do so, and in terms of the actual implementation, how intuative and easy would that be for a development team to do? i would say unintuative : somewhat okay.

iv.)
if you wanted to change all the rock meshes in the whole world, couldnt you just replace the .mesh file with a new one? i would in fact constrain it to this. having the user be able to make rock point to rock1.mesh and rock1 point to rock.mesh, are you sure this extra layer of indirection is a good thing? i do think having default properies on objects stored in xml is cool idea though, just not the names.

v.)
i agree with you in that the stuff that goes on in the background is hard. but i disagree with you in that the UI is the easy part. im sure that the people that designed the first dishwasher i ever had in my house said the UI was the easy part...seeing as though it was unusable and didnt make any sense! not to knock on your UI in the MapEditor Falagard, as i am referencing your comment, but imho, the UI can be as easy and as difficult as you want it to be. and imho, designing, prototyping and testing real effective humanly usable interfaces for a piece of software that provides the complex functionality that this software does, is a real challenge.

iv.)
going off the last point, God knows no one will ever get the user interface right the first time. and thats where the CEGUI will *really* get ya. not in the initial design and implementation of the things, but the revision - moving things around, taking things out and putting new things in...all the while trying not to break the surrounding user interface objects that are ever so delicatly hanging in the balance, oh yea, ive so been there. imo, .NET 2k5 minimizes this painful experience better than any other similar product out there.

iiv.)
so far i really do like the way the GOOF engine is sounding. i would use it in an editor if it did provide a lot of the stuff i would otherwise have to write; there isnt too much overhead; and taking some things like OIS out doesnt require too much hacking.

i) Ya, the grid property control is similar to what I'm doing and is what I sorta based it on.

ii and iii) I think you're understimating CEGUI. It's not all that different than any other GUI in creating layouts for it. People have done great things with it already - see the particle editor and the mesh viewer as examples.

I've created a window manager for CEGUI and other things that help ease the pain of dealing with it. The window manager makes it easier to deal with things that CEGUI seemed to lack, such as a modal window stack.

My select objects and insert objects windows are custom CEGUI windows, as are my windows for generating new terrain.

The properties window that is used for objects is generic and can work on anything that inherits from a certain base class. For example, Objects, Partitions, GameSystems and GameObjectManager are all done using the properties window.

iv) Yes, you could change the mesh file, but what if other objects are referring to that mesh file and you don't want to change them? It was just an example btw, you could for example turn off shadows on all objects in the game, change the light properties, etc. The point is that each instance of an object in the game refers back to metadata that describes it.

v) The UI is the easy part in my system, because the editor is only a small part of the overall puzzle. I agree that it is important, I'm not saying that it's not important. But the fact is there's so much more complicated stuff going on that the UI is classified as "easy". Here's a simple example - the whole world is divided into partitions in the engine. Since the engine runs inside the editor, the editor takes advantage of that. Can you imagine trying to run an editor for a large world game like Oblivion if everything in the whole world had to be loaded at once? Each object is put into a partition and only partitions near the camera are loaded at a time. Now picture dragging objects around in the world, they have to move from partition to partition. Since the editor plugin supports undo/redo, I had to do a lot of thinking on how to undo something when it was no longer even loaded. If you move and object, then move the camera away to a distant location, that object unloads completely. Now the user performs an undo operation - they want to undo the move of that object that used to be loaded. Stuff like that.

vi) You're a big fan of .NET, that's obvious. I like it as well. I agree that CEGUI can be painful, and at the same time it's not all that bad either. One of the big benefits of doing things in CEGUI is that it runs on anything, linux, mac, windows and looks exactly the same. You can also embed the editor in your game without problems.

/me is unswayed.

your example of the loading and undo/redo is a good example.

for me - a potential developer of such a piece of software who has equal access to both CEGUI and .NET 2k5, its all about weighing the pros and cons at this point.

[short explanation why .NET > CEGUI] (ignore if you already think .NET > CEGUI)
imagin a huge table - with one side having desired requirements from a UI package, and the other side being which package was better for this requirement, .NET or CEGUI. it would be a humongously long table with .NET reading all the way down. there is only *one* spot where CEGUI would be written, and that would be for cross compatibility. but really thats a moot point.

if there is such a wonderful and feature rich level editor that can only be used in windows, and that development team is serious about their workflow and content creation, _AND_ all of the modelers/level designers somehow happen to only have linux installed, only then would linux compatibility be an issue. first of all, the condition for this to be an issue seems pretty out there, secondly, its not a big deal to make a seperate partition and install windows, especially if your serious.

as for embedding the editor into the game, most people just want to create levels or worlds, and use those in the game.

with all the said, and imagining the table again, its only obvious to choose .NET over CEGUI.
[/short explanation why .NET > CEGUI]

You're preaching to the choir, which is why I separated the UI from the editor logic in the first place. I know that .NET > CEGUI, I'm a .NET developer and have written very large thick client applications in C# with web service backends. Despite this, I chose CEGUI. Am I nuts? A little. The fact is that most Ogre programmers are creating tools using CEGUI (see the particle editor and mesh viewer) and these can plug directly into my editor framework. I also think that I have a fully working editor right now that works fairly well in CEGUI and doesn't need much more added to it, without the use of .NET.

most people just want to create levels or worlds, and use those in the game.

Do they? That's funny, I think most people are here looking for an engine and editor, and leave when they can't find one, or try to create their own engine and editor from scratch and fail. Editors are easy-ish to create, but can only support a limited set of core functionality, and use dummy objects for those the editor doesn't know about. The key to the GOOF Engine plugin for the editor is that you're placing your actual game objects as they appear in your game, that's huge.

/me is unswayed.

your example of the loading and undo/redo is a good example.

for me - a potential developer of such a piece of software who has equal access to both CEGUI and .NET 2k5, its all about weighing the pros and cons at this point.

[short explanation why .NET > CEGUI] (ignore if you already think .NET > CEGUI)
imagin a huge table - with one side having desired requirements from a UI package, and the other side being which package was better for this requirement, .NET or CEGUI. it would be a humongously long table with .NET reading all the way down. there is only *one* spot where CEGUI would be written, and that would be for cross compatibility. but really thats a moot point.

if there is such a wonderful and feature rich level editor that can only be used in windows, and that development team is serious about their workflow and content creation, _AND_ all of the modelers/level designers somehow happen to only have linux installed, only then would linux compatibility be an issue. first of all, the condition for this to be an issue seems pretty out there, secondly, its not a big deal to make a seperate partition and install windows, especially if your serious.

as for embedding the editor into the game, most people just want to create levels or worlds, and use those in the game.

with all the said, and imagining the table again, its only obvious to choose .NET over CEGUI.
[/short explanation why .NET > CEGUI]

If CEGUI provides an in-game GUI, what does .NET provide? I have not kept up on the .NET workings with Ogre, because it does not interest me.

I tried to read your response with the attitude of, "Hey - this guy might explain why .NET is really good." I'm sorry to say this, but I don't see any argument in favor of .NET here. All I see is where you said, "the only thing CEGUI is good for is cross-compatibility."

What makes .NET actually good at rendering in-game 2D GUI windows with Ogre3D? What specific features?

It doesn't, he's not talking about rendering in game GUIs using .NET, he's talking about writing the GUI for an editor using .NET windows controls instead of in-game, which does make a lot of sense.

It's just that I'm saying there are reasons to go with CEGUI beyond just the functionality that of the UI library, and those include things like - developers already write their game GUIs using CEGUI so are familiar with it, and can embed an editor written using CEGUI directly into their game in case they want users to be able to create mods for their game. And since developers are already familiar with CEGUI for their game, they are already creating tools using CEGUI that can be added directly to my editor framework.

your example of the loading and undo/redo is a good example.


This is a good example for what?

@Occulis:

it really doesnt do justice to type it out like this, but basically visual studio has a very complex and feature rich editor for drawing and designer user interfaces. do you have visual studio? if so you should really check it out.

@Falagard:

I'm a .NET developer and have written very large thick client applications in C# with web service backends. Despite this, I chose CEGUI. Am I nuts? A little. The fact is that most Ogre programmers are creating tools using CEGUI (see the particle editor and mesh viewer)

let me get this straight, your new justification for using CEGUI in a world editor is that the mesh viewer and particle editor use CEGUI?

come on now. :p
having the mesh viewer and particle editor made with CEGUI hardly provides justification for CEGUI being the better choice for a level editor.

if you really wanna do a justifcation by comparison, look at the cryeditor, unreal editor, jupiter ex editor, etc. none of them use ingame ui and they all use windows controls, either mfc or .net. and those are the real, game industry, production level tools to compare to.

i think the particle editor is great. i just think it would look visually better if it was .NET, and the developers would have had a much easier time creating it. also, user interface extensibility isnt really a factor in the particle editor, like it is for a world editor. so that CEGUI limitation doesnt really surface.

also, the example you mentioned is a good example of those extra complexities that exist within a project like this that are initially thought of.

I think most people are here looking for an engine and editor

and also to clarify, i think most people want a WYSIWYG editor. after that they dont really care what the ui is - they just want the better ui. and .NET is the better ui, its that easy.

How can you have a WYSIWYG editor if your editor isn't running your game engine inside it?

Can't we all just be friends?

I'm not saying that the reason for using CEGUI is because of those two tools. I'm saying there are only two tools for Ogre that I know of, and they're both using CEGUI. That says something in itself doesn't it? Why aren't they using .NET? Probably because it's hard to integrate Ogre into .NET? Because they prefer C++ over C# or VB and managed C++ smells like dirty ass? Maybe because they're linux programmers? Some or all of the above?

I wholeheartedly agree that it's fine to create tools exclusively for Windows for the artists and designers.

Anyhow, I think we're going to have to agree to disagree and go our own ways, or you can look into GOOF as an editor and see if you want to rewrite the GUI in .NET and I'll support you as much as possible.

Personally, I'd go with wxWidgets if I were to redo the GUI, but that's because of some of the same things I stated above

as for embedding the editor into the game, most people just want to create levels or worlds, and use those in the game.
[/short explanation why .NET > CEGUI]
Not true for the type of editor he is making. This one was designed with MMO's in mind. This means that for people who realistically want to edit their zoneless worlds, this is the tool to have.
Do they? That's funny, I think most people are here looking for an engine and editor, and leave when they can't find one, or try to create their own engine and editor from scratch and fail. Editors are easy-ish to create, but can only support a limited set of core functionality, and use dummy objects for those the editor doesn't know about. The key to the GOOF Engine plugin for the editor is that you're placing your actual game objects as they appear in your game, that's huge.
I responded to him before I read your response, Amen.

@the_cX: Why are you even comparing this to the Cryeditor or UnrealEditor? We all know that this is not a fair comparison. This is a one-man show, and a damn good one at that. I agree that it would be great to see that quality of editor for Ogre, but I think we need to walk before we can run. If there were already other editors out there, then you could be justified in all your guiding, but the fact is that there is still not a single working editor that works within the Ogre engine. When there are others, then we can take the best of each and make a mega editor, but until then, lets help him, not give him a bigger list to do.

I think it is more important for Falagard to get his features complete before he ever worries about the GUI. As far as prioritizing goes, that would be WAY down on the list. If you are suggesting teaming up with him, then suggest it, don't just keep beating on your drum. Falagard has put a lot of time, thought and effort into this and he is justified to do whatever the heck he wants to with it. There are more than enough "justifications" to use cegui, so what's the hold up? Maybe I missed something about what your point is, but like I said, if you want to team up, then do it. Otherwise, let the man design his own app.

agree to disagree sounds good

@Jerky:

lol. this wasnt like, a random come in here and criticize Falagards work. :p
of course Falagard has done commendable work.

but this thread is actually a continuation of this thread:
http://www.ogre3d.org/phpBB2/viewtopic.php?t=20279

i was suggesting making a level editor for the google soc, and Falagard suggested collaborating on the GOOF MapEditor hes working on. this thread was just discussing if that would work out.

so this isnt about what the MapEditor should use for ui, its why im choosing to use .NET for my own proposed software.

I have a strong argument in favor of using your in-game GUI as the panel set for your world editor. It's in terms of testing, and of solid code. Your in-game GUI is obviously a hugely important part of most games. Hours spent by level designers and artists in their editing tools will vastly, vastly exceed the hours spent by your QA team testing your game. If the artists are using tools on multiple workstations doing multiple tasks for many years, then almost all GUI bugs are going to pop up during that time.

But I do see your point about the Unreal Editor and other editors using MFC and .NET interfaces. That is a solid point in favor of that technology.

lol. this wasnt like, a random come in here and criticize Falagards work. :p
of course Falagard has done commendable work.

but this thread is actually a continuation of this thread:
http://www.ogre3d.org/phpBB2/viewtopic.php?t=20279
That is what I thought, but I wasnt going to assume. I didnt read your whole thread, but I was aware of it. Just for clarity's sake, it would help if you mentioned that earlier for those of us who weren't on the same page .

BTW, for clarity's sake , I *was* defending Falagard's point, but I do agree with you that it would be a much more professional-looking tool to do as you suggested. I think it comes down to idealogy. Who is it that you want to support more, the open-source developers or the professional ones? A good case could be made for either side. Obviously, if Ogre or Falagard wanted to attract more professional developers, a tool more like UnrealEd and the like would be the way to go. On the other hand, for those of us who just want a working tool, a cegui-made one is best.

Like Occulus points out, developers could learn a lot by using it and learning how to tweak cegui, especially because their games will be using it as well. That, along with all of Falagard's points, still make more sense to me than your suggestions.

So, yes, I agree to disagree as well. Maybe 2 tools are needed?

2 tools


No, I'm going to redo the UI to use wxWidgets
It can look as professional as any .Net application and is cross platform and C++ based.

I've been fighting with CEGUI for performance anyhow lately. My laptop that I do primary dev on is a weak system. I have a powerful desktop and may start working on that, but I like being able to chug around the laptop. Now that I have SVN set up I can work on both no problem actually. But I think that wxWidgets is a better solution overall. I'll leave all the CEGUI management code in and support both CEGUI and wxWidgets in case someone wants to put in a CEGUI tool, but will likely port the two plugins I've already done to wxWidgets sometime soon.

Keep in mind that wxWidgets itself is pretty difficult to create UI with, but I like it better than going with .Net.

The new editor for the unreal engine 3 is completely rewritten using wxWidgets.

http://www.beyondunreal.com/daedalus/si ... hp?id=6277

I'm going to redo the UI to use wxWidgets

Good decision. CeGUI apps tend to lack the cleanliness and professionalism found in [say] .NET unless you really take some time on the skin and layout.

I have been curious about wxWidgets, but have not really checked it out yet. Looks like it will give you the best of both worlds though [professional AND portable]

Looking forward to GOOF!

GOOF is going to be even greater than I anticipated!

Now, about CEGUI versus wxWidgets/.NET/WhatNot:

In-Game GUIs and full-fledged GUI libraries doesn't compare, do they?

If GOOF is going to be as flexible as GOOFs going to be, support for both is needed.

If a clean GUI interface is written, you can embed GOOF in your tool/application.
And you can use whatever you want, be it widgets or forms.

However, sometimes it is handy to toggle game-mode and editor-mode from within your running 3D application.
Nothing beats CEGUI there.

It also depends on what kind of tool you are making.

The Particle editor for instance doesn't require anything else than OGRE and CEGUI, which is nice.
Makes it easier to compile and deploy/employ.

Looking forward to it!

EDIT: , beaten by several people, and I should of checked the second page too.

You are correct, if we wanted to have an editor that is up to the standards of Epic's UnrealEd we would make a cross platform GUI in wxWidgets, as they do . Maybe using some thing like DialogBlocks to get WSIWYG dialog layout goodness. Don't forget the numerous docking toolkits to get all the pinning, tearing, and tab functionality.

Disclaimer: I am a Windows, Linux, and Mac developer with wxWidgets and Ogre. So I have drunken the cross platform cool aid .

@Game_Ender:

definetly a nice set of links you have up there. i honestly didnt know such things existed for wxwidgets. wxwidgets can definetly be a good choice to use for a level editor and any other tool of this nature for ogre.

If you make a .NET editor that does what you have planned it will be a great asset to the Ogre community. I just wanted to point out that open source has a lot to offer too. wxWidgets has been under development for 13 years and the links I posted there just begin to scrape the surface of what it has to offer. We can also hope Mono gets the System.Windows.Forms support up to snuff in the next year and .NET applications will become truly more cross platform, making this whole back and forth a non-issue.

EDIT: Need to learn how to use a spell checker.

I hope that GOOF stays GUI agnostic, so that programmers are free to use whatever makes them tick.

No, it's not going to be GUI agnostic. If I go with wxWidgets, that's it. There's no point in creating a monstrosity here. When I say the UI is separated from the tool logic, it is, but i'm not creating some sort of massive UI plugin system that has to support any UI. Someone else can port it to something else but I can't imagine anyone doing so. It'll obviously also support CEGUI - as in - you can use it because it'll be initialized and be passed mouse and keyboard events, but the editor framework will be wxWidgets. If you really want to use CEGUI inside the editor for a tool plugin then that'll be possible but the ones I create won't be (if I do end up going to wxWidgets).

That's fine.
I am not planning to even touch wxWidgets, so I will port the editor for my project, which uses Visual Component Framework.
Shouldn't be too much trouble.

i'm not creating some sort of massive UI plugin system that has to support any UI.
No, that's definately not what I meant!

Anyway, Falagard: Consider requesting a GOOF forum. This is going to be big!

Question : Falagard, did you get time to make the switch over wxwidget?

Now, my point of view on this, I am a only windows user with Visual Studio. Despite of this, I think that GOOF should take a multi-platform GUI because we are saying that Ogre which is multi-platform it weakness is the lack of tools and now because of the GUI, the ultimate tool would be only for windows user. Doing such, the base mentality of Ogre would be lost (Open source engine, cross-platforms). Or at least letting a part of the cummunity behind for just a GUI.

I haven't yet switched to wxWindows, but the GUI is already multi-platform since it is using CEGUI which is rendered by the rendering API, which on linux/mac would be OpenGL. The question here is a matter of usability of CEGUI for a tool application, versus wxWidget which will use Windows GUI when running in Windows, or Mac when running on Mac, etc.

My long term plans are to port to wxWidgets but at the moment I'm focusing on much more important things, such as player movement and physics, and being able to use GOOF to actually build a real game

The reason I had a week or two where I was considered wxWidgets as a high priority was because I was running on a low spec machine (a laptop with a cheap integrated 3d card) and that's when you really see CEGUI start to have problems - when your framerate is around 10 to 15 fps working in debug. Then I moved my dev over to a desktop PC and it's not as high of a priority.

Hi,

@Falagard, I have some more questions and thought this thread might be the right place to ask.

(i) First of all, does GOOF have an own project's page? I only discovered the Wiki-Page and there was a lot of information missing, that I could read here in various threads of this forum.

(ii) I intended to use SDL Input and Audio/Mixer for my game and need a tool to create maps and load them in it (and a collision, not a whole physics engine). Can I use just these parts of GOOF and take SDL for the other ones?

(iii) What about Linux? I decided to work with Ogre because of it being cross-platform. In the Wiki Page, Installing and using GOOF under lin isn't even mentioned.

(iv) Where do I start? *g*
I mean, after installing the current version, does it bring a documentation or is there something in the internet, I couldn't find?


I think your project is really awesome and would love to use it, but I'm still undecided if it's the right choice for my case..

Thanks,
Harvest

i) The wiki is the only page available with information about GOOF at the moment. More info will come eventually but GOOF hasn't even reached Alpha stage yet. Documentation will be included with Alpha.

ii) The GOOF engine is tightly coupled with OIS for input. You could use SDL for input if you wanted, but input hasn't been abstracted out of the engine into a base class or anything since I don't deem it necessary to do so. OIS does the job, so that's why I'm using it. Sound, on the other hand, is a game system that you could easily do using SDL, as a SoundGameSystem will be a base class with a built in implementation for OpenAL, but you could create an SDL implementation as well.

iii) GOOF is cross platform in that I'm not using an Windows specific features any 3rd party libraries I'm using are also cross platform, but I'm not yet maintaining a Linux build or instructions on how to build on Linux. For that you're on your own until someone else picks it up.

iv) You can start by following the installation instructions but at the moment there is no additional documentation. This is simply because the project is moving at a fast pace and is a moving target. Building GOOF at the moment is a long process but with the next major update I'll be providing precompiled dependencies for all 3rd party libs, such as opcode, openal, wxWidgets, etc. so it'll be much easier. No word on when this next update is going to be released, but it should be soon after I finish porting to wxWidgets. The next update is not Alpha though, it's still too early for that.

All in all, it's up to you really whether you want to use GOOF. At the very least you should look at the GOOF source code since it has a lot of features already, even if it is not ready for creating a full game.