Sign in to follow this  

Opinions on a Level Editor

This topic is 4154 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi. I want to start coding a level editor for our action/adventure game. I will develop it along with the engine(I am using .Net for everything) so I have a question: Which is best: 1. Having an in game editor, with custom interface made in direct x and be able to edit as you play, switching between the in-game view and the editor view. 2. Having a standalone game editor using a standard windows interface(made using a standard resource editor) and the engine for rendering. I ask this question mainly because I don't know which one is harder: Configuring a custom d3d user interface(we already have one but it is pretty simple yet) for the in-game editor vs using the engine and loading of textures and such in the standalone game editor. Thanks.

Share this post


Link to post
Share on other sites
I would make the UI using .NET -- the UI widgets are much better than the DirectX ones. You're going to want tree views with drag-and-drop, etc.

For viewing the edited level, I would put the game engine inside a viewport. Then, I'd make sure that I have at least the following commands available:

1) re-set level to "loaded" state
2) start running level (physics starts, etc)
3) pause/un-pause level
4) single-step level (i e, run physics for 0.1 seconds or so)
5) switch between free-roaming and in-came cameras

Share this post


Link to post
Share on other sites
Thanks for the advice. I've always thought of the in-game approapch until yesterday, when I saw that it is difficult to implement in directx more complex UI controls.

Then I will continue with another question, because I'm pretty noob about such kind of tools. I thought of the following features to be included in the editor, along with the ones specified by hplus0603:

1. Particle System Editor
2. Heightmap browser with terrain generator and configurable height levels for vegetation and such.
3. Object browser and positioning with physic properties editor
4. Texture/Skin browser
5. Invisible objects creation (triggers, etc)
6. Camera Path editor
7. Waypoints editor (for the AI)
8. Lighting Configuration.
9. Character positioning and AI script assignment
10. Load/Save

Do you know anymore features that are a must in an editor and are not engine dependent(they must be present in any 3d Game Level Editor)?

Share this post


Link to post
Share on other sites
I would agree with the previous comments about making a separate GUI application for the editor. Using premade widgets will make the editor feel more consistent and should be quicker to develop.

Some other things I didn't see on your list (not level editor specific):

Selection (object selection(s), the tools you write probably want to operate on a selection)

Camera system (free camera, pan, rotate, zoom, zoom extents to selection)

Import/Export (it might be easier if you editor worked on a human readable file format to ease debugging and you can export it to your engine's native level format)

Consistent GUI (well laid out, intuitive)

If you gave more details about the "levels" being edited I'm sure I could come up with more specific features :)

Cheers,
dhm

Share this post


Link to post
Share on other sites
Thanks for your suggestions.

Your are right about selections, I've thought about them implictely, but not on all options you've described. But now I'm thinking to implement them too.

On the camera system, I thought just implementing a free camera for editing purposes, and eventually an orbiting feature.

On Load/Save, all levels are actually xml files, I am not sure yet there will be a binary format for them.

The design of the Gui will be made using the advices of our level designers, because it is important they feel comfortable with it.

Well the levels are for a 3'rd person action/adventure game. They will consist of Skybox(or dome) Terrain, Grass, Trees, Buildings ,Roads, a lot of characters, each one having their needs and doing their business, different objects placed here and there to help the player or to contribute to the general atmosphere of the game, Particle Systems for fire, water, smoke, etc.

Share this post


Link to post
Share on other sites
Hmm... the way I approached this in my game was to let the user generate (and name) any number of viewports they want, which all view the same "world". These viewports each had a visual representation (if they saw each other) - just a simple cube with a green line sticking out 1 unit showing the direction it's facing.

I'd experimented with a "camera linking" feature - which would have linked cameras execute the same movements at the same time... for example, when 3 cameras are orbiting a model, they could be locked on at 90 degree angles from each other - move one, the other two move to maintain that angle. I'd thought it was a good idea, but I have yet to see anyone using it. About all that did was have my use pointers instead of values in my camera's viewing angles - independent pointers if not linked, shared pointers if linked.

In my case, I was using OpenGL, which provided a "selection buffer" - basically, it would re-draw the scene around where you click, and tell you what objects (models, triangles, vertices, whatever you define) got hit. I'm not sure if DX has a similar feature.

I'd also put in a context-sensitive pane to the side of my viewport workspace - if you selected a single model, it would list actions that could be taken on that model (like assigning a mass or density, telling it to calculate volume - critical stuff for my engine :)). Multiple models being selected had a different set of options. Same for triangles and vertices. Then you have your different views, like waypoints and other events (I define a waypoint as a kind of event for my engine). Just having a context-sensitive pane instead of something that's always there, but not necessarily always used, saved a LOT of space and made the editor much more intuitive.

In my case, I had used Qt 4 (implies C++) + OpenGL + Silk Web, while the engine was written using C++ + SDL + OpenGL + Silk Web

Share this post


Link to post
Share on other sites
I'm currently writing a level editor in C++/DX9. So far it use only a basic win32 window, but since I've now implemented the most basic features I'm in great need of a real GUI. Could anyone point me in the right direction of how I should implement it? I was thinking of making my own interface, but this will take a long time to implement (I've done it before though). The pros is then that I can use the same UI in the actual game, but the in game UI could be really simple so it's not that important. What other options do I have to create the ui? Is MFC any good? I have no experience with it at all. I have no idea how people create these fancy looking UI's with gradients, shadows, etc as used in MS Office etc... I wish there was a way to use my current C++ code inside a C# created editor interface... :( I like how you designed window componens in Delphi! :D

Share this post


Link to post
Share on other sites

This topic is 4154 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this