Jump to content
  • Advertisement
Sign in to follow this  
Derakon

Balancing between generality and ease of use

This topic is 4969 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'm not entirely certain that this thread should go here, but it does seem to be related to design issues. I'm nearing completion of the engine half of my game project. I've created a general-purpose 2D sprite engine with a variety of features that I'll need for the actual game. However, one of the things I want to be able to do is release the engine with the game (that is, make them separate components) so that other people can modify the game content or make their own games using the engine. With that in mind, I made a few design choices, such as: fully scriptable game objects using Python easy to read plaintext data files generic engine Now I am faced with a problem: the engine, as it stands, is very generic. It's primarily a datadump and a message sender (user -> sprite and sprite -> sprite). Collision detection basically tells each sprite what they hit, what direction it was moving in, and what side the collision came from. There's no physics, no support for objects like walls or platforms, not even really the concept of a "player" (some sprites may accept keyboard input, and one of those "sprites" will be the camera; otherwise, no player per se). This makes the engine incredibly flexible in terms of what it is capable of doing, but it puts a lot of work on the shoulders of the content creator. To actually make a game, you need to write Python scripts for each object that determine how they react to objects (this includes things like backing off from permanent barriers so sprites don't get stuck, as well as the entire physics problem). This seems, to me, like an inelegant solution that will lead to a lot of duplication of work, assuming anybody ever tries to use my game engine. I'd like to find a way to cover that for people without reducing the generality of the engine. So far, the best idea I've come up with is to make a set of generic scripts that describe common game objects. For example, the "wall" object would just sit in space and never react to anything. A "simple moving sprite" object would have some basic precoded movement, and would react properly to collisions with wall objects. A "realistic sprite" object would be subject to gravity, friction, and so on, as well as doing everything that the "simple moving sprite" did. The idea here is that these scripts would serve as templates; you'd never actually see them running on their own in the game, but the content creator could use them as jumping-off points for their own game objects. Does this sound like a reasonable solution? Do you have any better ideas?

Share this post


Link to post
Share on other sites
Advertisement
I like your idea of providing some generic 'template' scripts, and was in fact intending to suggest it before I read that you'd already thought of it.

One possible suggestion though, would be to put some of the basic physics in it's own script rather than having reactions to it in the sprite's scripts - why have them write gravity handling code into each sprite, rather than have a single 'gravity' script which effects all sprites? As gravity acts on a number of variables (depending on how complex you make your physics), giving different sprites different properties could still make them act different to each other.

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!