Wednesday, October 31, 2007
Media Proposal
My media proposal for Anarchy MUD can be found here. I was up late last night working on it, and I had it posted to the pool, but I forgot to post it to my blog until about three minutes ago. The simulation will arrive in the next few days, and will also be found in the media proposal.
Monday, October 29, 2007
Only around seventeen years too late?
I was researching late last night for some possible source codes that I could work off from for Anarchy MUD, and I stumbled into something that could either make or break my project: TinyMUD. Apparently, about seventeen years ago, James Aspnes developed a MUD that allows all players, and not just administrators, to create items and rooms. Later derivatives improved on this, allowing more control over the world (such as being able to destroy items and rooms as well, adding recovery methods for deleted work, creating a system to limit power to certain players, and even allowing universal game rules to be changed (like Nomic)). The more I researched it, the more I've discovered games that had the same exact characteristics of Anarchy MUD. Every characteristic was present in another game somewhere.
Except for one.
As flexible as all of these games seem to be, I am yet to find one that incorporates the modification and deletion of player characters as a feature. This might be my only saving grace. It is also, in my opinion, the most interesting characteristic, so I'm not completely dismayed that everything else has been done before. If anything, it might make programming that much easier, if I am able to use the source code from a TinyMUD or TinyMUD-derivative game. I will be doing some more research, however, to make sure that I am indeed doing something at least partially original.
Ingenuity is hard work.
Except for one.
As flexible as all of these games seem to be, I am yet to find one that incorporates the modification and deletion of player characters as a feature. This might be my only saving grace. It is also, in my opinion, the most interesting characteristic, so I'm not completely dismayed that everything else has been done before. If anything, it might make programming that much easier, if I am able to use the source code from a TinyMUD or TinyMUD-derivative game. I will be doing some more research, however, to make sure that I am indeed doing something at least partially original.
Ingenuity is hard work.
Sunday, October 28, 2007
Feeling like a stick in the MUD
It has been very busy for me recently, so I haven't had much of a chance to update my blog beyond adding my proposal paper. I have been doing a lot of reviewing of other people's capstone ideas, giving suggestions, writing and editing my proposal paper and Gantt chart, and other random school work that I haven't had much time to work on my actual project.
I am also daunted by the task of working on a project that I've had little experience with, outside of actually playing a few MUDs a few years ago. I will either need to learn a programming language (not exactly sure what that language will be yet, at least not until after I research what is available), or make friends with someone willing to code for me. Thankfully, I do not believe I am forced to start from scratch; there are many source codes available for MUDs that are very basic, and allow designers to work off of and improve to fit their game better. I believe one of my first steps I will need to take is to research what is available for me to work from, and go with the one that fits my idea the best. This saves me about three heart attacks and an aneurysm, because I will not be forced to develop the entire system from the ground up and instead will have more time to create a solid and hopefully functional game.
If anyone knows of anyone who has actually had experience building MUDs before, I would love to receive a little bit of help.
I am also daunted by the task of working on a project that I've had little experience with, outside of actually playing a few MUDs a few years ago. I will either need to learn a programming language (not exactly sure what that language will be yet, at least not until after I research what is available), or make friends with someone willing to code for me. Thankfully, I do not believe I am forced to start from scratch; there are many source codes available for MUDs that are very basic, and allow designers to work off of and improve to fit their game better. I believe one of my first steps I will need to take is to research what is available for me to work from, and go with the one that fits my idea the best. This saves me about three heart attacks and an aneurysm, because I will not be forced to develop the entire system from the ground up and instead will have more time to create a solid and hopefully functional game.
If anyone knows of anyone who has actually had experience building MUDs before, I would love to receive a little bit of help.
Wednesday, October 24, 2007
Proposal, Version 2.0
I have revised my "Anarchy MUD" proposal paper for Mike Scott's capstone class. It hasn't changed too much, with the exception of a shiny Gantt chart replacing the old and ugly table I once had. You can find my newest version for download here (188k, .doc file). As before, any review of this would be most appreciated by myself.
Monday, October 22, 2007
Proposal Paper
It has been a very busy and stressful week, so updates have been slow as of late. I'll make up for it soon. However, I have finished my first draft of my proposal paper, which can be found here (35k, .doc file). As always, critique is welcome.
EDIT: Whoops, in my sleep-deprived state of mind, I forgot to add that the proposal is for "Anarchy MUD". So now you know, and knowing is half the battle.
EDIT: Whoops, in my sleep-deprived state of mind, I forgot to add that the proposal is for "Anarchy MUD". So now you know, and knowing is half the battle.
Friday, October 12, 2007
Spore
Jon Ippolito sent me another link, but this time it's to a "dated" article (March 2005) that previews a game code-named Spore (The game, developed by the people who created the Sim games, were originally planning on calling the game Sim Everything, but the code-name Spore stuck).
Spore is an evolution simulator, where you begin the game as a small microbe and eventually evolve into a creature. As the game progresses, your fully-customized creature becomes sentient and starts a tribe, and eventually a civilization. Ultimately, you acquire the technology to travel to other parts of the world, and even one of millions of planets, many populated by other beings. These other beings would be creatures created by other players, which have been automatically uploaded to their server and distributed around to other players, thus creating a unique "massive single-player online game".
The article talks about Will Wright's thought behind designing the game, and how he pushed away from having enormous teams of artists and animators creating everything needed for the game, and instead focuses on code-based procedural creation of not only the creatures, but the buildings and worlds they inhabit. The procedural generation doesn't rely on pre-designed images, but instead uses complex mathematical formulas to create everything; this effectively reduces the file sizes of other players' creatures down to under 1 kilobyte, making distribution of characters incredibly easy. The procedural generation doesn't stop at just the looks, however, it also can be used to smartly predict how the character would be animated (two legs vs. four legs vs. ten legs, how fast it moves, what limb it uses to hold objects primarily, etc.). And suddenly, a game that would normally require a gargantuan army of artists and animators and would take up a huge amount of disk space is instead able to be created by a significantly smaller team of coders and will take up much less hard drive space. On top of that, the creative possibilities open up, and are literally endless.
This is relevant to my Anarchy MUD idea because it's basically a game where the players create the world (or in this case, the universe) around them. This also has a playability advantage over my idea, in that the players aren't able to break the game and ruin it for everyone else. I haven't decided yet if I will keep the easy destruction of everything ability in later approaches of my idea, or if I can somehow incorporate a way to limit it, and if so, how would I go about limiting it. Just more things to think about.
Spore is an evolution simulator, where you begin the game as a small microbe and eventually evolve into a creature. As the game progresses, your fully-customized creature becomes sentient and starts a tribe, and eventually a civilization. Ultimately, you acquire the technology to travel to other parts of the world, and even one of millions of planets, many populated by other beings. These other beings would be creatures created by other players, which have been automatically uploaded to their server and distributed around to other players, thus creating a unique "massive single-player online game".
The article talks about Will Wright's thought behind designing the game, and how he pushed away from having enormous teams of artists and animators creating everything needed for the game, and instead focuses on code-based procedural creation of not only the creatures, but the buildings and worlds they inhabit. The procedural generation doesn't rely on pre-designed images, but instead uses complex mathematical formulas to create everything; this effectively reduces the file sizes of other players' creatures down to under 1 kilobyte, making distribution of characters incredibly easy. The procedural generation doesn't stop at just the looks, however, it also can be used to smartly predict how the character would be animated (two legs vs. four legs vs. ten legs, how fast it moves, what limb it uses to hold objects primarily, etc.). And suddenly, a game that would normally require a gargantuan army of artists and animators and would take up a huge amount of disk space is instead able to be created by a significantly smaller team of coders and will take up much less hard drive space. On top of that, the creative possibilities open up, and are literally endless.
This is relevant to my Anarchy MUD idea because it's basically a game where the players create the world (or in this case, the universe) around them. This also has a playability advantage over my idea, in that the players aren't able to break the game and ruin it for everyone else. I haven't decided yet if I will keep the easy destruction of everything ability in later approaches of my idea, or if I can somehow incorporate a way to limit it, and if so, how would I go about limiting it. Just more things to think about.
Lunchtimers
In response to my "Sand Box" idea I mentioned earlier, one of my classmates sent me a link to Lunchtimers, which is an interactive refrigerator magnet simulator. Players can move around colorful letters to spell words or sentences, and everyone has equal control over where the letters are placed (so someone in the middle of writing something can get his letters removed by someone else also writing something). Play isn't limited to just words, though--another player and I spent the last ten minutes organizing all the letters by color, and then sorted out each magnet by letter. Already, our work is being decimated by other players, and no one can expect their words to survive for too long. Sadly, the game seems to be most popular with thirteen-year-olds, and so the language reflects that, but the idea behind the game is clever nonetheless.
When I was brainstorming "Sand Box", I actually was partially inspired by this game, but I could not remember what it was called. It's a good thing some people in the class have a better memory than I do. The largest difference between Lunchtimers and Sand Box would be that Sand Box would allow for more control over the visual aspects: you are not limited to refrigerator magnets, and are able to hand draw not only your letters, but whatever you like. This, of course, would be much more difficult to program, and would definitely use more resources than Lunchtimers, but the trade-off might be worth it.
When I was brainstorming "Sand Box", I actually was partially inspired by this game, but I could not remember what it was called. It's a good thing some people in the class have a better memory than I do. The largest difference between Lunchtimers and Sand Box would be that Sand Box would allow for more control over the visual aspects: you are not limited to refrigerator magnets, and are able to hand draw not only your letters, but whatever you like. This, of course, would be much more difficult to program, and would definitely use more resources than Lunchtimers, but the trade-off might be worth it.
Subscribe to:
Posts (Atom)