Sign in to follow this  
Geomaster

A question about project design

Recommended Posts

Hello everyone!
I've been lurking awhile on these forums and finally decided to register, because I am unsure about something, and I would like to hear your thoughts on this.
After some experience with software engineering and game development with APIs such as Bullet & NVIDIA PhysX (physics), Ogre & Irrlicht (3D rendering), OpenAL & irrKlang (sound) and a couple of others, I decided to start writing a small game studio, which would accommodate common tasks such as building a 3D world with respect both to graphical and physical representation as well as some things that I commonly need to do when writing a game. I am well-aware that there are studios like this already, but I'm doing this for the sole purpose of improving my skills and experience. I don't expect writing something big; just a studio that would help me build my experience and also ease some tasks for me in the future.
So, I have written a minimal wrapper around PhysX which connects Ogre and PhysX together and synchronizes them so they are seamlessly integrated. However, it's still far from the optimal solution (which would include a customized scene manager for Ogre) but it works neatly so far although I plan on swapping it with a more efficient solution.
However, when projecting this small game studio, I have stumbled upon a kind of a problem. The studio would need to communicate directly with interfaces of Ogre, Bullet (or PhysX), OpenAL etc. I see this as a somehow bad practice because some API-specific behavior would be hardcoded into the application. That would make replacement of Ogre with, for example, Irrlicht, very troublesome.
However, solving this would require me to build a wrapper that would be used to call Ogre functions. The wrapper would not have any Ogre-specific functions in the interface, so replacement with another engine would be pretty easy. However, that would introduce practically rewriting Ogre's interfaces, and, since Ogre uses its own resource and memory management systems, it would mean duplicating these in the wrapper interface (because the code that accesses the wrapper shouldn't rely on the API-specific resource and memory management). The aforementioned would need to hold for physics and audio libraries, too, so I would wind up writing thousands of lines of code for something that has been already done.
So, my question to you is, what should I do? Use the code in the studio for direct communication with the APIs, or build a wrapper around each of the APIs used? What would you suggest, and is there a more efficient and better way of doing all this? I consider the second option only because the first one seems like a bad practice, but I'm not nearly as experienced as some of you, so I assume that you could draw the right conclusion.

Looking forward to hearing your thoughts.
Thanks for reading all this, and thanks in advance for your replies :)

Share this post


Link to post
Share on other sites
[quote name='Geomaster' timestamp='1305664732' post='4812086']
I am well-aware that there are studios like this already, but I'm doing this for the sole purpose of improving my skills and experience. I don't expect writing something big; just a studio that would help me build my experience and also ease some tasks for me in the future.[/quote]
The most valuable skill to learn is to not reinvent the wheel.

The second skill to learn is to define razor sharp goals. What, why, how, how much, where and when.

- Why do APIs need to be modular? Why must one be able to swap them out. This is expensive, takes a lot of boiler-plate code and effectively multiplies any additional effort due to testing. But if it's a crucial feature, then it must be done, so added time and cost is not a problem, it's a requirement.

[quote]it works neatly so far although I plan on swapping it with a more efficient solution.[/quote]If it works it's done. When engineering, there is no "more efficient". It's a binary condition. It either meets all the requirements or it does not.

The SE landscape has proven this over and over. The "might need it in the future" never ever worked. Unless the needed features were completely understood and "in the future" simply meant according to some plan, where the rest of the work took long enough.

What efficiency problems? What alternative? Which API will be used to replace it? When? How will the migration be performed? What about backward compatibility? If you know there is something more efficient, use it now.


[quote]So, my question to you is, what should I do?[/quote]
For one, I would not be trying to write yet another middleware solution. Especially not in an area where I didn't have 10 years of hands-on experience. That's a bare minimum to thoroughly understand all the actual needs and gain enough domain-specific knowledge.


You are building a tool. A tool must be *useful*. Any effort that goes into it must not be into polishing the tool, but optimizing its usefulness. And for any middleware today it will take years just to catch up to existing solutions.

Usefulness of such middleware is measured in time needed to produce intended projects compared to similar tools. Or, you would produce 5 games and observe it only took you the time it would to produce 2 with some other tool.


At very least, this is the Software Engineering question. Once you are sure about why, the code will follow, even if it means writing millions of lines of code.

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