Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 11 Jul 2012
Offline Last Active Sep 25 2012 08:33 AM

Posts I've Made

In Topic: Design: Where would you program behavior for an object?

28 August 2012 - 06:15 AM

I use a data based design and do the behavior only with a scripting language like Lua.
This is cache friendly and extensible but it is much more complex and not really easy.

Every entity has his properties and you can access them via C++/Java/C#... with a hash map or a normal map (other containers are welcome Posted Image). The scripting interface can be object oriented, so that you will get an object pointer, where you can access the members and change the properties in an object oriented manner, or also be data based.

/* Stupid Example */
/* C++ */
Point pt = dataManager->property("block1", "pos").toPoint();
/* Lua - Object Oriented*/
function blockClickHandler (block)
	 Point pt = block.position();
/* Lua - Data Based*/
function blockClickHandler (position)
	 Point pt = position;

This above is really a simple and incomplete example but shows some ways.
Many big games (with scripting languages), applications and websites use data based design. I really suggest it!

In Topic: When to use multi-threading and when to not

25 August 2012 - 09:05 AM

Add threads only for performance reasons.
  • When you do a simple application, don't use them.
  • When you use heavy input and output operations or do other long tasks. Use predefined threads. Like two threads, first for the main loop and the second for asynchronous operations.
  • Or you want an scalable and fast application (mostly engines), then you should use task based threads (like TBB). But they are only useful for computers with more then two cores.
This above is a very weak classification. The need of multi-threading really depends on your design and your costumers.


In Topic: Is python fast enough for a simulation heavy game similar to Dwarf Fortress?

25 August 2012 - 08:55 AM

I'm currently developing an heavy simulation game and has already some experience with script languages in such an area. On some of my applications there were a very strong deceleration when I used Lua or plugin based dlls. Python Interfaces are not really different.

My fractal viewer was based at first on internal codes but this was bad and not really scalable. After that I used a very simple dll interface. The performance breaks down (nearly 30%!) . I also started a lua interface. The performance breaks down once more (nearly 50%!).

So on my opinion. Don't use scripting languages in big loops (10000 iterations and up) but you can use it for simple things.
This was my experience with scripting languages. I used lua the most of the time. But lua is a little bit faster than Python, so there shouldn't be much difference.


In Topic: Game Engine Programming

23 August 2012 - 12:25 PM

Great! It looks good :)
So now your engine has more graphic then my Pear3DEngine, haha :D

In Topic: Game Engine Programming

23 August 2012 - 11:22 AM

wow you just motivated me to make an account and get better at C++! Thanks!!

Really? Cool Posted Image It makes me happy and proud when I could help one person.

This probably does not affect the plans of the OP but still: Networking and prediction last? Yikes!I'd say work your way through the list but leave all sorts of networking out of your first engine. Then, when you fell like you would like to add networking, start over again (probably using the parts of the first engine that you feel are working well) but plan the engine with networking in mind from day one.
I implemented things like NAT punch through, lobby servers and matchmaking before my engine could even create a window, and it has really payed off. I feel this is the only good way to create a networked game engine. This might be why you feel that "networking is the worst thing you will have to deal with".
That said, you can probably create a fully functional renderer and use it in a networked game engine just fine, as long as the renderer is separeted from the game logic, but only start create the GAME engine systems when you have your network layer figured out.
Just my two cents...

I also think that Network shouldn't be the last option. But it is also not the most important part. Design the framework with Network in mind.
You need at first a good object and class system. But please not a huge hierarchy tree. Also one root class like the QObject class in Qt is not really useful in game development (but in GUI developing).
My second suggestion: Don't make the underlying classes too general. You will lost much power and performance and in the end you will get spaghetti code because everything is done with the preprocessor and the template system.
To make a sophisticated design, I recommend UML tools.


PS: And on my mind don't use something like a signal slot system and over think the use of callbacks. But this all is up to you.