This is a blog series about my determination to code an MMORPG by myself. In the series, I will be talking about general MMORPG architecture decisions I’ve made and some game design whims. With this series I wish to provide more information for those who wish to experiment with their own fantasy world as well as insights and entertainment for fans of this project. Have fun reading!

Part 3 – Finer planning and data structural layout

So I have three sets of API I want to combine to make a structure. That is, I need to put the basic functionalities in place (character movement, interaction, selection, etc.) before I can start putting the content (quests, level design, items, etc).

Thankfully both the database and the server software come native in Java. Still, while just coding the basic login, account creation, and the outlying features of the game, I was met with a lot of frustration.

I need to consider licensing and costs. For the free edition of ObjectDB, I can have 10 entity classes. That essentially means 10 tables in relational database terms. It is very important to decide which ones get a table by themselves.

As I said before I separated the login servers from the game servers. So I went ahead and created two databases. One is dedicated in storing player information, and any other data I might be interested in later on. The other is all about game information. Each game server will get its separate database.

Well then, let’s see what a game database will look like. I need a table for players, which will keep a list of information about that player in that server. The most obvious property is characters. A player keeps a list of characters.

But characters are also important. After all, most of the time we are dealing with individual characters, and not players themselves. So they also need a table for themselves. The main difference between getting a table and not getting one lies in the speed of lookup. As a rule of thumb, if you want fast lookup, consider making your class an entity.

So what now? What should a character store? I decided to simplify the myriad of things you might want in your character. First I created a Stat enum which holds all numerical data, in int. This decision is to make things neat. Of course you would want to multiply your percentages (like critical hit chance, etc.) by 100x or 1000x. I ended up having 26 values in my enum. Then I simply used a HashMap to map Stat to value, and finally in the initialiser, I used a for loop to set everything to 0, then set other stats individually.

With that out of the way, we don’t have a lot left! There’s a String for the name, an encapsulated location class for character position, facing direction, skills (a list), items (another list), guild, etc. Put what you want in your game here.

And that’s about it! After creating the stub classes for skills, items, guild, and so on, I can see a corner of my mmorpg data structure set up! My Character class is ready to record data!


Part 4 – Smart Fox, take 1

Dealing with Smart Fox Server is another matter. With prior exposure, I retained a few knacks of how things should be done. That did not prevent me from making several rookie mistakes that took me hours to resolve.

Nevertheless, I managed to sketch a plan of how I want my server code to look like.

I put all the fringe code concerning login server in its own package, and then started looking at how I should organise my code for the main game server.

Smart Fox consists of Zones and Rooms. From their documentation, each Zone is like a separate app. So I suppose A Zone represents a single server (this is convenient! At the beginning I can put Login and Game server on a single server without worrying anything). What about Rooms? Well since I decided I shall have a map based world (world that comes in discrete maps instead of a single piece that loads dynamically while you walk around, which in my opinion gives you a discrete sense of achievement – e.g. omg I made to the hardest map of the game~), each Room should represent a map then. This is great because then I can divide my code accordingly. Any code that concerns about general things (like movement, quest handling, etc.) will be put in the main package (folder), and any map specific (e.g. NPC interaction handlers) will be put in their own subfolders.

Part 5 – I lied, I still care about looks!

That’s enough stuff on the server side! I decided to look for some graphical assets just to have an idea of what I want the game to look like. I definitely do not have the people power nor the resources to get high-poly meshes and detailed levels and whatnot, which is why I rejoiced when I found out the PolyWorld asset on Unity looks exactly right for me! Styled art that is easy (relatively) to create! I gladly took the $50 price tag off my shiny new asset…went through a few tutorials, and there it is! A scene that looks pretty good this early into development!

Not bad at all!

I also fished for some paper texture online to get some more stylised looks on my UI. I know they will eventually all get replaced, but still. It looks pretty nice now!

Finally, I still have to hook up the client side! This consists of defining a protocol of communication between the client and the server, actually obeying it, and creating UI that goes with it to display results. The last bit is actually the hardest. Knowing what UI to use at which occasion is hard. I left most of them simple so I can verify that the client-server interactions are working correctly.

So that’s about it! At this point I have various things working, like movement, chat, selection and NPCs. I also have set up a server with Amazon so the alpha is live. In the next post, I will pull those apart and examine the components bit by bit.

Making an MMORPG #2 – Fighting with the API
Tagged on:         

Leave a Reply

Your email address will not be published. Required fields are marked *