Just some fun stuff before going to yet another party (seems like this never ends...).
I was browsing the keywords used to find this blog on Google Analytics and here's the most used expressions:
"game development diary" (didn't know someone would search for something this specific)
"mini mmorpg games"
"point and click mmorpg" (I guess switching movement from keyboard to point and click was a good idea!)
Those all makes sense but here's some funny ones:
"best of mmorpg with skill punch" (I guess someone just want to punch the bad guys in the face)
"duplicated items in mmorpgs" (Hopefully, you won't find this here!)
"gm command to learn skill lockpicking" (hmm, again someone trying to cheat?)
"make mini piano" (eh, from my post about Ultima Online)
"mmorpg that is not point and click" (hehe, exact opposite of the other one)
"not just point and click mmorpg" (...come on...)
Monday, December 31, 2007
Just some fun stuff before going to yet another party (seems like this never ends...).
Friday, December 21, 2007
There's time when an idea just pop out of nowhere and slam into your face, almost pushing you into a state of divine illumination. Well, maybe not that much but still...
I was trying to figure out a way to allow players to put various items in the world like lakes, fountains, statues, ... without them throwing out the window the design of the world. That's when I figure it out.
As it is right now, players can use a building blueprint (or a building packed-up) on any zone (well, those not restricted to GM and admin). When a building is created, a key is put into the character's inventory, linking the character to the building.
What if I'd use the same process to allow players' cities. Players' would become unable to place buildings in the world zone but would receive the possibility to put cities instead. Players would then be able to put buildings only in those cities.
Cities could work the same way buildings currently do. Instead of seeing a building, players would an image representing a city. By right clicking on it, they would "enter" the city, just like they would enter a building. Once inside, instead of showing the design of a house, grass, dirt, water would be shown. So in the end, the city would be in fact just like a big building in which we can put other buildings.
From there, permits to place a house could be sold, city expansion blueprints could be crafted (to create more zone for the city) and the owner of the city would be free to carefully design an outside setting or just screw it up without breaking anything from the "big" world.
The good news is that I don't really have much to do to allow this since the mechanic already exist for buildings. Some changes need to be done at some level but nothing here is breaking the design.
I'm giving myself some time to think about it, to figure out if I'll add this or not. This would be the biggest change from my initial goal but I also feel like this would be one of the most interesting feature.
Since the beginning I never pushed away the possibility that the first game I'd make with this framework would be similar to one of those gameless-games. The reason is the amount of work require to get this project on it's feet. If I throw in more game mechanics like PvP, quests, weapons, spells ... I might have a hard time releasing something stable in the next year (I'd like to aim for spring for first release).
I already hear some people saying "glorified chatroom ahead!!!". Well, that could be a nice name for my first release :-P
The way I see it: one step at a time, small and functional is better than big and bugged. Anyway, when I suddenly feel (again) an urge to go back to SWG just to make myself a crafter and run my small casual business, I'd bet I'm not the only one in this set of mind.
Tuesday, December 18, 2007
I just added support for the toolbar (quick use of skills and items) and now is the time to think about building some tools to help me deal with the database. It wasn't really planned that I'd start to work on this right now but a comment on a post about tools from Psychochild's blog popped back some memories from Chasing Tortoise's development.
I consider I never did enough tools for CT and it brought me some problems, like getting lost in a ton of data made of meaning less foreign keys. As I was doing some test on the crafting process for the MMO project, I knew I had to spend some time on tools before this becomes a nightmare (or gives me some).
So the current tools I need are:
- Zone management : Easily see how zones are linked together, which zones belongs to buildings and the content of each zones
- Props families, types, types parts management : There is a lot items, a lot. Each item have properties and each item is made of other items. There's no way I can handle all of this without a clean interface.
- NPCs management : What are they selling, what can they teach
- Characters management : See attributes, skills and inventory of each characters
For now, those tools will probably be enough to deal with alpha testing. Since they basically consist of just clean interface to access data and linked data, it's quite easy to code (I'm using the "evils" wizards in Visual Studio which are just fine for what I want, performance not an issue here).
The props management tool is really the most important considering the amount of data and the number of tables linked together. With this tool, adding a new item to the game should become easy while dramatically decreasing errors possibilities.
I can't say tools' development is the most exciting part but I know it's an important part of the project if I want to make sure to get to a clean and stable result. Now back to work.
note: I'll be looking for VPS hosting soon to start testing (probably just after the holidays). My first choice (at least while testing the project) so far is http://www.1and1.com, mostly because it's cheap and at the moment, I can't really afford more. I know they had some bad reviews but which big company hasn't...
Anyway, if anyone can suggest me another VPS hosting for about the same price, I'd be interested.
Saturday, December 15, 2007
Click here for demo 5
Just a little disclaimer, I'm still not very good handling those videos. The "lag" you see is a result of this.
In this demo, you'll see better movement handling (because of point and click), skill training, crafting and how players can have a house.
For this demo I created 2 NPCs. Bob is a merchant selling houses, wood and iron. Jack is a skills trainer.
This demo shows Dak learning how to craft a small chest, buying wood and iron, craft his chest then buy a house and place his brand new chest inside his house. You'll even get a small glimpse at the guild interface but that's just a misclick from me...
You'll notice that the interface doesn't always react correctly (like on the first try to craft the chest, the first wood wasn't added correctly) but I'm still satisfied with it's current state considering it's still pre-alpha. I was expecting much more problems or glitches than that.
And don't worry, those horrible colors are just there to make it easier to spot different zones while testing. Like the red zones all around the play zone are used to move the character to adjacent zones.
Hope you'll enjoy this demo!
Thursday, December 13, 2007
From the start movement has been handle by keyboard arrows. I'm not really a fan of point and click movement in 3d games and my model was SWG. Move with arrows and click on skills located in the toolbar.
I never really looked back until yesterday when I was messing around in my 2 zones world.
If your gentle with the keyboard, the actual system works just fine. However, when you start doing fancy maneuvers (long run, switching direction really fast), the results are unpredictable.
When an arrow is pressed, a message is sent to the server, the event listener for keys is detached from the browser and is reattached half a second later. The listener is detached because constant key pressed brings some heavy loop that the browser have some difficulties to handle.
While the /move action is sent to the server, others /move action can be receive from it to show movement of the character on the screen. Between each /move action received, an animation process takes place to animate the character going from point A to point B.
As you can see, a lot of things are happening to move a character and synchronizing all of this can become quite difficult (and I'm not even talking of what happens if the client computer slows down). The character on the screen might not be at the exact real location with the result of the player holding too long the arrows and then the character moving 1 or 2 square too far from the desired location.
Like I said, all of this is not a problem is you're gentle with your keyboard... but I don't expect players to be (or the right thing to say would be I can't ask players to be). Now the question I'm really not sure to know the answer right now is "Will I be able to make the movement process more stable the way it is currently handled?".
First, a lot less signals would be sent to the server. To move 10 squares left, only one click would be needed compared to 10 /move commands with the keyboard.
Second, the ending position would really be for sure the desired position. No more "oops, I hold too long the arrow while the interface was trying to catch up".
So far it's all good. The downside is that more work on the server is needed to calculate character's position when a movement is asked (well, a new coordinate to go to is sent). I don't see this as a great problem but there's surely a small challenge there.
With arrows movement, the server is dumb. It only check if movement is allowed in this direction. With point and click, it needs to calculate all coordinates the character needs to hit in order to get to the desired location. I could do this in two ways.
The first would consist of going in straight lines. Player clicks on the interface, character try to go in this direction, if there is an obstacle it stops. The player then have to click somewhere else to get around the obstacle.
The other way is to use what the NPCs' AI is using: path finding. The code is already done for NPCs so I could easily use it for PCs as well. Player clicks on the screen, coordinate is sent to the server, server calculate best path to reach the destination, movements are sent back to clients one after another with the correct downtime between each movement (so the animation match the real location of the character) and if an obstacle is met, the character will go around without the need for the player to click elsewhere.
The main (only?) problem I see with the latest is that characters might sometimes go to places players didn't expected to reach the destination. Of course, the player would be able to change it's course by clicking elsewhere, sending a new destination coordinate to the server while the previous path to be sent is dumped.
What impact this would have on the interface? It's probably a bit early to know exactly since the toolbar isn't yet implemented. For now I'll probable just add it anyway while keeping the old method not too far and alpha testing should shine some light on this.
Anyone have some comments on this? Any links to keyboard VS mouse articles?
Wednesday, December 12, 2007
If you're like me, you probably created accounts on numerous web sites just to take a look at a service or a game. And if you're like me, you're probably getting tired of it and most of the time you just don't bother with yet another account creation process.
Inspired by Maid Marian, I added a way to easily "see how it looks" with the "log as guest" feature.
For Chasing Tortoise, I made sure visitors could take a look at the game without having to create an account. Screenshots being limited, I felt this was a good way to get people more easily into the game. For this project, the "log as guest" feature will allow anyone to enter the world, freely walk around and chat just by clicking a button with all other features being locked.
There is 4 access level available so far: Guest, player, GM and admin. Each command is linked to an access level. Each time a command is sent to the server, a check is first made to make sure the current character has the correct access level to execute this command, higher access levels being able to invoke lower access level commands.
So commands like /addzone, /deletezone are restricted to the admin level. Commands like /createnpc, /ban are restricted to GM. All other commands are restricted to the "player" access level (like /open, /use, /trade, ...).
The only commands available to the "Guest" access level are /logasguest, /logout and /move. This way, guests are unable to trade, buy from merchants, open their inventory, open containers and so on. I'm even thinking of restricting guests to some zones to make sure this feature is not used for scouting or any abuse. The point here is to show what the game looks like so people can decide if they want to create an account or not.
The name of a guest player is automatically set to "Guest[guest id]", [guest id] being the first number available starting at 1 and counting up. When a guest leaves, the number becomes available again. I'll probably have to add some filter to prevent characters' names being set as "Guest###" at the account creation so each name remains unique.
The to-do list of features I really wanted to have at start now looks really short which is a good news. It means that really soon I'll do another pass at all commands to do code revision in prevision to start alpha in January. That's still a lot of work but I'm getting closer!
Thursday, December 6, 2007
House pack-up as explained at the top
Wednesday, December 5, 2007
SunTzo has a dream. He wants to create a guild. He clicks on the "Guild" button and the guild window appears.
Two options are available: create a new guild or asking to join an existing guild. SunTzo type the name of his guild, Elite Tactical Unit, and then type the acronym that will be used for it, ETU.
He clicks the "Create" button and SunTzo receives a notice that the guild has been created.
Dak heard a lot of good things about ETU. He talked a bit with some of its members and decides to send an admission request.
He clicks on the "Guild" button and type the name (or it could be the acronym) "Elite Tactical Unit" and click on the "Ask to join this guild" button.
SunTzo opens his guild window. In this window, he sees on the left the current members of the guild and on the right the request to join the guild. He sees that Dak has requested to join the guild. He right click on Dak's name and select "Add" from the context menu. Dak is now a member of ETU.
From now on, SunTzo and Dak are able to chat on the "Guild" channel which is a private channel available only to members of ETU.
From the guild window, SunTzo also have the possibility to kick members out of the guild or even to delete the guild. Dak's options are limited to quiting the guild, see the current members list and see the join requests. Options shown for Dak and SunTzo (guild leader) are different even if they both click on the same button to access the guild window.