Sign in to follow this  

Starting a new engine

This topic is 4202 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

Ok so I have been working on a game for the last two years in Torque. I decided recently that although Torque was great, I wanted to build my own game engine, so here is what I to do with the engine. I want to build the engine on C#(new to me). I want to eventually use a DirectX 10 version of XNA, but for now I will be using MDX. This game will be released late 2007 or early 2008, and so I'm hoping XNA in DX10 form will be released. Now a tough decision was deciding what physics to use, will PhysX or HavocFX be dominate next year? I decided to use PhysX because they allow free use of the SDK at development stage, and for good if the game uses the hardware. So right now I'm writing the graphics engine in C# MDX and I want to optimize the engine to use multiple threads(ie. physics/AI), How should the engine design look? I was thinking something like this, Graphics Engine- has a scenegraph, can do stuff like Robot newRobot1 = new Robot(_device, @"robot.x", new Vector3(0.0f, 20.0f, 100.0f), 1f, 10.0f, fireSound, moveSound); newRobot1.position(2, 4, 0); // I think this is directX to move mesh to position newRobot1.setmovedest(2, 2, 0); // This would be my own function to walk the robot to his destination, it would move the robot object, not just its mesh basically add simple collision in here too Now how about physics, how would this work with my graphics engine? Does anyone know how(or the best way?) someone might implement PhysX into a new game engine? Thanks for any help. also I'm comfortable using C++ and unmanaged directX, would it be better for me to stick with C++ and then use DirectX10?

Share this post


Link to post
Share on other sites
Among many important thing, you have to be aware that a gane engine is so much more than a graphic engine.

Game engine must (perhaps in a multithreaded fashion):
- handle graphics
- handle sound
- handle physics
- handle data
[- handle network]

and last but not least:
- handle logics

Since this last point refers directly to "how will people (or yourself) use your engine", it is dramatically important. Thinl about simple situation. Imagine you want a NPC to walk and avoid a fieldmine. How will you express that ? How will you create and integrate a game scenario with your engine ? When you say
newRobot1.position(2, 4, 0);

where do figures 2, 4, 0 come from ? You think its just a detail ? it isn't ;)

What sort of data will your engine use as input ? What software will you create your levels with ? (or will it be procedural content ?)

So I'd say that you dont have to have a perfect design but at least it must be clear in your mind how things will work when you want to use your engine to create an actually playable game (for that is what it's meant for)

Share this post


Link to post
Share on other sites
Thanks for the replies so far,

I'm thinking of using raknet for the network.

I want to create a scene editor once I get a simple scene graph working nicely.

I already know how to create the scene graph, and to move objects around, I even know how to create the scene editor used to create/move objects.

What I don't know is how much(or what) I should be letting the PhysX engine handle, from what I understand PhysX can create actors and load meshes, however I was thinking that instead of letting PhysX handle the scenegraph in such a way, that my game engine would handle it, I'm not sure if I'm making sense, here are some examples of what I mean.

Ok so my question mainly is, should I code the game like this,
Player clicks on the terrain and units moves there, all handled by the engine
Actor is created in the scene graph and the move function coded in the engine.

or like this,
Player clicks on the terrain and units moves there, the actor is created by PhysX and the movement is handled by PhysX, so basically all my engine would be is a graphic engine..?

This might be more of a PhysX related question than anything, I will look at how Irrlicht integrated PhysX and see how that works.

Share this post


Link to post
Share on other sites
Quote:
Original post by janta
Among many important thing, you have to be aware that a gane engine is so much more than a graphic engine.

Game engine must (perhaps in a multithreaded fashion):
- handle graphics
- handle sound
- handle physics
- handle data
[- handle network]


I full agree. It also needs to handle:
Memory
File systems if you're multiplatform
Resources
Logging
Errors
Window Creation and OS events (some do some don't)

Amoung others

Quote:

and last but not least:
- handle logics

Since this last point refers directly to "how will people (or yourself) use your engine", it is dramatically important. Thinl about simple situation. Imagine you want a NPC to walk and avoid a fieldmine. How will you express that ? How will you create and integrate a game scenario with your engine ? When you say
newRobot1.position(2, 4, 0);

where do figures 2, 4, 0 come from ? You think its just a detail ? it isn't ;)

What sort of data will your engine use as input ? What software will you create your levels with ? (or will it be procedural content ?)

So I'd say that you dont have to have a perfect design but at least it must be clear in your mind how things will work when you want to use your engine to create an actually playable game (for that is what it's meant for)


Now with this I completely disagree. The engine should have NO clue about any of this. You tell it to render object A at position B and it does. Unless the engine is a one time use only thing (why?) do not tie any game aspects into it at all. The engine should care not if object A can speak or interact with the user. It gets input and passes it onto the game. The game takes that input and makes changes to data held within the engine (rotates something, translates another, etc) and then tells the engine it's time to render the scene again.

The engine and the game should be completely seperate projects. That is if you ever wish to use the engine for another project without taking weeks or more to extract and remove game logic from it then trying to fix it to run away.

Share this post


Link to post
Share on other sites
Quote:
Original post by Warvstar
Thanks for the replies so far,

I'm thinking of using raknet for the network.

I want to create a scene editor once I get a simple scene graph working nicely.

I already know how to create the scene graph, and to move objects around, I even know how to create the scene editor used to create/move objects.

What I don't know is how much(or what) I should be letting the PhysX engine handle, from what I understand PhysX can create actors and load meshes, however I was thinking that instead of letting PhysX handle the scenegraph in such a way, that my game engine would handle it, I'm not sure if I'm making sense, here are some examples of what I mean.

Ok so my question mainly is, should I code the game like this,
Player clicks on the terrain and units moves there, all handled by the engine
Actor is created in the scene graph and the move function coded in the engine.

or like this,
Player clicks on the terrain and units moves there, the actor is created by PhysX and the movement is handled by PhysX, so basically all my engine would be is a graphic engine..?

This might be more of a PhysX related question than anything, I will look at how Irrlicht integrated PhysX and see how that works.


Player clicks mouse, engine gets this event and fires off an internal event to whatever you have listening for it in your game (game registered this earlier). Game decides what to do (move object A and B to new position). Event is fired from game to engine, engine makes the needed changes after consulting the collision detection code, if all is right Scene Graph or whatever is updated. Your game tells the engine to render (or its on a set timer).

Keep game logic and engine seperate as much as possible unless you never want to use this engine again :) Using things like PhysX, RakNet, etc are excellent ways to speed up development.

Share this post


Link to post
Share on other sites
Thanks for the replies, I'm still deciding what I want to use for scripting though.

I can't seem to find any good scripting engines for C#, LUA apparently does not work nicely with C#.

Crysis looks amazing btw.

Share this post


Link to post
Share on other sites
Quote:
Original post by Warvstar
Thanks for the replies, I'm still deciding what I want to use for scripting though.

I can't seem to find any good scripting engines for C#, LUA apparently does not work nicely with C#.

Crysis looks amazing btw.


If you want, you can use C# for your scripting as well as your engine. You can compile files at run-time and discover their methods and types using reflection. I'd imagine this would be faster than using an interpereted language for your scripting.

Share this post


Link to post
Share on other sites
Quote:
Original post by Mike2343
Now with this I completely disagree. The engine should have NO clue about any of this. You tell it to render object A at position B and it does. Unless the engine is a one time use only thing (why?) do not tie any game aspects into it at all. The engine should care not if object A can speak or interact with the user. It gets input and passes it onto the game. The game takes that input and makes changes to data held within the engine (rotates something, translates another, etc) and then tells the engine it's time to render the scene again.

The engine and the game should be completely seperate projects. That is if you ever wish to use the engine for another project without taking weeks or more to extract and remove game logic from it then trying to fix it to run away.


Sorry I should have been more specific. A good game engine IMHO knows how to handle game logics, but the game logic itself remains completely outside of the engine. What I call "handling game logics" is the part of logic code wich is re-usable, that is some code that provides level designers with facilities to write game logic (interfaces for example) If not integrated to the engine, you will end up rewriting it for every project. Thus the game engine I thought of is actually completely reusable, and is a reliable ally for anyone who wants/need to prototype a game quickly.

I think the design which is in your mind is a .exe game / .dll engine, whereas in my mind its the exact countrary. Thus I see the engine as the piece which orchestrates everything: loading, rendering, updating objects( calling their logics, their physics, their animation and so on) etc.

Both approach are perfectly valid imo.

Share this post


Link to post
Share on other sites
Quote:
Original post by smr
Go through some of the tutorials for some popular 3D engines such as Ogre and Irrlicht. See how they do things. They might provide you some insight into how you might like to build yours.


Download the complete source to the first release for the irrlicht engine, v0.1. It really gave me a lot of insight into how things needed to be organised. And, if you've already got a basic idea about rendering and objects, the only other thing you need to get starting is to know how objects (objects, renderers, scene managers, etc) will be organised in a coherent fashion, so it is easy to use, but efficient and effective.

Share this post


Link to post
Share on other sites
Quote:
Original post by Warvstar
I can't seem to find any good scripting engines for C#, LUA apparently does not work nicely with C#.
Incorrect, Lua works perfectly fine as a scripting language when used from .NET through a P/Invoke system like LuaInterface. It's just that there are better and easier solutions out there for scripting in .NET:
  • IronPython is a Python implementation for the .NET Framework. I've seen a number of neat videos featuring it being integrated directly into the IDE.
  • Boo is IronPython's close cousin, targeting both the .NET Framework and Mono, making it an excellent choice for cross platform solutions.

The good thing about using one of the above solutions is that it allows you to use your C# code directly from the script. You can call your C# functions and methods and create objects of your C# defined classes. If you were to be using LuaInterface, you'd have to manually bind all the wanted functions to Lua itself instead of just adding the reference to the script and using it directly.

I've been using Boo in BooGame and it has been working very nicely. If you need help on how to get Boo working in your application, BooGame has a Script class which wraps the compiler and interpreter interfaces into one managable system. Just take a look at Script.cs .

Share this post


Link to post
Share on other sites
Right now we're using C# as our "scripting" language. It's nice having such a mature IDE to work with! Though I'm 99.9999% C++ and engine guy so I cannot speak too much about it.

@janta: No problem figured its what you ment but didn't want the OP getting confused. But what if you want to take your "engine" from a FPS to a RTS. That logic needs to be rewritten anyways. But now it might be tied too much into the engine to allow fast prototyping. Since we're at the very early stages we're looking into issues like these. One idea was to handle the transition from logic to engine in C#, which gets it data from XML files etc (for AI and the like). Then we can make a nice graphical interface for the level designers, world designers that can drag and drop set "actions" into a "bucket" and make new "actions" simular to how UE3 makes shaders. They can then change each variable to make it totally custom.

Since we have a console up, a DOS box basically with two way communications, the designer can easily make changes in the editor, save the file, order the game to reload it and instantly see the results. Even "unwinding" time a few seconds to replay the exact same instant in the game tweaking the "action" until its perfect.

This is a very general overview, sorry if it doesn't make sense.

Share this post


Link to post
Share on other sites

This topic is 4202 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