On Graphical User Interface

The Graphical User Interface, known as a GUI or UI is one of the most important aspects in a game. It is what allows your player to understand the chaos of the game world. The UI gives the player information that if the game were real, the 'player' would already know, eg. Your health. The human doesn't have some meter attached to them telling them how healthy they are, no. A person knows when they are sick, or if they get a cut.

My current project has been key bindings in a GUI. Anyone who has played World of Warcraft or many other games with a multitude of abilities or spells (Dragon Age: Origins, another example) knows that you don't always have room for every ability or spell on your GUI and it ruins the game experience to have to open the spell book to cast a spell every time. This type of GUI mechanism is called a QuickBar. Each slot on the bar is bound to a key. At anytime one can either change to binding of the slot, or the spell in the slot.

First i wanted key bound spells. So i sat down and attempted a flat out c# solution. No success. Now, either i'm missing knowledge, (which is very likely) or it just isn't possible in a language like C#. To fix this i used the Lua wrapper, LuaInterface. It wraps Lua into a dll (for windows) and gives the programmer access to a Lua Virtual Machine. You can feed to VM scripts, which it compiles during run time and executes. I wrote a simple script that takes in a C# method and a key, links them together in a table, and when given a key, calls the linked function. Problem solved.

Now for the GUI implementation of this.... which is a WIP. I've currently coded the QuickBar and am researching live Combat Systems to get a better view on spell effects and such.

Until next time,
TNariksan.

On Scripting

One of the more useful features i have come across is a scripting language. From may WoW days, i picked up a little of the language known as Lua. Its is a dynamically typed object oriented language. Meaning you don't define variables, and variables can even be methods. That's right, METHODS!

While trying to conquor the problem of key binding, custom user key binding (Aka, the user can set any key to do whatever they want), i came upon a problem. How to do this? I can't just assign the key 'K' to execute, WalkForward(). But with Lua, you actually can, in a way. You can use a table(with a key and a value) to use 'K' as the key and WalkForward() as the value. Now that i sit here and type this, i am most positive (not 100%) that C# probably as a similar data structure, possibly. Though i will still stick with the Lua fix because writing in a scripting language will much improve my game in the long run.

Ask yourself: Why is WoW so popular? It's because you can nearly do WHAT EVER THE HELL YOU WANT.
Custom GUI, here you go.
No Gui? Got your keys memorized? Sure. Macros, hell yeah.
GIANT ASS WORLD?! Got that too.

This is what i aim to replicate. The sheer depth of the game. Players will customize the game, i only provide the means to do so. This means custom armor (yes, you will be able to make your own armor, no not in the traditional, 'smithing i need 5 copper and 10 bronze to make a chest plate' No, you'll be able to mix and match metals to make alloys of various strength, the mix will determine what colors you can have your armor appear, its resistance to damage types... and so on.) custom building, custom enchantments, i've even thought about a language that would allow you to write words down in books, then if you click on the books, it would cast a custom spell.

All this would not be possible without a scripting language. Scripting means compiling while the game is running. You don't compile it until it is needed, that is the beauty of it, along with other things.

To Sum It Up: Scripting is beautiful, use it to take those leaps you couldn't with your core language. Learn a scripting language. Use one, it can make your life easier.

TNariskan.

On Positioning

While coding the element that would allow the player to select a target I ran into the problem of assuming the reference point of my sprites (2D pictures) was in the upper left hand corner, as was the default. For the animation of my sprites, i use code written by Microsoft in their Platformer XNA Demo. The reference is changed to the middle of the bottom of the sprite (for collision detection reasons). After a good fifteen minutes of staring at the normal rectangle bounding intersection statement, i came to realize this and corrected the problem. Only now it works, but only if the mouse if anywhere off to the upper left, yet not inside the actual sprite. Just one of the many bugs a programmer may run into.

TNariksan.

PS. I will attempt to answer any bug questions posted if you may be having similar problems. Also, i apologize for not posting more. More on my latest game system to be implemented. I'm working on a system that would allow the players to learn words (in some lore related language) that would be able to be combined with any other words to create effects, being a totally dynamic system, it has to be nearly bug free.

On Libraries and Overall Architecture

A very useful tool if you may be reusing classes or large parts of code in different applications is a Library. A Library is a collection of classes one can use simply by adding a:

 using LibraryName.Subfolder;  
 import LibraryName;  

at the top of your code. (using for C# and import for Java). I have many classes i reuse on both the server and client, for example a Class.

##Note: from here on out, Class will indicate an RPG class. class will indicate a code class.

Eg: Class - Mage. I have to reuse a lot of the damage and or stat calculators as i calculate data both client and server side. Instead of simply copying classes from folder to folder and worrying about whether or not both classes are updated on both the server and client, i can simply edit my Mage class on the server and it will update on the client.

THE DOWNSIDE: You cannot address the client or the server from your library code. I'm running into problems where my network streams used to communicate from the client and server cannot speak directly to my client or server code. I have to use a retriever to extract variables from the stream classes. It is a work around, but not the best coding practice. Normally you'd want to use a method from inside the class to pass variables out.

Architecture is something many people over look when building their programs. Of course, the user will never see just how your code works, unless you a) open source it, or b) allow it to be read. (Blizzard has released a viewer so you may read their code, some funny comments in there.) I like designing architectures. The overall structure and order is needed for me. Some developers program as they think up ideas, or some dive right in. But i like to take it step by step. Today improved my class system with a better inheritance:

Classes:

      Caster                                                                                                                              Melee

Healer            Damage                                                                            

Monk,         Tempest, Mage                Knight, Reaper, Titan

Poorly formatted, but you get the picture. Healer and Damage(Caster) inherit class Caster. while at the moment  Knight, Reaper, and Titan inherit Melee. Monk can inherit both Healer and Damage, or just Healer, haven't decided. And Tempest and Mage inherit Damage. This does not mean one Class can only use Healing abilities or Melee abilities. Each Class will be able to use any abiliy, or a large range of them, however, one Class will be better suited to heal or deal melee damage.

Architecture is important, you have to know how your code will work and the most efficient use of code. Languages provide a powerful reuse system already with inheritance. In C# the only thing one must do to inherit is thus:

 public class Mage : Caster  

However , Java must supply a type of inheritance:

 public class Mage extends Caster  
 public class Mage implements Caster  

 The first means you may modify any existing methods in the parent or super class. The second means you are using an interface. More on interfeces later. They are very usefull for RGP's and being able to define many different classes with one statement. (Quick example to clear that up, horrible wording)

EG:

Player testMage = new Mage();
Player testKnight = new Knight();

Player would be the interface here. I'll explain them fully in the next entry. For now, tata.

Push on my friends! Many happy coding adventures.

TNariksan.

On TCP & UDP, aka Networking

Over the past week, I have been hard at work getting a working protocol system implemented. As of today I am capable of updating the client with player coordinates and sending and receiving text messages. At first i began with a basic chat client server set up. The server spawned a new thread every time a client connected to it. Before i moved on to implement it into the game the chat server would only receive messages, not echo them to other clients.

Now i have moved on to a dual network stream per client structure. After extensive remodeling to my current set up of the game, i decided to cut my losses and create one simple library to be shared between both the server and the client. That way i could reference my classes without having to copy them over and worry about dependencies. Previously I had a rather strange system of inheritance.

A class, as in RPG class, not programming class. Say for example, a mage class. The class mage inherited an interface and a super class containing only variables. After reexamining C#'s inheritance system, my super class now inherits the interface and mage inherits the super class. However, one could remove the interface entirely and only use a super class, but that would take a little more time and possibly bug fixes.

The problem i am currently facing, is with my library, i designed most of the classes to be server side, thus they are essentially backwards on the client side.

EG: The server waits for a connection, so the client is supposed to be the one actively seeking the connection. Yet my current system has both client and server waiting at first. Problem? I think so, no connection would ever be made.

So that's where i am. Oh, and I'm also attempting to send the world data (its size and client.player id) to the client instead of it loading from the client's computer.

A quick note about UDP vs TCP. (I think it's important to know the difference)

first: UDP and TCP are both internet data relay protocols. UDP is built for speed while TCP is built for dependibility.

UDP says:
Server: HERE! THIS IS DATA! TAKE MORE DATA! HAVE ALL THE DATA!
Client: .......

TCP says:
Server: Here my good sir, have a little bit of data.
Client: Why thank you, this looks like x data.
Server: Why yes it is.
Client: Cool, thanks.

So as one can see, TCP involves more communication, but will make sure your data gets to the right place, while UDP just spits data out and doesn't have any client to server communication.

Personally, i'd use UDP for less crucial tasks, like updating a player's money, or their items in inventory. But for stuff like, player position or health, it would be good to use TCP.

If you have any questions, just ask!

TNariksan

MULTITHREADING

One of the more advanced topics many programmers may eventually come to face: running multiple things at once. Today I wrote a simple multi-threaded chat server. It may seem trivial but the more advanced application would be to easily upgrade it with protocols to tell your clients what the server looks like.

There are two types of MMO servers:
Server Heavy or Client Heavy.

Server Heavy: This requires a more powerful server, as the name may hint. In this format the client simply sends a command to the server that the player is moving forward, not that the player moved x amount forward. This type of server is less liable to hacking but requires more processing power as the server is doing all the calculating and not the client machine.

Client Heavy: This is the inverse of the above. The client does all the heavy lifting and the server only relays positions of other players back to the client and the game state.

For an MMO server, one must multi-thread. You should have a thread for each player or their connection. In my server, a new thread is spawned for each new connection made to the server.

More to come,
TNariksan

Release of the Alpha

Today I release an alpha version of the game I will be integrating to MMO status. It is a very rough platform. There are nearly no comments and scraps of unused and obsolete code laying around. Later this week or early next I'll release a cleaned and commented version.

Cheers,
TNariksan

The Summary:

To the first post. First off, a history.

My name is Tony, and I am a coder. I have been interesting in the computer sciences for a few years now, about  five years in total. At first, I floundered about with Lua not knowing much about how anything worked. I clumsily bumped my way through Lua with World of Warcraft. I come from a medium intensity, recreational gaming background. This blog is to mainly focus on the gaming side of programming. After foolishly attempting to teach myself Lua, I found Java. Having worked with Java for three years now, I do much like the language. Very simple to understand and easy to learn (for me). I am an Object Oriented kinda guy. However, in my latest endeavors, I have mixed the two, OO and Procedural. About a year ago I discovered XNA (XNA = Xna is Not an Acronym). I have recently been working on an MMORPG game engine and thought I might document the process.

Post Script: Someday I will offer Java and XNA/C# video tutorials.

TNariksan