We love source!

So I'm pretty stressed today.  To try and alleviate some of that I thought I'd put out there some of my code for the auto-drawing app that I have done.  You can consider this code to be under this creative commons license.  Have a look and be inspired.  Or laugh at my older cocos2d skills.  It's a little dated, but still works pretty ok.  Maybe someday I'll update and take this project to the place that it really ought to go.

You can get the code here.

Busy!

I want to apologize to anyone following along or waiting for some code changes.  I've been somewhat busy lately with real life stuff.  While that may not entirely go away, I hope to have that let up some here soon.

I have started kicking around an idea I've had for a while, which is to make a MUD style game in ruby.  Mostly to learn ruby, but also because I've always liked the idea of MUDs (and MUSHes, a good friend of mine had a MUSH on his BBS back in the day.  Yes, I'm dating myself with that one...)

Since this is a game dev blog I'll post the brief outline I started the other night.  It's by no means complete, but it should be a decent starting point and a place to collect my thoughts.  Assuming I get anywhere useful I'll put a github link to the project here.  For the moment I only have a text parser that understands help, quit and parrots your input back to you.  Yeah, it won't be winning any awards anytime soon...

Anyhow.  Enough of that.  On to the outline.

Synopsis:

A world exploring/building text adventure style game.  Players can discover pre-made worlds as well as

create their own world.  Should be a good tutorial/intro as well.

Note: this is probably crazy ambitous for a starter ruby project (past a hello world app)

*--------------------------------------

Currently working on:

- database persistence in sqlite3 (https://github.com/luislavena/sqlite3-ruby)

Bugs/Todo:

*--------------------------------------

- typing anything with 'quit' in it will quit the app, even if it's in a sentence.

- Lila says it needs moar kitties.

Pieces

*--------------------------------------

- Update the interpreter

- Add help to the interpreter.  Make this basic, but interactive.  Above all descriptive.

- add basic vocabulary that does stuff.

- look (examine), move, take (carry, hold, get, steal), say, [more]

- Add a basic tutorial

- Add a (less basic) tutorial.

- Add a basic world with a cheez-ball story.  Maybe reminiscent of king's quest 1 / space quest 1?  (but not as elaborate!)

- Add player object specifics and customization

- Add multiplayer via a server model that multiple clients can coonect to.

- bonjour would be cool for connecting here.  looks like dnssd is the gem for this.

- Also whispering and possibly in-game emails?  Too much?

Objects

*--------------------------------------

- All objects should have a parent, owner and creator.  Default owner is the room the object

is created in, no parent, and creator is the player.

- objects can have attributes.

- attributes should have passive triggers.  i.e. 'steal bread' should not broadcast

to others in a room that a player is taking the bread.

- should objects have a material type/types?  (this would help with world behavior.  Wood burns, stone does not, etc)

- for multiple types, if one is destroyed the object is destroyed?  i.e. a wooden shield with steel studs falls apart when burned

- players should have a custom range of attributes.

- Intelligent monsters could be an alternate computer controlled player, that have their own agenda and motives.

- Add basic infrastructure (API) which is defined as:

- portals/doors

- to other objects.  (objects can be rooms!)

- doors should have their own description, or the user should pick material type.

- We should at LEAST have a standard door that is the default.

- event triggers

- Design triggers.  How do they work.  What events can trigger them?  What can players add or not add?  Can we actually have players add ruby code to meaningfully interact with the world?

- initial thought - triggers should be proximity based (passive), or directly activated (active)

- passive triggers modify the connected object.

i.e. if you are carrying a magic glowing rock you have light around you as a passive effect.

- active triggers can be one-time or continuous.

i.e. turning on a flashlight is a one-time event that maybe activates a passive effect.

i.e. breaking a vase would be a one-time effect.

- custom object methods

- ideally these would be persisted DB objects that can have custom methods.

- thinking some built in actions (teleport to certain places, lloyd's beacon, opening, closing, destroying, etc) would be ideal as an API that makes objects with custom lego-like constructed methods.

- possibly triggers could have some form of ruby to make them very powerful?  How much would we have to expose in order for this to really be useful?  Is that a good idea?