Level Editor

[bmarroquin]

Things that still need to be done:

• Move the Launcher
• Limit the amount of Platforms that can be added [Done}
• Add more platforms to the Toolbox, or populate depending on level [Done]
• Add goal, deathtrap and treasure to tool box
  • Only viewable in Level Creator not level editor.
• Prevent GameplayScreen from launching if there is no goal.
  • creation mode problem
• Level saving.
• Depending on template limit which objects can be moved.

More Things to add

• Erasing added platforms[Done]
  • Ctrl + Left Click?
• restart editing from scratch [Not necessary just ctrl click everything.]
  • Maybe in the pause menu
• figure out how to do this with a 360 controller

I had this on the pull request, I'm placing it here to remind myself and had a couple of questions on how to implement. I'm open to suggestions and I will post my ideas for some of them here to see if they are good.

[bmarroquin]

To make sure the objects in templates are not moved I think we should add a Boolean to each object and set it to true during the Level Loader. The when we try clicking on it and if that field is true we just ignore the click.

[Jjp137]

Well the player is only going to place platforms during gameplay, right? So if that's the case, you only have to check for platforms, and you can disallow the player from moving the goal, treasures, or deathtraps.

[Jjp137]

You could keep two List of Platforms too; one for all platforms, and one for platforms that could be moved. If the platform isn't in the List of Platforms object that contains the platforms that can be moved, ignore the click.

[Twisol]

( EDIT: Of course Jorenz beat me to the punch. :cry:)

I don't really want to modify the level objects to fit a specific external use-case - it's a clear violation of the open/closed principle. Instead, perhaps we could store the static platforms in a separate list from the user-movable platforms.

This also gets to something else I want to do: separate the classes that the GameplayScreen and GameEditorScreen use. Let the GameEditorScreen keep an EditableLevel or LevelPrototype or something, with the custom representation it needs for editing the information of a level, then transform that into a SimulationLevel for the GameplayScreen with a representation optimized for game simulation. The LevelPrototype would probably be the closest thing to the data actually loaded from file.

[bmarroquin]

Yeah that probably would be the easiest way to handle it then. If the player is creating a level from scratch he might need to move the goal and other parts.

TIP: Do not hit reset during editing.

[Jjp137]

@Twisol Heh :p But yea that's a good idea.

The GameEditorScreen could use a EditableLevel that has no World object (since we're using rectangular collision and such for the most part, and there's no Ball object), while the SimulationLevel has a World object with the more precise physics and such. That's the major difference that comes to mind, but there's definitely other differences as well.

@bmarroquin The editor is going to have two modes of operation, right? (It states that in the requirements document.) One's for gameplay and the other is for level creation. If the editor is in gameplay mode, the player shouldn't move the goal, death traps or treasures around, only the platforms in the toolbox. Thus, in gameplay, you only have to check platforms and automatically deny requests to move anything else. On the other hand, if the editor is in level creation mode, the player can move whatever he or she wants, with the only restrictions being that the platforms (and other objects?) don't overlap and everything is in-bounds.

Well...at least that's what I think :p

[Twisol]

@Jjp137: Basically we want different types to distinguish the different semantics each screen requires. The fact that there are different semantics is sufficient to distinguish two different types. :smiley:

[bmarroquin]

I already handled the non moveable objects. did we say whether or not we wanted the platforms to intersect with any of the circle objects? The treasures shouldn't intersect right?

[bmarroquin]

I had already thought of what you said about separating the EditableLevel and Simulationlevel and that was my reasoning when i made the GamplayScreen initialize the world instead of automatically when creating the simulation. Making a new class should make it better.

[Jjp137]

@bmarroquin Circle objects of the same type shouldn't intersect. As for platforms and circle objects, well how does the physics engine behave when they do? I'd like to say that they shouldn't intersect as well so that they don't cause any weird, nearly untrackable bugs or whatever, but that does limit creativity a little bit.

I prefer that they don't intersect, but it's up to you.

[bmarroquin]

@Jjp137 If the platform and circle share an edge no collision with the circle. If the circle is slightly sticking out and the ball should hit it, the collision is only detected when the ball slows down. Intersection does not seem optimal. I think death traps should be okay with intersecting each other.

[Jjp137]

@bmarroquin Ah yea don't let them intersect each other then :p I could kinda see why that happens since I coded all the collision detection stuff, but yea that sounds really problematic and not easily fixable.

[bmarroquin]

I added a few more things to the issue

[Twisol]

We should create separate issues for each bullet left to implement, so we can better track our progress on this front.

[Twisol]

I've split off a few of the bullets into their own issues, but I'm leaving this open for discussion on the more speculative points.

[Twisol]

All goals for this issue have been met. :)