Jump to content
  • Advertisement
Sign in to follow this  
isbinil

Making a NOT library dependant game engine : useful?

This topic is 1340 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 was bored at work so i started to make general c++ classes to facilitate an hypothetical game development.

I made a Game class that can store States, an Entity class that contains a hitbox and can handle collisions on another Entity, a 8-directions movement inheriting from Entity and handling acceleration/deceleration, a Tilemap class able to handle collisions with Entities and load/save to binary file, a Camera class allowing smooth target following (you can set its x/y target and get its viewport x1 x2 y1 y2 to do what you want with...)

 

But those classes don't use any library (except the c++ standard library) so they don't do any drawing or input handling. For example the Tilemap can't draw itself, but you can inherit your game-specific tilemap class and access the whole array directly to draw it with a graphics lib. The 8-directions movement don't take any input it's just a function "move(int direction)" you'll call yourself after detecting a key press using your input library.

 

I am wondering, is having a non-library-dependant game engine/framework worth? it's a good or bad practice ? I like the idea, but i dunno if it's a good way of organizing the code.

 

I haven't tested it on a real game but it sounds good, for example when developing your game you'll made some Player, Enemy or whatever classes inheriting from Entity then adding some library dependant code (graphics/input/sound) to make a fully working object for your game. For Game states you just have to make inherited classes (Level, Menu...) and override the Input, Update and Draw methods.

 

I searched for game frameworks on google but can't find anything similar, they all include all the stuff like drawing into the engine. What's best practice ? Am i losing time doing this ? 

 

Thanks ! tongue.png

Edited by isbinil

Share this post


Link to post
Share on other sites
Advertisement
You're losing time. It's basically reinventing the wheel. However, if you're doing it for personal educational purposes, it can be useful to you (but not necessarily to the game engine).

The only time a library is really a problem is when it has restrictive licensing attached to it (or, of course, if it's just not a very good library). Well-made free libraries with permissive licensing are always useful and don't have any significant drawbacks.

Share this post


Link to post
Share on other sites

I admit I have a problem with optimisation, i often reinvent the wheel because all software i find is so much bloated and un-optimized to me... yes it works, but i hate this... and it makes me lose time sad.png . i'd like to make my own optimized wheel to stop reinventing it every time. maybe i'm wrong, but when i see some people writing 100+ lines of code for implementing the separated axis collision method where i can do the same with 20 lines i can't resist. it's easier to understand, looks better to the eye, is faster to execute...

 

if i continue developing my library, do you think i need to keep it library-independant, or should i add all the graphical stuff and other (opengl, window handling) ?

Edited by isbinil

Share this post


Link to post
Share on other sites

if i continue developing my library, do you think i need to keep it library-independant, or should i add all the graphical stuff and other (opengl, window handling) ?

 

I'm not sure what you're asking.

 

Keep it as focused and made for a specific use as you can.  E.g. is it a physics library, or is it a graphics library?  Try not to do everything.  If one of your tires is blown, just replace that tire.  Use as much existing code and other libraries as you can.

Share this post


Link to post
Share on other sites

it's a game engine that have no I/O  xD  (no graphics, no keyboard/mouse handling, no sound^^). I think it could work well with SFML/SDL (all multimedia libraries that doesnt provide game-related stuff)

 

thank you for your advices, i'll improve it while i develop a new game

Share this post


Link to post
Share on other sites

I think... what you are trying to say is that this game engine has literally.... no libraries. And no Draw code. No usability?

 

I wouldn't actually call this a game engine if this was the case. This type of design sounds better for games that are suppose to play themselves. A screen savor if you will... only it doesn't draw anything... so I guess it just warms the processor?

 

 

On an optimistic point of view. It's a library. That does provide a good heap of the backbone structure of a game engine. But I think there is also a reason why we don't actually see such libraries. Likely because engines are built up for the needs of the game. Not for general reasons.

Share this post


Link to post
Share on other sites
Not to me. Seems like a waste of time outside of learning purposes. You listed alot of code I could easily write in a short session and make 100 times better as it would be geared towards the actual project I'm working on.

Share this post


Link to post
Share on other sites


i started to make general c++ classes to facilitate an hypothetical game development.

 

I believe I understand what you're trying to do. I create new classes all the time (which don't render themselves or use I/O interfaces to update themselves, etc.) to use with my engine. However, your classes aren't "general." They're quite specific with regards to implementation. To use them requires using and interfacing your specific concept of game states (I don't use game states in my classes). It sounds like you've incorporated a physics engine specific to your configuration of objects. That's all very specific for "general" use.

 

[Rhetoric follows - just MHO]

 

Although you use general descriptions for your classes - acceleration/deceleration (for instance) isn't part of collision, it's physics, and can/should be separated from collision detection. If you want acceleration/deceleration to be a "feature" of your classes, you need to add angular velocity, torque and force accumulation, ability to set moments-of-intertia, friction factor setting, etc. Collision detection should handle multiple shapes (spheres, planes, triangles, etc.) and provide hit positions, surface normals and penetration depth.

 

All-in-all, if you include everything you imply, your library would be the opposite of general. Users would be tied to your specific concept of how objects should interact. Unless your implementation is very complete, it sounds like either a lot more than someone may need or not what may be needed.

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!