• 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
Nickie

Developing a game engine. Round 2.

4 posts in this topic

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 :D, but I think you have understood me)?
So, whats your advice?
0

Share this post


Link to post
Share on other sites
[quote]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) .[/quote]

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
0

Share this post


Link to post
Share on other sites
[quote name='nife87' timestamp='1353244522' post='5002025']
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?
[/quote]

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

Share this post


Link to post
Share on other sites
[quote name='Nickie' timestamp='1353230318' post='5001989'][list=1]
[*]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?
[/list]
[/quote][list=1]
[*]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 [b]not [/b]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.
[/list]
1

Share this post


Link to post
Share on other sites
Well, I have now something to think about.
[quote]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.[/quote]
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!
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