4 replies to this topic

[Nickie]

Hello everyone!
I took a little break and started my engine from the beginning. Well I didn't lose my time with the first engine. I can finally construct easily readable and extendable code. (And follow good design patters, + avoiding the bad ones). However I still lack of experience in game programming. The next step is building an actor hierarchy.

There was a close topic to this soon, but there was an stupid question about the addresses and everyone was writing just about this. Shoud I implement an actor hierarchy and give an object unique ID? If yes, where should the id be assigned. In the level file? Or it should be generated on runtime(this is the case I used before) .
I use the ID's to synchronize between the separate threads(or just subsystems. Not all systems have own threads). However almost every system has a copy of the actor(Renderer is keeping a scene node representing the actor, Physics is keeping a rigid body for example).

However I was thinking about it. Is there another way of doing this. Is it just time consuming and doesn't give me anything back? What will happen if I try to implement a multiplayer open world game and I need to load the the object(actors) continuously over time? This means that I need to synchronize between the multiplayer clients, and still to generate new IDs. (I really have not thinked about the networking system).

Other ideas are for example to use text names for everything and "hash" them(not sure how to say this , but I think you have understood me)?
So, whats your advice?

[nife87]

If yes, where should the id be assigned. In the level file? Or it should be generated on runtime(this is the case I used before) .

How would you otherwise differentiate and cross-reference the different objects in a level file (or in any other saved form) if they do not have some sort of ID already? This might just be a unique name, but it is still an ID. You can always switch one ID-method out for another (they all have their strengths and weaknesses). For instance, you can use unique names (strings) in files for simplicity (easy to edit by hand) and then swap them out with integer ID's for performance when loading files using either hashing or a LUT (string->integer). The opposite is required for saving, of course. An editor (level editor) might do the conversion automatically for you - you use string ID's within the editor, but it only saves integer ID's (and possibly a LUT to display the original string ID's within the editor for re-editing the files).

Edited by nife87, 18 November 2012 - 07:18 AM.

[solenoidz]

How would you otherwise differentiate and cross-reference the different objects in a level file (or in any other saved form) if they do not have some sort of ID already?

Sometimes there is no need to have unique objects name. It's not a good idea to not have them unique, but it will work anyway in some scenarios. For example, not every tree in a forest need to have unique name. It needs to have unique transformation though..
Unique names could be used to reference objects of importance for the game play, via scripts etc.

[Krohm]

• Shoud I implement an actor hierarchy and give an object unique ID?
• If yes, where should the id be assigned. In the level file? Or it should be generated on runtime(this is the case I used before) .
• I use the ID's to synchronize between the separate threads(or just subsystems. Not all systems have own threads). However almost every system has a copy of the actor(Renderer is keeping a scene node representing the actor, Physics is keeping a rigid body for example).
• What will happen if I try to implement a multiplayer open world game and I need to load the the object(actors) continuously over time?

• In practice, I've found this is convenient but I guess there's no real "requirement" in the strictest sense. Keep in mind your internal systems shall probably not use this id, but rather interface to the structure directly.
• You'll find out you'll need serialization ids and runtime ids.
• So much for your statement about good practice. I'm afraid there's plenty of potential for error here. The easiest thing to point out is that putting your scene node directly in the renderer is probably not a good idea (separation of concerns, move this functionality to an external "driver" class). Using threads already? Uhm, I suggest to rethink your design.
• There's no "if". Don't write an engine. Write a game. That said, your game will have requirements. Is this scenario a requirement or not? For personal experience I can tell you that overengineering will get you nowhere in 99% of the cases.

[Nickie]

Well, I have now something to think about.

There's no "if". Don't write an engine. Write a game. That said, your game will have requirements. Is this scenario a requirement or not? For personal experience I can tell you that overengineering will get you nowhere in 99% of the cases.

I'm actually coding an game. However I need an engine for it. I have already got list of features which I will need for the game and nothing more. I had the problem of overengineering thats why it is called Round 2. However this is not a feature its is actually the core of the engine.
And yeah I'm already on 3 threads. The current separation I'm thinking about is:
1. Main Thread. Logic, Scripts, Physics, (Maybe rendering, I'll see how my game behaves and decide based on it)
2. Worker Thread 1. Loading files in memory(their content). Extracting archives into memory for example.
3. Worker Thread 2. Turning the raw data into something useful. (Create the texture object, Compile the shader and save the effect file(shader, I know effect is deprecated, or producing mesh structure from .obj)

I'm using event manager for the synchronization. Each thread has a task queue and the event manager has.

Hmh, I'll give myself 2-3 days before coding it. So everything can reorder in my mind. Thanks!