Author Topic: Scenario Editor  (Read 1274 times)

daniel.santos

  • Guest
Scenario Editor
« on: 4 October 2009, 01:58:27 »
I think I know the best way to go about creating a scenario editor.  I think it will actually be best done in-game.  I don't think I even want to experiment with it until we've settled on a GUI library and integrated it into the trunk (or are at least close) because there will be a lot of GUI components.  But in essence, I think this is what it will involve:

  • From the Main Menu (or some menu) we have a "Scenario Editor" option.  This will invoke a "Scenario Editor" menu.
  • From this menu, we have the choice of "Edit", "Create New" or "Create From Saved Game".  The "Edit" option invokes a specialization of the current "Scenario" menu (Game::MenuStateScenario), the "Create New" invokes a specialization of the "New Game" menu and the "Create From Saved Game" a specialization of the current "Load Game" menu.
  • Each of these will initialize GameSettings and create a Scenario object (we're going to be more sophisticated than the C-style struct/class ScenarioInfo that's now in menu_main.h) and launch the ScenarioEditor. When loading from a saved game
  • A class named ScenarioEditor will exist in place of the Game::Game class, which will have it's own Gui class to replace Game::Gui. (Maybe this will be in some ScenarioEditor namespace?)
  • Finally, Game::World will be split, having the common functionality going into a Game::AbstractWorld (or WorldBase or some such) and the specializations being Game::World and ScenarioEditor::World.  The base class will contain all the map, techTree, tileset, all of the factions, units and associated getters & setters.

So silnarm, as you're re-factoring & such (especially with the Singletons), just please keep this in mind.

In short, my idea for the new scenarios includes most of the information from a saved game and I figured we'd reuse as much of that code as possible.  I would like to have a scenario editor where you can add units to any faction, move them around, screw with their stats, alter map heights (I want to add that to saved games as well), etc.  For example, maybe a scenario starts shortly after some other battle just took place and the majority of your units are damaged, buildings are on fire, etc., and you're job is to defend the base, repair it, etc.

silnarm

  • Local Moderator
  • Behemoth
  • ********
  • Posts: 1,373
    • View Profile
Re: Scenario Editor
« Reply #1 on: 4 October 2009, 09:59:14 »
I think I know the best way to go about creating a scenario editor.  I think it will actually be best done in-game.  I don't think I even want to experiment with it until we've settled on a GUI library and integrated it into the trunk...

Yeah, I was holding out on any discussion of this until we have the GUI sorted... The only thing I'll add atm is that there will need to be a campaign editor too... but this not something I personally want to explore greatly for now.

Quote from: daniel.santos
  • Finally, Game::World will be split, having the common functionality going into a Game::AbstractWorld (or WorldBase or some such) and the specializations being Game::World and ScenarioEditor::World.  The base class will contain all the map, techTree, tileset, all of the factions, units and associated getters & setters.

So silnarm, as you're re-factoring & such (especially with the Singletons), just please keep this in mind.

Yeah, I'm beginning to think more about the consequences of singletons, and it could be problematic.  However, this isn't really my fault ;)  While I have made World and Map singletons, and will revert them, they are effectively global anyway, Game was already a singleton, and has a public getInstance() from which you can call the public getWorld(), form which you can call getMap().  So the problem remains.

I'll need to investigate your namespace changes in the network branch a bit more, but I think we should go through the entire game project (namespace) and decide on a set of embedded namespaces to shove it all into... with as little interdependency as possible. Discussing and refactoring as we go...

Glest Advanced Engine - Code Monkey

Timeline | Downloads

Omega

  • MegaGlest Team
  • Dragon
  • ********
  • Posts: 6,167
  • Professional bug writer
    • View Profile
    • Personal site
Re: Scenario Editor
« Reply #2 on: 4 October 2009, 22:25:52 »
Edit the MegaGlest wiki: http://docs.megaglest.org/

My personal projects: http://github.com/KatrinaHoffert

Hectate

  • Guest
Re: Scenario Editor
« Reply #3 on: 5 October 2009, 00:31:50 »
Omega: Yes but a point and click, WYSIWYG editor world be great.

I like the ideas. Note that if you're going to enable terrain alteration you might as well make it a map editor at the same time! Or at least make A map editor at the same time. :)

daniel.santos

  • Guest
Re: Scenario Editor
« Reply #4 on: 5 October 2009, 03:50:29 »
I like the ideas. Note that if you're going to enable terrain alteration you might as well make it a map editor at the same time! Or at least make A map editor at the same time. :)

LMAO!! I was thinking the same thing, but I didn't want to stick my foot in my mouth and make the commitment! :)  So, we'll see about that, but I'm having a hard time arguing against it! :)

...a campaign editor too... but this not something I personally want to explore greatly for now.
amen!  So perhaps, in the end, maps, scenarios and campaigns can all be edited from "in-game", allowing us to render them as they would look in game, etc.  I noticed that they did this in Rise of Nations.  I think that noting it is enough for now.

While I have made World and Map singletons, and will revert them...
Actually, please don't revert them yet.  I think it serves them well to be singletons, or at least to be accessible in that fashion.

... I think we should go through the entire game project (namespace) and decide on a set of embedded namespaces to shove it all into... with as little interdependency as possible. Discussing and refactoring as we go...
100% agreed.  I mostly want this to make it easier to navigate the classes in my IDE, but that's not a good enough justification (IMO) to say we need to do it.  None the less, I just like the idea. :)

 

anything