• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
CC Ricers

Creating a level editor alongside the game, how to apply it?

11 posts in this topic

I'm planning out a WYSIWYG level editor for my 3D racing game, but will start with some more straightforward features like loading and moving models, before I get into more game specific things like building tracks and checkpoints. Having said that, as I'm also working on the graphics code that the game will use, there will inevitably be some level which it will have to respond to a WYSIWYG editor.

 

How "close" to the game code should the editor code be? Would you make it part of the game project, or in a different project that is deployed as a standalone program? I've tried using WinForms with XNA, but the combination didn't feel right to me. My plan is to start out with a simple GUI rendered alongside the game's graphics, like a toolbox for basic selection and creation functions. Nothing too big or complex like the editors for popular, commercial engines. I also found this, but I've yet to use it with my game...could be a timesaver if it's easier to fit it within my pipeline than making my own, though.

Edited by CC Ricers
0

Share this post


Link to post
Share on other sites

I think an editor has to know about the game, but not vice-versa. Ideally I would make an editor as an optional loadable wrapper around my game:

  • Intercept handling input and use it for editor button actions, selecting and manipulating items in world.
  • Make all game state related things dependent on single Game object somehow, and be able to use it to start(), pause(), restart() your game in-editor.

For example (some pseudo-code):

 

void EditorDraw() {

    this->game->Draw(); // same as for game
    DrawSelectedModels(this->selectedModels); // unique to editor
    DrawEditorGUI(); // unique to editor

}

void EditorInput() {

    if (!this->HandleEditorGuiInput()) { // if input does not belong to editor GUI
        if (this->game->IsRunning()) { // game is "playing"
            this->game->HandleInput(); // same as for real game
        } else {
            HandleWorldEditingInput(); // handle selecting, moving game objects
        }
    }

}
Edited by Nercury
0

Share this post


Link to post
Share on other sites

Caveat: "How close to the game code.." is actually a fairly perspective-dependant question. Many will say it should be very close, or that "the editor is the game!". Many will say not, there is no real 'true' answer only opinion.

 

Saying that, my own opinion is that "code wise" your editing application doesn't *need* to be that close at all, in fact I would say if it is close then you are significantly hamstringing yourself for no benefit. That doesn't mean it can't work, only that I think it's not the best way.

 

I would personally state that *data* wise, there should be a strong correlation between editor and game but not code wise. With the simple conclusion that a game is not an editor, and an editor is not a game. There are things both wish to do that are not of interest to the other and trying to get both to work in the same space will cause your final code to be a mash of both and the best of neither. Putting both together in the same code base narrows your options and forces you into design choices that are not based on what is best for your editor or game, but choices that don't break your editor or game.

 

Take, as a really simple example, a simple float. This represents the maximum 'strength' of something in the game, in the editor you would want associated metadata like an edit range, a display name, an edit type (numeric or slider, for example). The game doesn't need or want this meta-data, but it's there anyway because the editor needs it. You could then argue ways to provide that data that disappear when running the actual game (or even argue you don't want that data at all), but you're then already in the valley of "mash of both, best of none".

 

The code examples in the previous post (please don't take this personally, I'm just using as an example) ties the game & editor together in all kinds of ways I don't like (even if I were taking a "the editor is the game" approach).

 

My ultimate point is that you should be thinking much more along data-centric relations than code-centric, you can pile everything together if you like though that's not my personal preference (it can work) but I'd rather have an editor and a game with tight data driven relations. It's actually a big subject I could go on about for a long time unfortunately :s

 

n!

Edited by nfactorial
0

Share this post


Link to post
Share on other sites
FWIW: I started out more with the editor first, and ended up later making the editor into the game, as previously I had been using a variant of the Quake2 engine (as the game-engine part) and later decided that I wanted to be free of the GPL (in its earlier form, my engine was originally some 3D tools, like a 3D modeler, skeletal animator, and map-making tools), so I discarded the Quake2 engine (and nearly any other code I hadn't written myself) and at the time wrote a functional mock-up on top of my own code (albeit mostly using the maps from Quake 1), then later on ended up moving over to voxels, mostly due to me being not so good at making original maps which didn't suck, and voxel terrain was one of the few options which "wasn't totally lame" (I had also tried modular tile worlds, bus wasn't particularly compelled by the results, ...).


originally (some-odd years ago), my effort was more motivated at trying to make "better" free 3D tools, because most of what exists in free-land kind of sucks, but then I was left to note that my tools weren't really all that good either... and who knows how much work goes into making something like Maya or 3DS Max... interestingly (in a sense), the 3D models for my game were created in the engine itself. for the most part though, no one really seemed to care about 3D tools.


personally, I don't think there is anything particularly wrong with making them all part of the same codebase, at least as far as it goes that if the code is reasonably well abstracted, then it shouldn't really care too much if it is part of the engine or part of the editor.

the drawback: often code doesn't really end up that well abstracted, and in these cases one may end up with cruftiness, but in this case it is more a question of shared code with the cruftiness involved, or dealing with a lot of probably duplicate code, and still probably having ugly code.

not like there aren't a few ugly areas where there is a bit of hair (in my case, the code for handling the camera and user input is high on the list, essentially being implemented as a mess of settings over code that was originally written more for handling user-input for a 3D modeler, ...).

but, it works... Edited by cr88192
1

Share this post


Link to post
Share on other sites

My editor uses the game engine.  That way it's more or less WYSIWYG, so what you're working on in the editor will pretty much be what to expect in-game.  It's actually part of the main engine project but abstracted enough it could probably be a separate application and just reference the engine DLL.  I use wxWidgets for the interface.

 

The actual 'game code' is not really referenced at all by the editor (it is in its own DLL), just the renderer is used.  Everything is data driven so game entity definitions are loaded in from the script system which is actually separate from the game code.  (part of the engine).

 

It does make things a bit more difficult, as normally you would have certain objects in different data structures (static objects vs. dynamic objects for example), and since any model can be moved around you need to be able quickly update these in the background.  We also have a fairly complex shadow system so when lights are moved around part of their shadow maps need to be quickly recalculated as well (VSM shadows).  

 

This is easy enough for small scenes but as levels get bigger and more complex you need to be able to do this super quickly so the editing experience is impacted by poor performance or things popping everywhere.

 

There are lots of other things like being able to hot-reload assets in the engine, which means a little bit of extra work on the resource managers, but this gives the added advantage that you can update a texture or model even when in the game without having to open up the editor.

 

The editor code isn't the prettiest (I don't think it ever is...) and is bit of work to get going but definitely worth it in the end.  It's good being able to open the game up to test things out and having it look exactly as expected.

 

Bonus screenshot...

 

62Vn3xh.jpg

1

Share this post


Link to post
Share on other sites

@mightypigeon: Did you build that using .NET with C# or VB? When I was working in C++ and DirectX, I'd build mine using the winapi C classes, which is gross Win32 stuff from the 90's... Designing .NET applications are a breeze, but getting my C++ engine built on top of OpenGL to interact with .NET hasn't ever worked out for me yet.

 

EDIT: Woah, I asked before I looked up wxWidgets. You sir, answered by question before I even knew haha

Edited by Vincent_M
1

Share this post


Link to post
Share on other sites

Looks like I've started on the right track already, as I already have my engine code compiled into a DLL and the game project uses it. Where I do not know how to add editor features right now is for instance, rendering things like labels on objects or the rotate/scale/move gizmo, and rendering other debug shapes. I suppose they just need to be treated as special cases in the rendering engine, so they do not become affected by the lighting, for example. Sounds like the most popular option is to have the game and editor code as totally separate projects. Guess as a start, I'll keep both in one project but keep the editor code and game code in separate folders.

0

Share this post


Link to post
Share on other sites

Looks like I've started on the right track already, as I already have my engine code compiled into a DLL and the game project uses it. Where I do not know how to add editor features right now is for instance, rendering things like labels on objects or the rotate/scale/move gizmo, and rendering other debug shapes. I suppose they just need to be treated as special cases in the rendering engine, so they do not become affected by the lighting, for example. Sounds like the most popular option is to have the game and editor code as totally separate projects. Guess as a start, I'll keep both in one project but keep the editor code and game code in separate folders.

I'm sort of stuck there myself. I have this module in my code called HelpObjects, and it's just handles to global vertex and index buffers that are manipulated with Update() and Render() functions for drawing scene help objects such as lights and cameras. It literally took hours to hand-code my camera with the two film reels, frustum box, etc, but it works really nice now. The thing I'm stuck as is view scale. My camera, for example is about 5x5x2.5 units in volume, and that is massive in this game I'm working on where generic units are treated as meters. My player's ship model is like 2 units large long, and the 6 cameras that move with it to render its environment map are so large, you have to zoom the camera far out just to see that it's inside a bunch of camera gizmos.

 

What I'm going try is: setup an orthogonal camera, and do ray picking. If any gizmos are in view, I'll un-project their 3D coordinates to 2D screen-space coordinates and just draw my 3D gizmos in 2D ortho space like I would for sprites, but keep the rotation. The ortho view will always keep my camera the same size just like you'd see in 3DS Max, Maya, Blender, etc.

 

That might work, but the ortho-to-perspective might distort the way the rotation looks...

 

I have no editors for now, but any helper geometry (as you refer to as gizmos) are subclassed from my engine's generic "Object" class, and overrides the RenderHelpers() class to display themselves. So, when I set the RENDER_HELPERS flag to my scene, all helpers render. I also have flags for normals and bones for model instances that only get allocated, updated and rendered when those flags are set. ;)

0

Share this post


Link to post
Share on other sites

@mightypigeon: Did you build that using .NET with C# or VB? When I was working in C++ and DirectX, I'd build mine using the winapi C classes, which is gross Win32 stuff from the 90's... Designing .NET applications are a breeze, but getting my C++ engine built on top of OpenGL to interact with .NET hasn't ever worked out for me yet.

 

EDIT: Woah, I asked before I looked up wxWidgets. You sir, answered by question before I even knew haha

Back in the day I used C# for the interface with a small helper DLL written in C++ which was used to communicate with the engine using .NET interop.  It was a pain.

 

Lately I've been doing it the other way around, I was playing around with WPF and enjoyed it so now I have written a couple of dialogs for the editor using it and C#.  They export to a COM library.  After a lot of mucking around, the end result I can load up those WPF windows in native C++ using COM - no managed C++ or C++/CLI stuff at all, wanted to keep that away from the engine.  I ended up pulling an all-nighter to get it going, and I'm having nightmares just thinking about it again, but it's one of those things that once you do it the first time, it's there forever.  Definitely a learning experience!

 

 

 


Looks like I've started on the right track already, as I already have my engine code compiled into a DLL and the game project uses it. Where I do not know how to add editor features right now is for instance, rendering things like labels on objects or the rotate/scale/move gizmo, and rendering other debug shapes. I suppose they just need to be treated as special cases in the rendering engine, so they do not become affected by the lighting, for example. Sounds like the most popular option is to have the game and editor code as totally separate projects. Guess as a start, I'll keep both in one project but keep the editor code and game code in separate folders.

 

Rendering ad-hoc lines and labels and things like that is definitely worth implementing, even if you aren't writing an editor.  It can be a life saver down the track as you can quickly implement debug drawing in your game code (draw an AI's navigation path for example)

 

And speaking of gizmos, here is something I found that I found a while back: https://github.com/CedricGuillemet/LibGizmo

Works great.

Edited by mightypigeon
0

Share this post


Link to post
Share on other sites

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  
Followers 0