Jump to content
  • Advertisement
Sign in to follow this  
extralongpants

Unity How separate should my libraries be?

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

I came by this comment:
Quote:
Original post by hplus0603 ... What I will suggest, is making sure that you define a small core set of things that every piece of your engine depends on (say, memory management, reference counting, logging and error handling) and then making sure that every other module (file I/O, sprite management, input, windowing, etc) is independent from every other module in implementation and interface. Where you need to hand off data from one to the other (file I/O -> sprite sheet -> 2D rendering), you define interfaces that make piping one into the other easy, but you keep the actual implementations cleanly separated.
in this thread, and a few questions came to mind: How separate should my libraries be? What should my 'core' library contain? Should libraries depend on libraries other than the 'core' library? In my current project, my gui library is dependent upon my input library, which, in turn, is dependent upon my core library. Would this be considered 'bad' design? None of my libraries are interdependent, that is, there are no two libraries that both depend on each other, but I do have libraries that form a sort of chain. I haven't run into any problems as a result, and I can't really predict any. Another concern of mine is that my core library seems to grow every day. It seems to want to grow large enough to encapsulate my whole engine (I can personify a library, because I'm awesome). I can see how keeping libraries totally separate might reduce the amount of resultant changes one might need to make after altering a part of a depended-upon library, but is it really worth it? It seems like a lot of effort to make interfaces between libraries. I suppose I would just like to hear your opinions on the matter and what your practices are, in terms of module-based engine development. Thanks in advance for any input.

Share this post


Link to post
Share on other sites
Advertisement
Writing a game without internal dependencies is something of an oxymoron, or at least an utopian vision of the "ultimate" engine design..

You could pretend that they're not there by writing advanced event systems or always letting the main application shuffle the data around. But it doesn't remove the fact that any (resonably complex) game will be littered with dependencies.
Don't get me wrong, you should reduce your dependencies. It's just that you won't get rid of them all so trying to hide the necessary ones might not be such a good idea.

Personally I'd spend my time cleaning up the external interfaces instead.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
There is no easy answer to this. Game engine design is one of the hardest in software design. The only thing that will help you is experience, and also reading lots of other things. I recommend you browse around the c2 wiki a bit

http://c2.com/cgi/wiki?WelcomeVisitors

Also, it's best to have a bad design that works then a good design that doesn't work. But always try to refactor your code to clean things up as you go along. Again, there are no easy answers to software design. experience is really the only way. so just start coding! :)

Share this post


Link to post
Share on other sites
Thank you for the replies. I suppose I was hoping for these kind of answers (it means I'm headed in the right direction). I figured it was a bit ridiculous to write interfaces etc., instead of just using the classes one took so much time in making useful. Thanks again, I really appreciate it.

Share this post


Link to post
Share on other sites
I like this topic a lot, so here's my 2c on this, everyone's right, there's absolutely no way (at least to date) of doing the "utopia-design", however I do feel there are somethings you should feel that need to be "seperated"

a game could be divided into several components.

The following components should NOT be dependent on the "core library - i.e. the game"

----
GUI - Things such as the menu
3D graphics Engine - Things that handle all the rendering of the game itself.
Input - Handles Initialization of Keyboard/Mouse or other devices and their feedback.
Collision Detection - Handles collisions between primitives.
(and anything similar to this)
----
They should be easily removable and replacable, as they should behave like "helping" classes

Now...
The core library, can be divided into several smaller components, which by all means can be interdependent, but limit this, because when you want to change anything... you wouldn't want to spend all week on it, finding all its dependencies.

The above can be easily illustrated by a simple class for Person, and inheriting that for more "specialized" people that DO only specific things. e.g. You could make a Person class dependent on the Statistics class, which might handle events like Health etc.

The Core part of your game will ofcourse have a lot of "hand-coded" things, the logic of the game, and this is to be expected, how generic are you willing to go?

Anyway, group things logically and there'll be no problem really, I'm sure experience will guide everyone in the end... just like everyone plays solitaire differently :)

-Ixeus

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
there is nothing wrong with a layered approach to library design. for instance:

hud depends on 2d depends on vertex buffer

one thing to avoid is circular dependencies, like:

2d depends on vertex buffer, vertex buffer depends on 2d

because then you can separate/reuse vertex buffer without 2d




Share this post


Link to post
Share on other sites
Quote:
Original post by Ixeus
I like this topic a lot, so here's my 2c on this, everyone's right, there's absolutely no way (at least to date) of doing the "utopia-design", however I do feel there are somethings you should feel that need to be "seperated"

a game could be divided into several components.

The following components should NOT be dependent on the "core library - i.e. the game"

----
GUI - Things such as the menu
3D graphics Engine - Things that handle all the rendering of the game itself.
Input - Handles Initialization of Keyboard/Mouse or other devices and their feedback.
Collision Detection - Handles collisions between primitives.
(and anything similar to this)
----
They should be easily removable and replacable, as they should behave like "helping" classes

Now...
The core library, can be divided into several smaller components, which by all means can be interdependent, but limit this, because when you want to change anything... you wouldn't want to spend all week on it, finding all its dependencies.

The above can be easily illustrated by a simple class for Person, and inheriting that for more "specialized" people that DO only specific things. e.g. You could make a Person class dependent on the Statistics class, which might handle events like Health etc.

The Core part of your game will ofcourse have a lot of "hand-coded" things, the logic of the game, and this is to be expected, how generic are you willing to go?

Anyway, group things logically and there'll be no problem really, I'm sure experience will guide everyone in the end... just like everyone plays solitaire differently :)

-Ixeus


So by the 'Core', you mean the game-specific code? What I meant by the 'core' is the library containing things that every other library might need, like a serializer or a memmory manager (very low-level stuff, I suppose). I just wanted to clear up any confusion, in the event that you misinterpreted some of what I said. In any case, thank you for the input, I will definately keep what you said in mind.

Share this post


Link to post
Share on other sites
Odious, a great book to check out is Robert C. Martin's "Agile Software Development" (linky). While at first glance, it looks like the book focuses on agile development, it actually focuses more on object-oriented design principles.

You will learn things like the "Single Responsibility Principle", the "Open-Closed Principle", the "Liskov Substitution Principle", the "Dependancy Inversion Principle", the "Interface Segregation Principle", etc. It also goes into package dependancies (like you were discussing), and discusses how to determine whether your libraries are properly connected or not.

If you learn these principles and take them to heart, you will be a LOT more capable of a software designer. Anything you learn about just software architecture in general will help you immensely with game engine design.

Some other books that are must-haves for every serious software developer:

Design Patterns, by the Gang of Four (linky)

Refactoring, by Martin Fowler (linky)

UML Distilled, by Martin Fowler (linky)

Patterns of Enterprise Application Architecture (linky)

This is just a start too. There is a lot of good information out there on software architecture in general.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!