Jump to content
  • Advertisement
Sign in to follow this  
snufkin

Looking for feedback on my game engine

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

Hi!

 

I've started writing a game engine for PC (initially Linux only) for fun and giggles, and would appreciate some feedback on the design I've chosen. I've started writing some simple functionality (C++, OpenGL), but I think it's time to hear what you guys have to say. I've written a game (ish) for Android using OpenGL, but it turned out to be such spaghetti that I abandoned the project before I was even close to a releasable product. I found this article, and that's what I'm trying to achieve in my current engine.

 

As you can see in the sloppy UML diagram below, I've not really implemented much at all (empty classes aren't even created yet).

 

R3vKmC6.png

 

I have a couple of questions on how to proceed accordingly to the article I linked previously. HiminbjorgRoot is obviously the heart of the engine. This is the class that every game will inherit in order to create a game. In order to drive the game forward, is it "OK" for HiminbjorgRoot to keep an reference to each one of the Core* and *Manager objects and simply call their respective update methods, or does that go againt the principle of avoiding unnecessary coupling? Should the root class instead spam update messages on the bus?

 

I also wonder how each 3D model gets rendered to the screen. More specifically, I wan't to know about the relationship between the SceneManager and the RenderManager. Does the RenderManager keep a reference to every mesh (which then is sent to my non-existing draw() function in CoreDraw) or do the entities themselves in SceneManager listen on the message bus for a draw message, and then call CoreDraw->draw()?

 

The above questions are my main concern right now. I have a ton of questions, but they can wait until I've read your replies.

Share this post


Link to post
Share on other sites
Advertisement

Please consider this for a moment.

 

You fail at writing a game, as you cannot manage to get the structure correct. Next up, you try an engine, a thing that is a lot further up in complexity. An engine is at least as complex as a game structure, since the engine IS the game structure. It is more complex, because an engine is generic, it has to be usable for a whole lot of games, not just 1.

How good do you think your chances for a game engine are, if a relatively simple, single game is too much already at this time?

 

 

May I suggest you shelve your engine idea for now. Instead, learn to write games, understand their structure. Look at structure of other games. Discuss structure. Once you are comfortable with that, read the article again, and try to understand how your knowledge fits in that idea. If you can do that, you'll be in a much better position to bring it some form of success.

Share this post


Link to post
Share on other sites

What BFG says is what has worked in my experience, and I've started about a dozen different game engines, each time failing to have the foresight or experience necessary to prevent the inherent issues in each project's design. It wasn't until my last project that I'm working on right now, and have 95% completed, that I was able to see all the pieces in their entirety, and how they all come together, allowing me to actually create a game engine that worked, and that games could be made out of.

 

It also really depends on what functionality you want which bears the questions: what kind of games do you want your engine to run? do you want multiplayer capabilities? what sort of graphics capabilities do you want it to have? do you want physics? how detailed should the physics be? are you loading models/textures? are you animating models? do you want particles? ad nauseam.

 

All of the answers to these questions affect a lot of things about an engine, and a generalized basic unassuming core engine design is going to be just that: basic and making no assumptions. It's not going to do anything at all, not until these questions are answered and the engine itself can actually have some meat to it. There are a million ways to write an engine, but it's nothing without the things that will make it capable of actually presenting a game.

 

Personally, I got stuck in the engine architecture stuff for a while completely second-guessing everything I came up with. Eventually what it came down to was actually writing code, and writing and writing, and then seeing what I did wrong, and doing it over again, usually re-using a lot of code - that had to be written in the first place in order for me to re-use and integrate into a re-write. Each iteration refining bits and pieces of the code I was re-using, and really as BFG says, just refactoring the whole engine. Over time I had something viable.

Share this post


Link to post
Share on other sites

You have 4 "Managers". You wouldn't even go 4 seconds beyond one of my DRs (Design review).

What does the "sceneManager" do? How would you implement 3D graphics AND 2d graphics with this "render manager"? How'd you make shaders work? 

Where is your support for audio?

What about networking? debugging helpers? Math? 

 

Before designing something on your own, try to review existing frameworks and engines.

the SFML is a really nice example. It has few classes and a good project seperation. 

Edited by WoopsASword

Share this post


Link to post
Share on other sites

Nice UML diagram.  That is about it really though. As others have mentioned there isn't enough details in this diagram to tell what really is going on.  

 

The one item I would recommend you thing through a little more is the Input system.  You have two classes which look like they do the same job but are just called something different.  You may find doing a little abstraction here might help make your engine usable with not only a keyboard and mouse but maybe a joystick or touch screen.  Another thing to think about here is how will you manage allowing players to customize they key commands?  Sure WASD is used a lot to move around in a game but what if I'm used to using the arrow keys because I'm left handed or say IJKL instead?

 

As others have said start programming and see what happens.  Try a few things out and see what happens.  If the code breaks or doesn't work as expected then go back to your diagram and make some adjustments.  Iteration here is the key and don't be afraid to make mistakes.  We all do and most of the time you learn more from it.

 

Lastly if your serious about making a game engine then start building up your reference library.  Find as many books and articles you can on the subject and read as much as you can.  Using one article for reference isn't always the best way to get a better understanding of the subject.  

Share this post


Link to post
Share on other sites

I think @[member='Alberth'], smashed the nail on the head. If you can't complete a game the odds of you completing a game engine is much lower. A game engine has at LEAST as much complexity as a game engine and in most cases a game engine is FAR more complex.

Please take some time and build a game. Understand how you built it and grow from there.

Share this post


Link to post
Share on other sites

Yes your diagram is too generic and certainly too little. Yes you failed to finish a game because your code became too messy.

But anyone can learn from failures. So if this is your way, do it.

Or if some doubts arose from the answers you got, then try a different approach. Try to do another game, with keeping a clear code for example.

And later, maybe you'll feel more comfortable with some aspects or others and  you'll consider writing an engine, or a full game, or be a part of a more important project.

 

Just my 2 cents.

Share this post


Link to post
Share on other sites

I have some points in your design approah that in my opinion shouldnt be that way for example your root object. It may be working practice in a bunch of big engines that you need something like a root object to design any other manager/class/whatever on top of but you should consider the real use of the class you are creating and then the value gain of using a root object. You will be in specialising your root object in most cases so the value gain is near zero.

 

I in my Engine use only one root object and this is because of the strict memory managing model that needs any struct/class accessing the heap to have its own reference to an allocator class of certain type. Any more is not necessary and you will see that for example on looking into Unity 3D where for example a Manager class in the scene has also transform, light and collision values from the root object.

 

Another design issue is the point any on the paragraph "call CoreDraw->draw()". Managers normaly should not have any references to each other and wont have a global draw() function however. Your scene manager should basicly be something that is a more advanced node graph of objects containing the scene structure and relationship between each of your models inside it. This can then easily decide what object trees to render from root to parents and how transforming is done. A renderer dosent need any of that informations but the order how objects should be drawn and not only from the scene manager but also from UI and post processing.

 

If you want to go forward with your project for learning purposes then you should skip the article as your main source and instead read the book Game Engine Architecture 2nd Edition. This is a very good start to get inside engine development therories

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!