Ultima Online is now 10 years old and I stumbled upon this post by Damion Schubert. He describes some unplanned uses of the game that gave a "magical" touch to UO.
My attention has been caught by how players found a way to build a piano by using shirts and a chess board. While I never played UO myself, I've seen similar creativity in SWG. In fact, some players dedicate quite some time just to build stuff that wasn't planned in the game. All of this comes down to players' freedom and I realized how I could a bit more freedom in my project.
I use a very rigid x,y coordinates system when it comes down to deal with items positions. You have to see it as a grid and all items are contained in a cell (or more if they're bigger but their positions are relative to the cells). So if I want to see a player made piano in my game one day, I'm not helping players here by restricting how items are shown.
I created a new table containing offsets for each items. The values contained in this table are pixels. This way, I pass the coordinates of each object to the client with the offset. The pixel position is calculated and then I apply the offset, allowing items to be placed wherever the player want it to be. With the pixels offsets, I added an offset for the Z-Index that will affect on which layer the item will be shown.
Players will use the /offset command to change those values. To move a chest 30 pixels to the left, just type /offset x -30 and the chest will appear 30 pixels to the left. Of course, not all items will be allowed to be moved like this. Only items with no elevation (no collision) will be allowed to be moved this way to prevent any abusing.
There it is, a way to build a piano! Not the kind of thing that was part of my priorities list but considering how little time it took me to code, it was well worth it for the possibilities this might open.
Saturday, September 29, 2007
Ultima Online is now 10 years old and I stumbled upon this post by Damion Schubert. He describes some unplanned uses of the game that gave a "magical" touch to UO.
Wednesday, September 26, 2007
Is a guild system really necessary for a MMORPG? Well, considering the point is to get players to play together, why not make it easier for them to group. I guess this statement is pretty obvious but players will create their own guild system in games without one (like Urban Dead at some time).
Beside, considering the time it took me to code it, that was really worth it. The guild system took me around 6 hours to code. Of course, it's basic but it's enough for what I wanted to start with. Let's take a look at it.
/guildcreate [guild name] [guild acronym]
Anyone can create a guild. The guild acronym is just to make it easier for the interface.
You'll notice that there's no parameters for this command. The less parameters, the less headaches for me later if players find a way to abuse them. All checks are made in the SQL stored procedure (is the current character a guild leader?) to have the best performance.
/guildjoin [guild name]
The only way to join a guild is by first submitting a request. The character will appear on the members' list as "waiting approbation". Having to send a request prevent spammers roaming around sending invites possibly getting in the way of gameplay.
Again, no parameters here. We check if the character is part of a guild, if he's not the guild leader. Currently, the only way for a guild leader to leave a guild is to delete it. I'll have to have add a /guildtransfer command that will allow to give the leader title to another character but for now it's not important.
/guildadd [character name]
This command will work only if the character applied for membership and if the character using it is the leader of a guild. While I did put a "member status", I haven't implemented different members' roles (like someone that could add members but not delete the guild). That's just some fun stuff I'll keep for once the game is done if there's ever a need for it.
/guildremove [character name]
Works the same way as /guildadd. It just remove a character from a guild.
That's it! Not more complicated than this. Adding the guild chat was actually pretty easy too since I already had all the mechanic for chat. All I added to the web service is a "sendGuildChatMessage" function that pass a different parameter to the same function as "sendChatMessage".
At first, I wanted to use the same function but dynamically add "/g" to messages from the interface when the guild tab is activated but in the end, it was just plain dirty and confusing for nothing.
So the guild system was this week objective. Giving yourself small and realistic objectives helps a lot motivation and to get the feeling that you're actually getting something done. With this, I'll probably be able to allow me a break tomorrow for the first episode of the new season of CSI!
Monday, September 24, 2007
I thought that doing player to player trading was gonna be an easy ride. Well, I couldn't be more wrong. Beside just building the mechanic, I was constantly adding more and more validation to prevent cheating. Most of mechanics I took from Magic The Gathering Online system.
So let's see what I needed. I wanted players to be able to trade items AND money (just addind a /tip command wasn't good enough since I wanted to make sure players can do fair trades without having to rely on trust that the other will pay them).
So the commands looks like this:
- trade (send trade request / accept trade request)
- add item
- remove item
- update money
- accept (true or false)
- cancel trade
The interface will basically have 3 lists:
- Character's inventory
- Current character's items offer
- Other character's items offer
There's a textbox to insert money and a checkbox allowing each characters to accept the trade.
The first "anti-cheat" mechanic I added was to make sure that if Character A accepted the trade and that Character B modify it before accepting, the "accept" status is reseted. That way, there's no last minute changes without leaving the other reconsider the trade.
The exact same check is made in the SQL database when the trade is accepted by both players. The reason is that when 2 characters trade together, everything else is still running in the background. A character could put an item for trade and then remove it from his inventory (or maybe even trade it to an alt or something). When the stored procedure is executed, there's nothing that can be modified to the trade. If the items and money states aren't the same as before accepting the trade, everything is canceled and the trade instance is deleted.
Beside those points, there's a system to make sure a character is currently trading with only another one character, again to make sure no item is lost.
One thing that always fascinated me is how almost all games have/had bugs allowing items to be duplicated. I think I made a good job that at least the trading system won't allow this. In the data, the object is never "moved" or deleted/recreated. The link to the character remains on the item so when an item is traded, only the reference to the character is changed, avoiding leaving a ghost item somewhere.
I haven't build a fully operational interface for this system yet and I believe it will wait until I get seriously into the interface. All those interaction (drag and drop, lots of events received) made it complicated to find my way in my prototype that is beginning to look a bit ugly by pushing a little bit of not so well thought code. The good thing is that with that prototype, I get a good sense of what not to do once I'll start coding the real interface. So far I have a list full and I'm still learning new tricks about how to use script.aculo.us.
What's next? I really want at least a basic guild system with guild chat for the first version and I have yet to work on PVE. That one should be a nice challenge. After this, if I check my to-do list, it's pretty much just revisiting existing functions to polish them and make sure they're usable in a real case scenario.
I feel I need to hit the brakes a bit before getting into something too big. That also means that I need to rethink my first game idea. What I have in mind now wouldn't require much "game specific" mechanics so I think it's better. The only real big thing to add would be a crafting system. Enough said for now, need to do before.
Wednesday, September 19, 2007
Here's an idea about a system that could be used by characters to buy skills or do some actions. Something to replace the XP system and the "active" grind. I'm not aware of all systems ever imagined so if it's already been done well, I like the idea anyway.
Every hours, a character receives X time points. A character can accumulate Y points before he reach a cap and need to spend them to receive more.
Each skill require that an certain amount of points be spent to learn it. Lower "level" skills could require an amount of points lower than the number of points a character receives in a day, some might require more.
When a skill require more points than the maximum a character can accumulate, he need to spend some to start the learning progress.
Time points can be spent to learn skills (combat, crafting, ...)
Ex.: Dak wants to learn the Fireball spell. Fireball cost 200 time points and Dak can only have a maximum of 150 time points at the same time. He decide to spend 100 points right now, leaving him with 100 more to spend later while still having 50 points to use somewhere else. Dak won't know the Fireball spell until he paid all 200 points.
Time points can be used to collect some materials (mining, cut wood, ...)
Ex.: Instead of spending countless hours mining for ore, Dak goes to the mine and spend 50 points. Those 50 time points will give him 20 units of ore. If he'd spent more, he'd collect more ore.
Time points can be "sold" to a NPC for money
Ex.: Dak is a little short on money. Hopefully, he has the "create leather armor" skill. He's not interested to create his own business so he goes to the armorsmith. The blacksmith tells him that if he helps him finish that big full plate his working on, he'll pay Dak 1 silver coin. Dak spend the necessary amount of time points and receives his money.
If Dak would have been better at helping the armorsmith, he might have received more money. Dak won't get rich this way and the armorsmith might not always need some help.
Time points can be spent to teach a skill to another character
Ex.: Dak still want to learn the "dragon swordfighting style" that cost 100 points while he only have 75 left. He go see Zak that already have that skill. Zak can spend 25% of the time points needed by Dak to learn this skill, leaving Dak with 75 points to spend to learn this skill.
Time points can be spent to craft
Ex.: Dak wants to craft a sword. A sword requires 200 time points to craft. If he have all materials needed, he can spend points to begin crafting. He can spend 100 today and the remaining tomorrow.
So you're saying I could "maxxed" my character by just doing nothing?
Well, that's up to you but I guess that wouldn't be really fun. Is it unfair to the hardcore players that spend countless hours killing orcs over and over? I know this is the usual way of measuring the "hard work" someone is putting in a game but frankly, it's not my cup of tea.
Beside, I think that with an approach "skills brings more choices and not more power" it might be successful.
If it's been done over and over, it must be because it brings some kind of "success" to a game (keep the players hooked for not much in the end). But it's been done over and over so why try to do it again...
I'm throwing this idea because that's what I'd like to see in my game. Of course, this is a first draft, I'm sure some there's some flaws in it. I'm also sure a lot players won't like this system like (hopefully) a lot of players will. However, if I'd do a "grind system", I would be the one not liking it and I don't see a point spending time for something I wouldn't like in the end.
If I'm not mistaken, Eve Online works a bit like this (think that's what I read).
Tuesday, September 18, 2007
So here it is, the big news is out on Metaplace.
I see some links with what I've been working on (mostly on technologies used from what we know so far) so I applied for Alpha. I'm curious to see how this could be used for my project (or how it could influence it) so now I'll just have to wait to see if my web programming experience is relevant to them.
Until then, I still have work to do here! More to come!
Monday, September 17, 2007
Just found a new toy so I had to play with it! It's SlickEdit Gadget that I found here. So here's some stats just for fun.
Chasing Tortoise stats (click to zoom)
MMORPG Project stats (click to zoom)
Those stats doesn't count line of code in the databases and HTML/CSS code. As you can see, I'm putting a lot more comments for the MMORPG project since I found out that there wasn't enough in CT. While I still understand all my code, it makes it a bit harder sometimes to get my head back into the code.
For a gross evaluation of time, each time I work on a project, I do a backup just after (duh...). For Chasing Tortoise I have 260 backups and for my MMORPG project I have 39 so far.
I usually work an average of 2-3 hours for each backup (a bit more on sundays) so you do the math. Of course, this doesn't include time spent on design before starting to code, website administration and stuff like that.
First backup of Chasing Tortoirse was on september 29, 2006 (almost 1 year already!) and first backup of my MMORPG project was on july 17, 2007.
Sunday, September 16, 2007
Those were big systems needed to easily build worlds. The blueprint system was surely the most difficult to build but it's now the one I'm the most proud of.
A building (house,tavern,...) is really just a zone that you can access by walking toward a door. The walls are just props I created with various size to be able to do collision. For the prototype interface, I used the set found on Lost Garden.
So to manually create a building, all I had to do was to use the /createprop command I already had. While it do offer the possibility to create whatever setting you have in mind, it is a lot of work to have everything at the right place. To ease the process a bit, I could just do some work on the interface to allow a drag and drop feature where I could pick walls sections and put them next to each other. However, if I'd want 50 buildings, it would still be too much work.
So instead of creating walls, I figured it would be much easier to use a blueprint that would create all zones and walls related to a type of building. The blueprint system works like the SWG system. You drag the blueprint from your inventory and drop it somewhere on the screen to create the appropriate type of building. In 10 seconds you obtain what would take about 30 minutes to build.
To create the world of my first game, I'll just set a NPC merchant that will sell blueprints. Since I'm planning to allow some part of the world to be built by beta players, everyone will become autonomous to build the world without having to deal with strange commands. This system is the first step toward players' owned buildings.
So since I needed a way to put blueprints in my inventory, I needed to create the NPC merchant. This NPC will sell both "infinite" type of props (meaning he the quantity available never goes down) and props bought from players (currently the NPC only sell stuff, buying from PC will come later). When a prop is bought from a NPC, inventory space is checked, money taken from PC and a prop is then put inside the PC inventory.
The inventory has been functional for some time already but it's just this week that I added the graphical interface that make it a bit easier to deal with it. The screenshot below show the inventory as well as the content of the chest near Dak. Props can be put inside the chest and/or inventory by drag and drop. Both windows can be dragged around and there's even transparency (and all of this is created with just 1 line of code thanks to script.aculo.us!).
Click to zoom
I haven't put a video of this since the interface is not as functional as I want it to be. I just thrown some code together to have something that works but it's not worth showing yet.
Here's how "Type 1 House" create with a blueprint looks like (I've put in the bottom left how it looks from the outside). Even if this is just a prototype, it's beginning to look a bit more like a real world.
Click to zoom
Monday, September 10, 2007
Like I already said, the first step is not to build a game but to build a framework that will allow me to create games. Here's the list of features I want for this framework. This list will evolve so I've put a link to it in the right column of this blog.
So far, it's actually going faster than I thought it would. I just can't imagine how fast it would go if it wouldn't be of my day job... hehe. Of course, I constantly asked myself "Is this really needed? Am I going too deep on this feature?" just to make sure I'm not chasing things that won't really help me to achieve the first vision I have.
Some features already are in a functional stage. Those are marked with *. Check the demos to see the evolution. Note that I'm still not talking about the work done on the interface.
- Access level: Player, GM, Admin * (access level is what set which commands can be used by who)
- Movement (right-click) *
- Inventory management *
- Equip weapon *
- Different avatars * (I'm not aiming for complete avatar customization at this point)
- Friendly character creation process *
- Guild system *
- Chat *
- Guild chat *
- Enter as guest (enter the world without creating an account) *
- Ban tool
- 2d up-down view *
- Zones management *
- Add props to a zone *
- Elevation (for collision) *
- Create exterior view *
- Enter/exit buildings *
- Custom creation of interior view *
- Automatic creation of buildings by a using a blueprint (By the use of a prop, create the exterior view and all zones with their walls. Ex.: Use a prop to create a type A house with 2 rooms) *
- Players owned buildings *
- Take *
- Put in a container from inventory *
- Buildings, weapons, decorations, containers, walls * (more props will come)
- Talk to *
- Creation of NPC by using a blueprint (I want to have something that allow players to create a NPC without having to use the /createnpc command)
- Merchants *
- Skills trainers *
- Player to player trading *
- Sell to a NPC
- Buy from a NPC *
- Skills training *
- Cool-down factor *
- Mining *
- Woodcutting *
- Crafting *
- Distance checks * (Ex.: for attacking, opening a chest, talking to a NPC, ...)
- Melee & Range * (basically it's just skills with different ranges)
- HP *
- Respawn *
Monday, September 3, 2007
I finally decided to put some more time on the interface. Even if it's just a prototype and that I will probably throw away a lot of that code, it just make things a lot easier to explain and more enjoyable.
I used graphics from Lost Garden here. Really nice set that gives a sense of life to these lines of code I'm writing. And since I decided to put an online diary of my project, I figured that putting up something decent is still the best way to show that I'm not just throwing ideas on the web. Ideas are cheap and many people have good ideas.
About the demo, I'm showing in this one the combat system. It's quite basic in fact: Target something, use a skill, the server check if the target is compatible with the skill used and a result is produced. The distance between the target and the PC is also checked to make sure the PC is within range of using the skill (different skills can have different range). The same system will be used for any skill (like lockpicking a door for example).
In this demo, Dak (PC) is attacking a NPC. The NPC is currently not replying to attacks but I could have done the same demo with Dak attacking another PC. Some kind of basic intelligence for NPC is something I'm planning but there's still more work to do before that.
There's currently 2 skills implemented: Punch and Basic Weapon Melee Attack. With those 2 skills, I added the system allowing a PC to equip a prop. The prop can be a weapon or anything else allowed to be equipped at the desired slot. There's currently only one slot, the one for the prop the PC have in his hands. More can be easily added. The interface to equip the PC is yet to come.
By default, Dak have no weapon equipped. He's allowed to only use the Punch skill. Once he picks his sword, he's not able to use it anymore but now can use the Basic Weapon Melee Attack.
The next thing I will be working on will be to make sure I can build the inside of a building. The tavern currently existing will be used for this. Currently, the inside of the tavern just look like any other zone with props in it. I'll have to make sure I can put walls in there to have something that looks like this.
After this, well, I'll see. I'm trying to cover only the most familiar systems we see in games while keeping them basic for now (next milestones will be PC to PC trading, basic guild system and some kind of interaction with NPCs). My goal is to have something opening me enough opportunities without going too far in each systems. I'm only building a framework for now so I need to focus on it without falling into systems specific to a game.
Here's the link to the demo : Demo 2
Hope you'll enjoy this new demo. As always, comments are welcome!