Jump to content
  • Advertisement
Sign in to follow this  
IcarusX

Game engine architecture

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

Hello,

I'm looking to develop a basic cross platform multi threaded game engine and would like to get information on what the best way to structure my classes would be.

I've seen a lot of tutorials using a Singleton as the main 'Engine' class for an application; however I've read that this is less than optimal.

What are the possible substitutes for this architecture?

Thanks,

IcarusX

Share this post


Link to post
Share on other sites
Advertisement
I've done my fair share of game programming.

I've mostly been doing single platform console programming work the last couple of years. I would just like to get a good modular yet coherent system together. :)

Any experiences from people that have built such a system is appreciated.

Share this post


Link to post
Share on other sites
There is nothing basic about a cross platform, multi threaded, anything.
Follow the tutorial. Then remember that a tutorial is just that. It is trying to teach one thing any thing the tutorial does outside of its area of focus should be highly suspect for being out right wrong. Anything inside of its area of focus should be highly suspect for being simplified for "educational purposes".

Tutorial code should be thrown away after you have learned from it. If it is the best tutorial code in the world you might consider using it after a thorough design review and code review.

Share this post


Link to post
Share on other sites
Quote:
I've mostly been doing single platform console programming work the last couple of years. I would just like to get a good modular yet coherent system together. :)
Are you sure there's not already an engine out there that would meet your needs? There are many, many engines (both free and commercial) targeting many different platforms currently available.

Anyway, a couple of questions:

1. What platforms do you want to support?

2. What language(s) do you want to support?

3. Why does it need to be multithreaded? (In other words, how do you see threads being used?)

Share this post


Link to post
Share on other sites
Quote:
1. What platforms do you want to support?

A great deal of mobile devices and tablets that run OpenGL ES, PSP, 3DS (When its released), Xbox360 and PS3. I am aware that you need access to official devkits; that is not a problem.

I will implement a separate renderer for OpenGL ES 1.x and 2.0. As a first version I'm just looking to implement the basics for mobile and OpenGL ES based devices but want to be able to implement other renderers and such if needed.

I want a central toolchain for these platforms, and the reason why I want to build the basic version myself is so that I have intimate knowledge on how it is built.

Quote:
2. What language(s) do you want to support?

C++, perhaps a scripting language but that can be added without problems later.

Quote:
3. Why does it need to be multithreaded? (In other words, how do you see threads being used?)


Mainly to get the most out of future mobile hardware and consoles. Tegra2 based mobile phones will be released in Q1 2011 and they will have a dual core 1,5ghz chip. I can see the renderer running on one thread and the logic/physic simulations on the other one.

Share this post


Link to post
Share on other sites
Quote:
Original post by IcarusX
I've seen a lot of tutorials using a Singleton as the main 'Engine' class for an application; however I've read that this is less than optimal.


I'm trying to figure out how this would be less than optimal?

There's only a couple of ways of making the pointer to the engine class available to other classes:

Make it global, which probably would be faster, but probably would end up being a coding nightmare, and some platforms have issues with bare global variables.

Make it a public member of a class or wrap it with an accessor function.
Either way, you still have to have a pointer to wrapping class, that contains either the engine class pointer or an accessor function. So, again you're down to a global somewhere, or limited access to the engine.

Make it a singleton. The cost for this is a static function call, a failed NULL pointer check (except for the first time), and returning a pointer. I can't see how this would be any slower than calling an accessor function in a class to get the engine class pointer.

Share this post


Link to post
Share on other sites
Quote:
Original post by cdotyMake it a singleton. The cost for this is a static function call, a failed NULL pointer check (except for the first time), and returning a pointer. I can't see how this would be any slower than calling an accessor function in a class to get the engine class pointer.


I meant this from an architectural point of view.

Share this post


Link to post
Share on other sites
Quote:
Make it a singleton. The cost for this is a static function call, a failed NULL pointer check (except for the first time), and returning a pointer. I can't see how this would be any slower than calling an accessor function in a class to get the engine class pointer.
I'd suggest not making it a singleton. If you're interested in writing object-oriented code, pass references to objects forward to those modules that need access to them. If you want to go the procedural route, just make it a global.
Quote:
Make it global, which probably would be faster, but probably would end up being a coding nightmare, and some platforms have issues with bare global variables.
How would using a singleton create any less of a coding nightmare than using a global? A singleton is essentially a global anyway (with the additional constraint that there only be one in existence at a given time), so I'm not sure why the implications of using a singleton would be so different than the implications of using a global.

Also, what do you mean about some platforms having issues with bare globals? (I'm not doubting you - I've just haven't heard of that myself.)

Note also that if order of construction is an issue, you can make the global available through an accessor function (similar to how you'd expose a singleton instance).

Share this post


Link to post
Share on other sites
Quote:
Original post by cdoty
I'm trying to figure out how this would be less than optimal?

Each time singleton is accessed, it needs to be locked while it does its work. Which is the exact wrong way to go about heavily concurrent architectures that prefer to replicate state across multiple threads to achieve isolation.

Imagine a singleton on GPU. 400 cores, but only one of them can access the texture at any given time.

Quote:
What are the possible substitutes for this architecture?

That depends on each individual platform that should be supported.

A heavily data-centric architecture is likely the most portable, since it has no direct architectural disadvantages on any platform and allows careful control over allocations. As opposed to mostly OO design. The data parallel parts tend to fairly straight-forward to off-load to GPU as needed/available as well.

Quote:
A great deal of mobile devices and tablets that run OpenGL ES, PSP, 3DS (When its released), Xbox360 and PS3. I am aware that you need access to official devkits; that is not a problem.

First, gather architectural documentation on all of those.
Read it.
Make a table of lowest common denominator for all those platforms. Provide extension paths for subsets of features.
Design architecture around that.
Implement it.

The above is a proven and reliable method to go about system integration.

Quote:
I've mostly been doing single platform console programming work the last couple of years

Take what you learned there, apply the concepts to other platforms. When something doesn't work, find a better generalization.


A better question would be - how to test it. Just the PC testing will require a lab, likely off-shore, with a large number of full-time employees, and with access to all the hardware (hundreds of graphics cards, mobile devices, devkits, enough power to run it, enough room to store it, with S&H costs on top of it, with proper back-end infrastructure to manage all of that.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!