• Advertisement
Sign in to follow this  
  • entries
    570
  • comments
    2427
  • views
    216331

Untitled

Sign in to follow this  

75 views

I have been inspired by this thread on magic systems. The idea of "using the environment to cast magic" gave me the idea for a game that I'll code after I finish up Hiatus this weekend.

Basically, the premise is this - you have a character on a small map of fixed size (basically, in the style of the old top-down Zelda games). The right mouse button allows you to control your character, walking around, opening doors, talking to people, etc., while the left mouse button allows you to manipulate magic.

Screw all the old magic systems with spells and shit. Basically, the map won't technically be a "map". Its a collection of overlapping objects, each having specific properties - an innate magic, what happens if they are reacted with a magic, etc.

In a nutshell: you use the left mouse button to sap magic from the environment, combine it with other shit/magic/whatever in the environment and stuff happens. Like if there was a torch, you could harness the fire of the torch into a ball, then throw the ball at a tree. The tree object would (hopefully) have code which would be called like tree::onHitWithSomethingWhichIsOnFire and also burst into flames. Then you could grab some water from the nearby pond and throw it on the tree which would then call tree::onHitWithSomethingWhichIsSufficientlyWetToPutTheFireOut.

Key ideas:
  • Fixed maps: this allows us to ditch the notion of tile maps, which scroll really nicely and are fast to blit (no culling needed). We need each object on the map (including the map itself) to be able to react to stuff, which means we need each object to have unique qualities, and blah which would be a pain to do with a tilemap.

  • Minimalist UI: Everything should be done with the mouse. No cheating by adding buttons to the screen or any of that crap - the controls should be simple and intuitive, yet yield diverse gameplay options.

  • Reactivity: Each object should react with stuff in a predictable, intuitive way. If you throw fire into a gas station, it blows up. If you throw water on the fire, it might go out. Unless its an oil fire. In which case it blows up more.

  • Unpredictability: Magic is an unstable thing by nature, accidents should happen. If you're not experienced enough to wad together 42 cubic metres of pure fire, you might accidentially fuck up and cause the whole map to inferno. Which would ultimately result in player::onPantsCatchFire being called, which is bad.

I hate having big massive projects, so I think I'm going to limit the scope of this to a "proof-of-concept" - just a couple of sandbox maps and such. This should be do-able, I think, as long as I don't introduce something insanely complex.
Sign in to follow this  


3 Comments


Recommended Comments

I would have a templated visitor object that takes a pair of physical properties (wood + fire) and returns an event (light object on fire). I believe this is what HL2 does for their much-promoted material system (they work it into their sound and physics system as well, so wood + rubber makes a muffled noise instead of a squeaky one when you walk over it).

Then that way you can define a GameObject:
class IGameObject {

std::list<Material> materials;
}

Tree = new IGameObject()
Tree.materials.push_back(WOOD)


And then spawn many different types of wooden objects along this regard, without having to think too much about it.

MaterialInteractor<Fire,Water>(Fire target, Water actor) {

target.parent.remove(target) // The fire is out!
target.parent.add(SMOKE) // oh snap
}


You could add properties to the material, of course (deletes parent on expiry, time-to-live, sound effects/sprites while active, gives off light, damages characters on contact). There's a lot of room for flexibility with a decent set of interfaces. You could probably even prioritize materials (so a table with varnish on it would be more flammable than one without) and provide 'minimum amounts' in the interaction (so a droplet of water wouldn't extinguish a forest-fire).

Effectively, to save memory you could define a base set of actions (delete, then add smoke) and then build a table of the interactions -- this is probably only best if your interactions are commutative; for example, throwing a gas station at a fire is probably less likely to set it on fire than throwing a fireball at it.

Come to think of it, I think this is what chemistry simulators do.

This is neat.

Share this comment


Link to comment
That environmental magic is soooo early 2006. Dwarfy and I played with the idea when we were in Empyrean Gate's early design phase. Actually, I don't think we ever discarded it...

Share this comment


Link to comment

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

  • Advertisement