Thursday, March 27, 2008
Thursday, March 20, 2008
Methodology to the Madness
It just occurred to me that the way I'm getting this ready for publication is worthy of comment.
I am restructuring this thing top down. Starting with the top level concepts and classes to do some much needed refactoring, plus rearranging file directories and files in the process. I am also going to throw out a bunch of failed and half complete experiments along the way. They can be reincorporated later if desired.
After this restructuring/reevaluation phase I need to re-implement certain things from the bottom up. The main thing is object lifetime. That's always a ball of wax.
I am restructuring this thing top down. Starting with the top level concepts and classes to do some much needed refactoring, plus rearranging file directories and files in the process. I am also going to throw out a bunch of failed and half complete experiments along the way. They can be reincorporated later if desired.
After this restructuring/reevaluation phase I need to re-implement certain things from the bottom up. The main thing is object lifetime. That's always a ball of wax.
The Applet Concept
This concept is not to be confused with Java Applets. The Applet concept goes further back if you look at the Wikipedia entry here.
I had been tempted just to change the name to Application or App for short. I'm going to stay with it in the eventuality that we may wish to run several of these side by side or embedded in a web page. That makes the name stick.
The Applet's main role is to serve as the root of the simulation heirarchy.
Applets are derived according to which GUI system the user plans on using. CEGUI and wxWidgets for now. More to follow.
I had been tempted just to change the name to Application or App for short. I'm going to stay with it in the eventuality that we may wish to run several of these side by side or embedded in a web page. That makes the name stick.
The Applet's main role is to serve as the root of the simulation heirarchy.
Applets are derived according to which GUI system the user plans on using. CEGUI and wxWidgets for now. More to follow.
The User Concept
Each Scenario creates and owns a User object.
The User object is created via a factory method of the Applet. (Need to define Applet soon!)
Each User class is specific to a particular GUI system. CEGUI, wxWidgets, etc.
Each User has a UserMode tree.
A UserMode is a class that can be either an action, a UserMode group, or a mode of some kind. For instance a dialog.
User interaction consists of drilling down and escaping back out of this tree.
It makes it extremely easy to implement user interfaces and is more intuitive than your average GUI with it's multiple menus, toolbars, etc., although these elements could be integrated into the User framework as well.
The User object is created via a factory method of the Applet. (Need to define Applet soon!)
Each User class is specific to a particular GUI system. CEGUI, wxWidgets, etc.
Each User has a UserMode tree.
A UserMode is a class that can be either an action, a UserMode group, or a mode of some kind. For instance a dialog.
User interaction consists of drilling down and escaping back out of this tree.
It makes it extremely easy to implement user interfaces and is more intuitive than your average GUI with it's multiple menus, toolbars, etc., although these elements could be integrated into the User framework as well.
Fire Bad!!!
This thing is a Frankenstein creation for sure. It's cobbled from open source components and it has graphics only a mother could love.
I'm not sure when, or even if it's going to appear. I'm not even sure about the license type yet.
So ... I'm just going to keep throwing details on this Blog for no apparent reason. :)
I'm not sure when, or even if it's going to appear. I'm not even sure about the license type yet.
So ... I'm just going to keep throwing details on this Blog for no apparent reason. :)
Wednesday, March 19, 2008
Requests For Comments
I'm going to start tossing some RFCs up here to help resolve issues that I can't make a clear cut decision on, even after endless hours of searching the internet.
Hopefully SOMEONE will participate.
Thanks!
Hopefully SOMEONE will participate.
Thanks!
Tuesday, March 18, 2008
GUI Madness
I'm probably the only person whose nuts enough to implement GUI interfaces for multiple GUI systems on a per scenario basis.
It all got started because the 'in-game' GUI looked like crap inside wxWidgets.
You could have GUIGUI wrappers but that would be insane, trying to wrap each element for each GUI system.
The solution is to have a factory function that returns a User object specific to the GUI that creates the interface and manages event routing.
This might be interesting in the fact that you could have the factory function create different interfaces depending on certain modalities: play, edit, etc.
Hopefully I get it refactored and working properly by days end.
It all got started because the 'in-game' GUI looked like crap inside wxWidgets.
You could have GUIGUI wrappers but that would be insane, trying to wrap each element for each GUI system.
The solution is to have a factory function that returns a User object specific to the GUI that creates the interface and manages event routing.
This might be interesting in the fact that you could have the factory function create different interfaces depending on certain modalities: play, edit, etc.
Hopefully I get it refactored and working properly by days end.
Subscribe to:
Posts (Atom)
