Level editor communication with engine
I'm thinking of writing a level editor using Windows Forms.
I want this level editor to somehow communicate with the game engine (has it's own exe). I'm not sure how to do this, I'm thinking that interprocess communication is the thing to use? I'm not sure and I hope someone might help me with how these two programs could communicate. The interface for communication should be as general as possible.
Also, do someone know any good articles/places I could read on how to attach a renderwindow to a part of a Windows Forms window?
[edited by - GameOxygen on June 9, 2004 5:05:23 AM]
For IPC, if the game executable is .NET as well, then Remoting is probably the best choice. If the executable is unmanaged and the editor is managed, then sockets with a simple message base protocol is probably the way to go.
I want both game engine and the editor to be independent exe's, the two should be as independent as possible.
Thanks mitchw, the game engine is unmanaged. Using sockets is something I will check out.
Another way to solve it might be that the game engine could have support for some type of command line (LUA?), which the editor could issue commands to. But I'm not quite sure how communication both ways could be done, maybe the editor also could support some type of command line which the game engine then could reply with the requested information?
[edited by - GameOxygen on June 9, 2004 12:16:49 PM]
Thanks mitchw, the game engine is unmanaged. Using sockets is something I will check out.
Another way to solve it might be that the game engine could have support for some type of command line (LUA?), which the editor could issue commands to. But I'm not quite sure how communication both ways could be done, maybe the editor also could support some type of command line which the game engine then could reply with the requested information?
[edited by - GameOxygen on June 9, 2004 12:16:49 PM]
when you are using the windows api why not use sendmessagew or what it''s called and just send some strings to the application
Here''s the way that I decided upon for my new version of the engine. The game ''server'' eg Engine that powers the game, handles maps entites and such is ''script-aware'', so you can do a whole load of stuff to the engine from script. addEntity() / addLight() / doStuff() etc can be called from scripts. If you set up your game client/server arcitecture like this, then the game ''service'' has a common way of responding to events from a source - be it a player, a network player, an AI, an editor client or whatever.
So if you look at the idea suggested before, create your client editor (which could just be a listening socket that takes a message from the outside and sends the response back). In your level editor application, you want to add a enemy to a certain position - the editor fires a ''addEnemy(500, 149, ''killer-robot'');'' script command down the wire which hits the editor game client in the engine... The engine''s script API could then act upon this, firing a reply to the client which in turn is hit back down the wire to your editor application.
Did I explain this well?
So if you look at the idea suggested before, create your client editor (which could just be a listening socket that takes a message from the outside and sends the response back). In your level editor application, you want to add a enemy to a certain position - the editor fires a ''addEnemy(500, 149, ''killer-robot'');'' script command down the wire which hits the editor game client in the engine... The engine''s script API could then act upon this, firing a reply to the client which in turn is hit back down the wire to your editor application.
Did I explain this well?
quote:Original post by GameOxygen
I'm thinking of writing a level editor using Windows Forms.
Before you write a bespoke level editor, make sure that you cannot easily create levels for your game using a combination of one or more of the following:
- A text editor (small tilemaps, item data if it's easy enough)
- An existing bitmapped graphics editor (useful for heightfields etc, simple large tilemaps)
- An existing 2d vector graphics editor (for 2d level data, or even 3d using some conversion routines / utils)
- An existing 3d vector graphics editor (with conversion programs as necessary for your desired format)
- An in-game level editor (useful for object placement in some situations - perhaps less ideal for 2d/3d vector data)
If none of them seems adequate, or your audience for the level editor will be utterly incapable of using that combination to edit the amount of levels you require, then consider writing your own editor.
Or of course, if you think it will save time in the long run, for instance if you have 5 people who will be creating 1000 large levels between them.
Mark
[edited by - markr on June 9, 2004 1:18:43 PM]
Thanks everyone, the answers has helped me in deciding what I really want to create.
That was quite informative. I got a question. You said "script-aware", and using sockets for communication? Could you maybe explain a little better what you mean by script-aware. Does script-aware just mean that the game engine is listening to sockets?
It sounds like a good idea for what I had in mind.
quote:Original post by downgraded
Here''s the way that I decided upon for my new version of the engine. The game ''server'' eg Engine that powers the game, handles maps entites and such is ''script-aware'', so you can do a whole load of stuff to the engine from script. addEntity() / addLight() / doStuff() etc can be called from scripts. If you set up your game client/server arcitecture like this, then the game ''service'' has a common way of responding to events from a source - be it a player, a network player, an AI, an editor client or whatever.
So if you look at the idea suggested before, create your client editor (which could just be a listening socket that takes a message from the outside and sends the response back). In your level editor application, you want to add a enemy to a certain position - the editor fires a ''addEnemy(500, 149, ''killer-robot'');'' script command down the wire which hits the editor game client in the engine... The engine''s script API could then act upon this, firing a reply to the client which in turn is hit back down the wire to your editor application.
Did I explain this well?
That was quite informative. I got a question. You said "script-aware", and using sockets for communication? Could you maybe explain a little better what you mean by script-aware. Does script-aware just mean that the game engine is listening to sockets?
It sounds like a good idea for what I had in mind.
Script-aware was referring to if you wanted to use LUA. You could get away without it, of course. The editor can send script text through the socket and the engine interprets it and does the desired action. There's other ways without scripts - use 'messages'.
But here's the basics - have a 'dumb' game client (handling input, rendering, local entity stuff) and a game server (handling the game, the enemies, the map, pretty much most other things). They can communicate via messages passed either locally or via a socket interface. What do I mean by messages?
Well each one can be different: for example, your editor client could send a message to the game server "create_enemy" (think of windows messages here). The server would respond by creating the enemy and replying with an "enemy_spawned" message to the client. Because your game service is built in two modes "edit" and "play" (you could take out or disable 'edit' later), this dictates how the server would respond to the messages. For example, in 'play' mode - the server would ignore most messages to do with adding things or altering the world - it'd only respond to motion and other such client input. In edit mode, the server is much more responsive to the messages from the 'client'.
So what do you need? You need a way for the server/client to communicate. In mxEvolution (my engine) there's a message transport layer, which can send messages either locally (client/server in same process - messages sent via memory) or over the network (messages sent via sockets).
The benefits of this are that you can reuse a lot of your code base - the game 'server' has two modes (or more, depending how many you want to add) which decide how it deals with messages. The client can either be a playable game (input/rendering) or an editor. The thing they have in common is that they have to share the same message communication interface to interact. In my case, the message is simply a numeric ID, a pair of parameters and an id for the 'source'. Locally, these messages just get thrown back and forth - over the network there's an additional layer to encode/decode the packets down to this interface.
Back to your situation. Enable a socket on the game and on the editor for communication. Then you need to be sure that the game and the editor are sharing the same game data (if you had the editor/game server in the same process, they could share the data in memory) - with your situation you have to ensure they're running off the same map file...
I'm going off on a huge tangent. If you want any more info drop me a mail and I'll explain things better.
[edited by - downgraded on June 10, 2004 9:18:22 AM]
But here's the basics - have a 'dumb' game client (handling input, rendering, local entity stuff) and a game server (handling the game, the enemies, the map, pretty much most other things). They can communicate via messages passed either locally or via a socket interface. What do I mean by messages?
Well each one can be different: for example, your editor client could send a message to the game server "create_enemy" (think of windows messages here). The server would respond by creating the enemy and replying with an "enemy_spawned" message to the client. Because your game service is built in two modes "edit" and "play" (you could take out or disable 'edit' later), this dictates how the server would respond to the messages. For example, in 'play' mode - the server would ignore most messages to do with adding things or altering the world - it'd only respond to motion and other such client input. In edit mode, the server is much more responsive to the messages from the 'client'.
So what do you need? You need a way for the server/client to communicate. In mxEvolution (my engine) there's a message transport layer, which can send messages either locally (client/server in same process - messages sent via memory) or over the network (messages sent via sockets).
The benefits of this are that you can reuse a lot of your code base - the game 'server' has two modes (or more, depending how many you want to add) which decide how it deals with messages. The client can either be a playable game (input/rendering) or an editor. The thing they have in common is that they have to share the same message communication interface to interact. In my case, the message is simply a numeric ID, a pair of parameters and an id for the 'source'. Locally, these messages just get thrown back and forth - over the network there's an additional layer to encode/decode the packets down to this interface.
Back to your situation. Enable a socket on the game and on the editor for communication. Then you need to be sure that the game and the editor are sharing the same game data (if you had the editor/game server in the same process, they could share the data in memory) - with your situation you have to ensure they're running off the same map file...
I'm going off on a huge tangent. If you want any more info drop me a mail and I'll explain things better.
[edited by - downgraded on June 10, 2004 9:18:22 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement