GameProducer.Net

Found an interesting blog the other day: GameProducer.net. Though I don't necessarily agree with his views on when to give / not give out freebies, it still looks like a well-done site.

Vyde + RSS + OPML = Vrississopemihl

I've mentioned a couple of times now how I'd like Vyde to be extensible, and even have a web-based component for things like software updates and mod distribution. Today it occured to me that developers could use RSS to broadcast the existence of new mods or updated mods, and the Vyde client could be told to subscribe to OPML files — published online by developers or enthusiasts, or compiled locally in an editor — thereby allowing players to roll their own "option package" for Vyde.

Here's a use case:

1. I'm Jeff, and I play Vyde. I am also a developer, and make a Vyde package available on my site that contains some hand-crafted rooms for inclusion in Vyde's random map generator. I've also got a less popular mod that contains some cheat codes of my own design.
2. I have a friend, Danny, who also develops add-ons for Vyde. He makes a package that contains a +3 laser drill item for inclusion by the Vyde world generator.
3. Danny has a friend, Chris, who publishes a story add-on for Vyde. It adds text for certain NPCs that advances a bizarre story.
4. The most current version of my mods available at http://www.vyde.com/pub/mods/2005-11-04/churches.vpk and http://www.vyde.com/pub/mods/2006-01-01/hotcoffee.vpk.
5. The most current version of Danny's mod is available at http://www.danpack.net/vydemods/laserdrill.vpk.
6. I publish an RSS feed at http://www.vyde.com/pub/mods/currentmods.xml that contains pointers to my most current mods. I also publish an OPML file at http://www.vyde.com/pub/jeffvyde.opml that points to my RSS feed and Danny's RSS feed.
7. Danny publishes an RSS feed for his most recent mod at http://www.danpack.net/vydemods/list.xml. He also publishes an OPML file at http://www.danpack.net/dannysvyde133tness.opml that points to his RSS feed, my OPML file, and his friend Chris's RSS feed.
8. I like to play Vyde using my own add-ons and Danny's add-on. But I don't like Chris's add-on because it isn't canon. So I configure my Vyde client to tune into my OPML file, which excludes Chris's RSS feed. When I play, I get a church room, some cheat codes, and Danny's +3 laser drill, but no story modifications.
9. Danny likes to play Vyde using his own add-ons, mine, and Chris's. He configures his Vyde client to run off his OPML file. He gets my church room, my cheat codes, his +3 laser drill, and Chris's story modifications.
10. All Vyde players tailor the game's mods to their tastes. Everybody gets the most recent mods as long as the developers keep their RSS feeds up to date, and those who like to clone others' play styles just use the public OMPL files.
11. They praise me for my game's modability and send me presents in the mail.

I like this idea, but of course it's pretty far away. Who knows what the RSS/OPML crusaders will have done by the time I get to this point.

Problemoid #1: Unified Environmental Feedback Architecture

Happy New Year to all. I'm going to start making mini-posts that I'll call problemoids. They'll have a number and a kneejerk name assigned to them. These are visions of finished-product I have in my head that demand some kind of design or implementation decision.

Today's problemoid is as follows. Given a random feature in a map, that feature will have attributes and contain objects having attributes that should be affected by some relation the feature has with the rest of the map. For instance, a randomly generated tunnel may have a "dripper" prop placed in it — a little scenery touch that shows some water drops falling from the ceiling to the ground, probably resulting in a moody "bloop" sound effect. But whether or not a dripper appears may depend on several factors, perhaps the humidity value assigned to that region of the map or the temperature in an ice-themed feature (higher temperature = ice melting = more drippers). The attributes upon which the prop's creation depends must be expressed in a uniform way so that the dripper creator and other interested factories can tap into them, especially when developers decide they want their hand-crafted features to take on some dynamic morphology. I want the environment to have a feedback mechanism.

How do I create a unified attribute exposure/consumption architecture? What's a good way to expose actionable attributes to the API for use by me and others who extend Vyde later? Are we talking about every actor in the engine having a collection of "VydeAttribute" objects that can be reflected upon, queried, etc. by the factory? Or perhaps invert the control and have the factory's creator inject the attributes and the formulas that consume them into the factory when it's instantiated?