Today we (3 students from germany) launched our DevBlog for our MMORPG Project Aleron.
This post will give you a small introduction to our project (Check out the DevBlog for more details)
Dev Blog: http://brutalhack.com/
Everybody says that an Indie should NOT start with an MMO.
So we decided to start with an MMO
Our goals for Aleron:
MMORPG with tactical combat
Tile-based turn-based combat system
Movement outside of combat is in realtime
Each player controls 2 characters
A characters skills are dependent on their equipment, no character classes.
What is our current status?
We implemented an MMO architecture consisting of one login server, several game servers and an arbitrary number of clients.
You can:
Create an account
Select a game server and login
Create characters and march into battle
We also implemented basic parts of our combat system:
Start and join fights
Choose your characters starting position
Turn-based combat
Move
Melee Attack / Range Attack / Heal
We create maps using our own map editor.
(Weâll share details about the editor in a future article.)
Some technical details
We develop in Java using jMonkeyEngine 3.
Our main IDE is IntelliJ Idea.
Data is stored in an Entity Component System, both on client and server.
Persistant data is written to a PostgreSQL database.
Thanks, after coding for a few years we agreed that this was the only proper way to describe the process of software development.
Regardless of how much we pay attention to writing clean code, coding always âfeelsâ like brutally hacking stuff together.
(Of course we pay a lot of attention to our code and we ate clean code for breakfast.)
As a big fan of Final Fantasy Tatics and Disgaea, I have to say: This is awesome! Iâve noticed your blog before, but didnât know it was made on JME.
Keep this going!
Also, I have to ask, where the name Aleron cames from?
Very happy to hear it being called awesome, thank you
Actually it was just me and some name generators. Looking for a âuniqueâ fantasy name.
Aleron is only the project name. The final game will probably have a very different name
To this I would personally add in the easier ability to introduce logical âdead locksâ. If said developer is thinking in a âsynchronousâ mind set (as in send a request then wait for a response) then the roundtrip to the server adds a huge wrinkle. In local processes, you might get away with that kind of logic 99.9% of the time but when your request is going to the server and back then you open the window much farther.
You end up with cases where the client requests some value and blocks for a response, meanwhile the server is waiting for something from the client that will never come because they client is blocked.
Better to be fully asynchronous when possible to reduce the chances of this. (As in, client might send a request but then it doesnât block⌠it handles the result when it comes back and the result has everything needed so the client knows what to do with the response.)
Using a separate channel for things that must block is another way.
âPeer to Peer is not viable!â
I generally agree with this. However, there was an interesting article I read some time back about a distributed peer-to-peer system that spread authoritativeness to peers that werenât part of the current game session. Seemed really complicated to me. (Canât find an easy link to the article anymore.)
Blog time! This time we share all details on the implementation of our machine learning AI!
If you donât know anything about machine learning, donât worry.
This article is written with Indie Devs in mind
(minimum 1)
but missing entries in you blog 
)
