Recent Topics

Yeah... so we have a female Broly. by ILFICOSACRO
[Today at 06:47:41 PM]

Que paso con los Domingos con DBOR? by Aeris
[Today at 02:09:36 PM]

I need an update :/ by Tofu
[Yesterday at 03:29:45 PM]

Dragon Ball Super by Roxas
[February 16, 2017, 06:03:55 PM]

Dragon Ball Z Dokkan Battle by LordWilhelmIV
[February 16, 2017, 03:36:26 AM]

View Desktop Site View Mobile Site

* ShoutBox!

Refresh History
  • Keep it Clean! No Advertising!
  • Today at 03:46:34 AM
    Mostly because Breath of the Wild, but I'm still interested in trying out Splatoon and stuff.
  • Today at 03:46:00 AM
    The Switch is definitively a console. Sure, you can take it around and stuff, but considering it's size, it won't be as easy to play on the go as the trailers suggest. Like I said, I still like the concept, but that's not the main reason why I wanna buy one. The Switch is definitively still top in my console purchase priority
  • Today at 02:38:50 AM
    Be you don't care about the games or you for some reason really care about 4K graphics that the PS4 pro and Xbox 1s have .
  • Today at 02:37:56 AM
    It is a console ? How does it ruin it being a console ? It's not one or the other it's literally both . It's kind of a stupid argument , not to mention if you consider it as a handheld it would be the strongest handheld out there . It's the equivalent of having a portable pc or gaming laptop but it goes to your tv . A better argument would
  • Yesterday at 05:51:42 PM
    I do like the concept anyways, but that's probably not the reason why I'm getting it (if I can ever pay for it, that is)
  • Yesterday at 05:51:22 PM
    It's awesome that you can move the Switch around, but it sorta ruins the whole point of the "console."
  • Yesterday at 09:50:54 AM
    Again, that's just me.
  • Yesterday at 09:50:47 AM
    I do find the Joycon stupid tho.
  • Yesterday at 09:50:19 AM
    Then the answer would be, go for the handheld. Right? Don't get me wrong. I don't have anything against the Switch. I just don't like it. The idea is okay, but for me, if I wanted a console I would buy a PS4, as I did. If I wanted to buy a handheld, I would buy a handheld.
  • Yesterday at 07:43:26 AM
    Manphu , um your 1. Point doesn't make sense on the account that some people like to play in the living room and some play in the bedroom and while I think the idea of kind of stupid as an employee on electronics people are for some reason always buying a second system just to play in another room instead of just moving it .
  • February 18, 2017, 10:07:35 PM
    1st. Xbox is not a console to be played on another room. That's askinf from a turtle to fly. 2nd. Joycon is good for all games. Yeah, go play SF or any fighting game on it. It will be perfect. 3rd The PS4 controller not top Tier, nice joke.
  • February 18, 2017, 11:51:27 AM
    since i didnt test them yet
  • February 18, 2017, 11:51:23 AM
    cant say nothing about the joycons
  • February 18, 2017, 11:51:18 AM
    was talking about the wii u pad
  • February 18, 2017, 11:50:03 AM
    They got more features than a PS4 controller anyways
  • February 18, 2017, 11:49:35 AM
    Why do you say the joycons are bad controllers is what I should say
  • February 18, 2017, 11:48:59 AM
    Duck plz , everything is optional they give you more than enough to work with . You ain't forced to do shit .
  • February 18, 2017, 11:48:24 AM
    you telling me the ps4 controller is shit?
  • February 18, 2017, 11:48:22 AM
    >joycon isn't a fully functional controller you can use for all games .
  • February 18, 2017, 11:47:56 AM
  • February 18, 2017, 11:27:50 AM
    you ratchet hoe
  • February 18, 2017, 11:27:25 AM
    you aint forced to upgrade it
  • February 18, 2017, 11:27:18 AM
    the ps4 actually gives you a good controller when u buy it tho
  • February 18, 2017, 10:40:43 AM
    People got a double standard for Nintendo I swear
  • February 18, 2017, 10:40:15 AM
    80$ for two controllers . How much would 2 new Xbox controllers cost ? The Sam of not more since they are usually 50$ each but I think they lowered it to 43$

Topic: Development Diary #2  (Read 16767 times)

0 Members and 1 Guest are viewing this topic.

Development Diary #2
« on: July 21, 2014, 01:23:36 PM »

    Offline Luke[Dumke]

  • Administrator
  • Dragon King's Focus
  • Honor: 168 / 1
  • Posts: 2,988
    • View Profile
  • Project Leader
  • I am a: Great Namek

You can discuss this announcement here:

Greetings all,

Here is the much requested Development Diary #2. This development diary is going to be fairly technical as we've been getting some technical questions about our core server and other development related topics on the forum and from the AMA. Hopefully it's not too boring to anyone.

At a high level, the server has two main parts: network and simulation (of course, there are others like the database, but let's ignore that for now).

For the network side, There is the network thread pool which handles all the connections and inputs from players, the simulation is the core of the game play. This is where the world, and all the game objects (players, npcs, and everything) are, as well as all the game logic.

The simulation consists of many subsystems, In our initial list, we have spec'd out more than 40 subsystems. From simple ones like inventory or mail, to more complex and heavy ones like collision detection. And I'm almost positive that there will be more as we go.

All these subsystems communicate with each other via events. Each type of events can be subscribed to. In our last sneak peek video where you see a simple combat, it was basically a test of a combat event flow among a number of subsystems.

Here is a quick step through on how different subsystems worked together in that example:
  • When the player starts an attack on a mob, it sends an event which the combat manager has subscribed for.
  • The combat manager starts the combat logic between the two objects. Each round of attacks it will fire off events that get sent back to the player like damages and LP/Lifepoints updates.
  • When the mob dies, an event is fired off again to indicate that the player has killed the mob.
  • The player manager that has subscribed to this event can award the player with experience point, while the drop manager that has suscribed to the same event can award the player a drop of money or, like, 7 dragon balls ;)
Similarly, the quest manager can subscribe to this event to update the player's quest progress (if killing this mob is part of a quest).

Having subsystems not only make things more manageable, it also makes it possible to have them running in parallel where we see fit. It also allows us to move a subsystem to a different process or a different host, which makes the server more scalable. For instance, the collision detection or the proximity manager might get overloaded as we get more and more players.

I'm not saying this design is perfect (and it definitely isn't), but this is what we've been working with. I'm sure our design will be broken, changed, and improved as we progress.

There are also things that we have implemented purely for development benefits. From simple things like auto login and auto character selection, to things like a special server mode which we can terminate the game server, make some code changes, recompile and restart, all that while the clients stay connected and without the need of restarting. Of course, some states of world are not preserved after a restart (not yet anyway since there is no point), but it does help a lot when testing various areas of the server.

This quick video demonstrates this:

The two players could see each other's movements, until the game server was stopped. Both clients stayed up without knowing what had happened. When the server was brought again, things were back to normal. You can also see how the npc's positions were resetted when the server was restarted, as their states were not preserved.

I'm also in the progress of writing up some test clients so we could do some early profiling and stress test, and I'll post a video of it when I get to it.

Apart from writing actual server code, we also need to do a lot of reverse engineering to see how the client work.

A lot of people think since now we all have the old client source code and libraries, it should be easy. Well, the old source code does help obviously. But the fact is a lot of the protocols, packet structures, data tables, etc have been changed. Some of them took us more time to work out.

Unsurprisingly, we have also found that even the TW client has a different build from the HK client in terms of protocols and packet structures, and they are incompatible with each other.

Meanwhile, the client will just crash if you send it just one byte (or bit) of incorrect data, and there is no easy way to debug without the source, assuming you don't count the assembler code as source ;) And since we are writing everything from scratch and not relying on any existing DBO/NTL's code, this makes the process a pretty long one.

To sum it up, our goal is certainly a big and an ambitious one, but we are happy with what we have done so far. And once again, thank you for the patience.

I would also like to say a few words about other DBO projects that's been going on. I personally think they are all great. And as a developer, there's nothing more exciting than seeing people taking interesting in programming. Different projects will have different directions and different ways of doing things, but ultimately we all share the same goal - bringing DBO back. I truly wish that we can all respect each other, respect each other's work, and respect the differences.

Well, I think that's all for now. I hope I can do more this kind of write up more often. If you have any questions, feel free to ask and I'll try my best to answer.

Thank you!
« Last Edit: August 08, 2014, 02:51:48 PM by Luke[Dumke] »
Project Leader for DBORevelations || Contact Email:

"We'd rather under-promise and over-deliver"