Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


The process of making a level editor


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 ic0de   Members   -  Reputation: 870

Like
0Likes
Like

Posted 16 October 2012 - 07:22 PM

I have decided to help out my artists and develop some tools such as a level editor for my engine. Right now the workflow involves exporting chunks geometry data from blender then editing a text file to list the file address of each chunk and its position as well as the position of entities like monsters or lights. I was hoping to create a tool that would generate that file and let the artist move each chunk or entity and see the results graphically. I was wondering is the level editor usually using the same engine (mine is made in house) as the game itself or is it usually an original piece of software? Are there any universal editors than can be scripted to export to a custom map format? Also how does 3d selection work I would assume it involves ray-casting? Can someone point me in the right direction for making a level editor?

you know you program too much when you start ending sentences with semicolons;


Sponsor:

#2 L. Spiro   Crossbones+   -  Reputation: 13958

Like
3Likes
Like

Posted 16 October 2012 - 09:41 PM

The editor will be a stand-alone project that links to and uses your actual in-house engine (meaning you need to add support for multiple views to it and remove its game loop if it has one built-in).

Valve Hammer Editor does not export in custom formats, but the .MAP/VMF files it exports are easy to parse and convert to something in-house, though it is unlikely to be suited for your purposes since it cannot load your terrain/models.
You will find that to be a common theme among all editors, so it is generally easier to make your own primitive editor and add it to over time.

3D selection does involve ray-casting. If that worries you, you may not be comfortable enough with 3D math to be able to complete a usable editor.


L. Spiro

Edited by L. Spiro, 16 October 2012 - 11:15 PM.

It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#3 ic0de   Members   -  Reputation: 870

Like
0Likes
Like

Posted 16 October 2012 - 10:06 PM

3D selection does involve ray-casting. If that worries you, you may not be comfortable enough with 3D math to be able to complete a usable editor.


No. That doesn't worry me it's just I already use raycasting(provided by bullet physics) to check if my player can grab something among other things. I was just wondering if 3d selection worked the same way with a mouse as opposed to a rotating view. I was thinking just cast a ray from the mouse into the screen and select whatever the ray hits.

you know you program too much when you start ending sentences with semicolons;


#4 Krohm   Crossbones+   -  Reputation: 3167

Like
5Likes
Like

Posted 17 October 2012 - 12:55 AM

Have you considered custom properties? They work like a charm for me.
CustomProps.png
Here's how my (hopefully) final workflow goes.
  • Level geometry is generated normally.
  • Adding static meshes. The meshes are authored externally and imported. The basic mesh is annotated with a special customprop instructing the filter to alias those meshes.
  • Adding other resources such as gameplay elements. They are similarly annotated.
  • When done, export to collada.
  • A python script in blender walks over the scene graph (it's basically a vector in blender) and pours out a nodename, properties set for each annotated node. It dumps everything to json.
  • Filter loads the exported collada, short-circuiting parsing of anything having an allocation. Done.
This way you still get the benefit of having an editor "almost ready to go".
Couldn't you encode this in collada directly? It's very likely but it's my understanding that AssImp won't load the data so I found another way.

Edit.
As a side note, make sure you write the custom props in the correct place. It is possible to put custom props pretty much everywhere. In nodes and materials for sure. I think meshes also have a custom prop capability but I'm not sure. Sure there are other places where custom props could be used but I'm not all that good with Blender.

Edited by Krohm, 17 October 2012 - 12:58 AM.


#5 dAND3h   Members   -  Reputation: 214

Like
2Likes
Like

Posted 18 October 2012 - 12:45 PM

Just keep it as simple and practical as possible at the beginning. When I did a simple 3D level editor(simple as in 1 weeks work) I made sure It was a completely separate entity to my game. Therefore, the only thing I needed to do was to decide how I was going to store the data, so I could parse it accordingly when my game loads the level. It did however use alot of the code from my game, most notably the render and input code, with modifications to suit the editor;

Because I had such a short amount of time, I decided to limit the artists abilities to just translate,scale and rotate objects. I also decided to leave out the ability to add textures in the editor. I believe as a starting point, this is what you should aim to do.

You would have to make a decision as to whether or not you want to load the models from within the program dynamically, or to load them before hand. Clearly the dynamic option would be more use to the artist, as they wouldn't need you to dig around the code to load another model, but as a start, the pre-load method is adequate.

For ray-casting, you need to make sure you are only casting inside the "viewport" where your scene is being rendered. Otherwise, you will end up with a bogus cast because of the mouse position taking the entire window into account.

Edited by dAND3h, 18 October 2012 - 12:48 PM.


#6 Krohm   Crossbones+   -  Reputation: 3167

Like
2Likes
Like

Posted 19 October 2012 - 01:22 AM

(1) Just keep it as simple and practical as possible ... (2) It was a completely separate entity to my game .. (3) decide how I was going to store the data, so I could parse it accordingly ... (4) use alot of the code from my game, most notably the render and input code, with modifications to suit the editor;
Because I had such a short amount of time (5), I decided to limit the artists abilities (6) to just translate,scale and rotate objects. I also decided to leave out the ability to add textures in the editor.

Sorry but I disagree on some of the concepts here and I need to point those out so people can properly relate to the efforts involved.

(4), (2) We could discuss that. There's a code dependancy.
(3) this is not future proof. How my code loads its own data is the last of my concerns. What concerns me is compatibility across other DCC tools as...
(6) telling artists "you must use my editor" and "you cannot do that" is pretty far from best practice.
(1), (5) If I'm in a hurry, I don't write a level editor. I bolt my features on pre-made programs. Took me two days to write the blender scripts, and a week to refit the whole asset workflow. And I can guarantee my feature set is pretty rich.

My first (and last) attempt at a "slick" 3D level editor is something around 2001-2004 I think. Words fail to describe how limited it was and how much effort it required. In the end, it was just easier to filter input from other programs (not to mention this is required anyway as there's a large availability of test data on the net).




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS