Graphic resources for games

Here's some links of my research for game graphics.

Tool to create characters, faces and battleset
http://www.charas-project.net/index.php?lang=en

Lost Garden
http://www.lostgarden.com/2006/07/more-free-game-graphics.html
http://lostgarden.com/2007/05/dancs-miraculously-flexible-game.html

Pixel Art community
http://www.pixeljoint.com/

Lots of stuff
http://reinerstileset.4players.de/englisch.htm

Tilesets goldmine
http://www.tekepon.net/fsm/index.php

RPG Maker resources
http://www.phanxgames.com/resources/
http://rpg2000.4players.de/

Tileset development for another 2d MMORPG
http://wiki.themanaworld.org/index.php/Tileset_development

Toolkit's stuff
http://www.toolkitzone.com/

World Creator
http://www.inet2inet.com/main/main.htm

Read More......

Do, undo, rethink, redo and I feel much better

So this is my first shot using JSON. I use JSON to return events data back to the client. At first, I thought the best way would be to create classes for each events. Well, it didn't take long before I realized it was way too much work to maintain.

Well, it's the best way to learn. So now, I switched to use arrays instead. Before, it sometimes happened that an object was sent to the client with 1 or more empty properties. First, it was not really smart bandwidth wise. Second, I felt dirty.

With arrays, I'm now sure that only what's needed is sent to the client. And on top of that, it becomes much more easier to add more info if a change needs to be done. Each event possess its own function and I wrapped them all inside a class named EventManager. I will probably save a lot of time coding the client since I will only need to refer to this class.

So before, I had something like this (inside ZoneManager):

objZoneEvent.obj = paramobj
objZoneEvent.nme = paramname
objZoneEvent.x = paramx
objZoneEvent.y = paramy

objGameEvent.EventType = eventType.CharacterMove
objGameEvent.EventDatetime = Now
objGameEvent.DataReturned = objZoneEvent

_zoneEvents.Add(objGameEvent)

And now (inside EventManager):

arrrayEventData.Add(fkCharacter)
arrrayEventData.Add(charactername)
arrrayEventData.Add(x)
arrrayEventData.Add(y)

objGameEvent.EventType = eventType.CharacterMove
objGameEvent.EventDatetime = Now
objGameEvent.DataReturned = arrrayEventData

Zone(fkzone).Events.Add(objGameEvent)

I know, it might not sound very interesting to you but it is for me. I just made a whole part of the framework a lot easier to handle. Of course, it means I have to revise parts of what I have done until now but it's part of the game. Better now than later, thanks to my interface prototype.

Read More......

Can I have those old "ugly" graphics?

Since UO is "Reborn", could someone tell them to ship me for free their old graphics? :-P Yeah, I guess not...

Bah, it's isometric(?) anyway so no good for me. It seems awfully difficult to find good resources for top-down view games (free or not). So far I've only found this. I still need to dig a bit more on deviantArt.

I need to get a graphic artist as a friend... Or kidnap one! ;-)

If anyone have some links to share for graphics, I'd be interested. I'm not there yet but sooner or later, this will be needed.

Read More......

No one is born a paladin

I was just trying to come up with a nice title... Classes or skills? I go with skills. Anyway, while playing D&D, all my paladins were dead before level 5... Go figure...

Well, I said I was going with skills but in the end, it could really be a class system. Classes are just a skin on top of a skills system. It's up to you to decide how tied down the skills will be. It's not my intention to debate about classes and skills here, instead I'll explain how my system will be (nice links about this 1 and 2).

Each skill is part of a family (ex.: melee attack, range attack, magic, evasion, ...). A skill can be the parent of other skills (you have to take skill #1 if you want skill #2) or a skill can exist on its own without any parent. Here, if I wanted to have classes, I could just add a skill named Paladin that is the only way to access some paladin specific skills.

I have only 1 table in my database for all skills. It will be easier to deal with it this way. I have generic columns called value1, value2, ... that will stored the data needed for each skill.

So, what kind of skill will you have? For now, I don't know. I'll start with few and put more later. However, I pretty much have my mind set on to how they will work. I'm not really a big fan of "get new powers to kill more powerful monsters so in the end you're not really more powerful than before" scheme. And since I'd like to have PvP (my focus will be first on PvP, it will be easier to code, maybe not to balance but easier to code), I'm not really a fan of "I can beat you because I have [insert high level power here] macroed on my keyboard". I want to balance skills and not balance classes (fixed set of skills).

So I'd like to go a bit in the same direction as Eve Online (well, based on what I've been reading about since I barely played it). The focus will be to offer diversity to older players instead of giving them more raw power. When a new skill will be added to the game, I want it to be offered to old players AND new players (unless this skill is the child of another one).

So if we talk about combat, skills will look a bit like what we see in Urban Dead. Chance to hit will be a fixed % for each skill and damage will also be fixed. Attack skills will be balanced on 4 stats: chance to hit, range, damage and delay (cool down). Some more stats could be added later (something like side-effects) but I'll start with this. Here's what it could look like:

Basic melee attack
% to hit: 50
Damage: 3
Range: 1
Delay: 2 seconds

Basic range attack
% to hit: 50
Damage: 1
Range: 3
Delay: 2 seconds

Greater attack
% to hit: 30
Damage: 5
Range: 1
Delay: 2 seconds

Ultimate attack
% to hit: 40
Damage: 10
Range: 1
Delay: 10 seconds

Those are just quick-made skills just to show how it would work. As you can see, the skill you would use would depend on the situation. You couldn't really always use the same skill and hope to be equally successful all the time.

Of course, this bring up the question "If I'm dealing always the same damage, will you have powerful magic swords?". Well, I'm not there yet but the answer could be "Maybe, but never to unbalance this". Anyway, this is not part of my development focus right now. I do have some ideas but this will be part of another post.

So far, the basic mechanic of skills is done and I'm beginning work on combat (I needed the skills system first). The system to "buy" those skills is not yet implemented and is currently not important. For now, all I had to do was to make me 2 commands: /addskill and /removeskill

Read More......

A door only for exit

After thinking about Brian's comment about the /open command, I figured out that some changes would be needed. At first I thought this could all be hidden by the interface but I was wrong.

To enter a building, a door had to be created (prop) next to the building. When the /open command was used (the character needed to be on the tile containing the door), a check was made against the door to know in which zone (and coordinates) to send the character.

So a building didn't really have a door. From the start something was bugging me about this but I thought I could just live with it. Then I tried to link movement with the action of entering a building, that's when I saw I made a mistake.

So instead of creating a door prop for each building, I added a property to buildings allowing to specify where the door(s) is(are) located. So when a collision with a prop is detected, a check is made to figure out if it's a building. If so, a check is made to see if the door location fits with the location the character would have been if he was allowed to move. When there's a match, the character is taken to the new zone.

To exit a building though, it works much like before but now you don't need to use the /open command. The inside of a building is a zone just like any other and not "really" the inside of a building. A zone can be linked to 4 other zones (up, right, down, left). When a character try to move outside a zone, a check is made to see if there's actually a zone linked to the desired direction. If not, the character hit a "wall". Since I don't want to add the notion of doors to zones, that's why I still have to create doors to exit buildings.

However, this one was much easier to change. When a character hit the border of the zone, a check is made to see if he's on a tile with a door on it. If so, we check the direction the character wanted to go against the "exit direction" (could be "enter direction", doesn't change anything). If there's a match, the door will tell us where the character need to go.

Some minor changes that already make the interface a bit more friendly.

Read More......

Data structure

Thinking how your data structure (entities) will be built is always something you must do carefully. Because if you did a mistake or forgot a "use case", it will pop into your face when you have already half the application coded. That's about when your code start to get messy. I have seen (and done) enough projects that suffered from this.

Here's what I currently have for my MMORPG project. It's not finished but this currently allow me to have a world where I can walk and chat.

• Players
• Characters
• Inventory
  
• Props
• Props families
• Family Properties
  
• Props types
• Properties
  
• Zones
• Tiles
• Events
• Zone events
• Character events
  
• Chat
• Zone chat
• Character chat

Players - Characters

Simple. I separated those two so if I ever want to allow multiple characters on the same account, I can. This won't be part of the game at first since it's not critical. Already some less work here!


Props

Any object in the game is a prop. Buildings, weapons, chests, clothes. A prop only have a "prop type", name, description, properties and an owner.

The prop family is used to defined properties. Prop types are used to defined specific members of a family. So if I want to add a chest to the game, I'll first create a "Container" family. All containers have the same properties (space, locked, key, ...) with default values. Then, I'll create a prop type named "Chest" (I could then create another type named "Big Chest" or "Locker"). After, I just have to create an instance of a chest and set its properties to the value I want.

So once I've created a "Building" family, I can create any building without bothering to remember which properties I need to assign. If I need a new property for my buildings, I'll just add it to the family.


Inventory

The current form of inventory is quite simple. It's just a link between a character and a prop. I already did some preparation to allow stacking but since it's not critical, I won't spend energy on this for now. I don't need this to release a first version.


Zones

A zone is a part of the world and have a name, description, width, height and a default "type of tile" (grass, dirt, water). Each zones are made of tiles (a 15x15 zone would have 225 tiles). Tiles allow to set different kind of graphics to the map. With this, I can draw a road or create a lake in the middle of a zone.

For "collision", I use what I called "elevation" (it was called "level" at first but it was too confusing with the possible notion of character level). A character can walk on any tile with the same elevation as his. So a character currently on elevation 0 wouldn't be able to walk on water which have an elevation of -1 or a building which have an elevation of 1. By the way, there won't be any collision detection between PC, NPC.

There won't be any jumping or climbing. Creating a feeling of 3D would be nice but would be a lot more work. However, if I ever want to add those, the system is ready to receive it.

My current system allow me to have only 1 prop per tile in a zone. This limitation prevent me from being able to stack props on top of each other (say I want to put a plate on a table, the plate would have to be part of the table instead of being a prop on it's own). I thought about this for some time then decided that I would live with it. It's not critical and the current system is easy enough to understand and maintain.


Events

When a character or prop enter or leave a zone or when it moves, an event is added to the zone. This event tells the interface what it must show, how and where. If a character fight a monster and kills it, an event will be added to the zone telling the interface to show a graphic of the monster dead. All characters in a zone are receiving the events from it. This is what allow you to see that someone is moving from one side of the zone to the other.

Character events are received only by the concerned character. Say a character open a chest. The server receive the command, check if the chest can be opened and if so, send the content of the chest back to the character with a character event. Only the character opening the chest is receiving it. This could be useful to return a change of HP and stuff like this.


Chat

Well, chat is chat. It was actually quite simple to do. Each zone have it's own chat room and each character can receive private messages. Private messages can be /tell or can be just system message like "You can't open this chest, you don't have the key".

Since there was no need to reinvent the wheel here, I based my work on the example shown here.


Other data structure not yet implemented

Since this is a work in progress, there's still some pieces missing. So far, I'm able to move around and chat. While I know quite some players that are actually just doing this in MMORPG, I feel there's a bit more to do ;-)

Those missing pieces will be posted later when I have actually done some work on them.

Read More......

Game development diary now open and first demo of my MMORPG project

Like many persons, I once woke up with the desire to build my own game and I did. Chasing Tortoise is now online for some months now and I'm quite happy with the result. The game is stable enough to run with minimum maintenance.

While it's my intention to keep working on this first game, I was now ready for another challenge. Something bigger, more challenging. A MMORPG, I was going to start working on a MMORPG.

I already hear many saying "Here's yet another hobbyist aiming for something out of his reach". Indeed, how many times have we seen someone posting on a forum "Hey, I have a good idea and I want to know how to do a MMORPG. Can someone help me?"... Well...

I know what I'm able to do and most important, I know my limits. Trying to build the "next generation" game in 3D with the latest technologies is not something I can hope to achieve. While I have programming experience (it's my day job), I know nothing about 3D, C++, DirectX or anything else about how to build games like WoW, Everquest or Ultima Online and it's not my intention for now to start learning this.

However, I have good knowledge of ASP.NET, SQL and Javascript. Those will be my tools. If I want to get something done, I need to fit my project with my abilities. If you go read some "How to break into the game industry" on blogs like Raph Koster, Brian Green or Damion Schubert, you will see suggestions like "do a mod for another game", "start working on an existing MUD". While those are probably good (those guys pretty much know what they're talking about), I prefer to be the captain of my own ship. It will be more work but again, I know what I can go for.

So, how do you start a MMORPG? Well, I started by putting on paper what I wanted to achieve. I'm not talking about what name it will have or what will be the backstory. Those are useless since I don't even have a framework to build the game. I thought of using an existing tool but like I said, I want to stick with things I'm familiar with (and it's part of the fun too!). So the only option is to start from scratch. Do I want a graphic interface? Do I want PvP? Do I want trading? How is the world generated?

I builded a requirements list and put this in Enterprise Architect (helps to have those softwares at work). Still using this tool, I created my entities. I need characters, I need something to create buildings, weapons and other objects, I need a way to allow chat and so on.

Maybe 5-6 weeks later, I had something to start with. My idea was clear and I was now ready to start building my framework.

For the database, I'm using SQL Server 2005 Express edition. For my framework, I'm using VB.NET. For the interface, I'm currently using Javascript and some AJAX libraries. For communication between the interface and the server, I'm using web services and JSON. The interface for now is only needed to help testing and debugging so I'm not spending much time on it. Since I'm using web services, in the end I could decide to build a Flash interface but I think I'll be able to achieve what I want with AJAX. Anyway, the interface is not a priority for now.

The goal of this framework is to allow to create the game while playing it. It's currently not important to know what buildings or zones there will be in the game. I just want to be able to create them. So if I want to create a castle, I log into the game and type something like "/create castle".

After 1 month of work, I'm now able to show a first demo of how the system works. Don't pay attention to how it looks since it's not the point. Having nice little graphics would be of no help at this point.

Click here to see the demo: Demo 1

So this is the first step of my project. Add this blog to your RSS reader to follow this journey I'm already enjoying.

Read More......