Status for indi game developer
goldfreak
I stumbled upon your project, and it looks very interesting. Browsing
at the source, the code looks beautiful especially compared to
reddwarf. The transparent references and Dependency Injection could
really do wonders for code quality.
I am starting my own indi game, and I have been working with reddwarf.
Although the server works, all the ManagedReferences, as well as the
AppContext.xxxx really pollutes the code IMHO. This is from someone
that is using Spring heavily in his day job so not working with POJO's
seems very ugly. I would love to switch to dimdwarf, so I wanted to
ask on the status on it.
First the database. I see you are using an in memory database, and
that you are planing to do HA. I also found this:
Dimdwarf uses a custom in-memory database. It is planned to persist
the database to disk asynchronously.
I was wondering on the status of that asynchronous disk save, if you
have had a chance to do anything about it, and are still planing on
doing it, or are you going to rely on HA?
I wanted to know on the general status of your project. Is anyone
using it right now? is it usable, or will it be in the future? Would
you recommend jumping on board or not yet?
Esko Luontola
Didmwarf's architecture change is in progress and it's still missing
some core components which are needed for running applications. I wrote
about its status this summer at
http://groups.google.com/group/dimdwarf/browse_thread/thread/d33fa6a6a3868bd0#
and since then I've created some of the core components (controllers &
actors architecture, parts of network layer, authentication, deploying
applications) but some things remain until it can run applications
(client session management, session messages, task scheduling, in-memory
database).
Right now I'm able to work on Dimdwarf only a few hours per week (see
http://github.com/orfjackal/dimdwarf/blob/notes/workhours.txt), so the
progress is slow. By working 5 hours per week, I'm estimating it to take
6-12 months for Dimdwarf to catch up with RedDwarf's current
functionality (plus transparent references, garbage collection and DI
support).
My current recommendation is to continue using RedDwarf for now, and
migrate to Dimdwarf when it is ready. Of course feedback is welcome any
time before it, so please stay on this mailing list for latest news.
Converting a RedDwarf application to Dimdwarf should be straightforward;
I'll provide adapter classes for RedDwarf's API so that RedDwarf
applications can be run as-is on Dimdwarf, after which it will be
possible to remove managed references and switch to using Dimdwarf's API
one class at a time. The overall structure of the server application
doesn't need to be changed, and the client application doesn't need to
be changed at all, because the client protocol is the same as in RedDwarf.
During normal operation, Dimdwarf will rely mostly on its in-memory
database (I've implemented it once, but the architecture change requires
rewriting it - that means about 20 hours of work), but Dimdwarf will
also replicate all data on disk (in single-node and multi-node) and
other server nodes (in multi-node). I have not yet written code for the
on-disk persistence, but it's high on my roadmap. I'll first implement
the features which are needed to be able to run applications, and right
after that I'll begin working on the persistence, because it's critical
for production use.
Here is my current plan for milestone releases:
- Single node, in-memory database, capable of running applications for
development (minimal set of features).
- Single node, persisted database, ready for production use (same
features as RedDwarf, and some more).
- Multi node, centralized database, centralized directory, centralized
GC etc.
- Multi node, load balancing of client sessions, scales as servers are
added (if Darkstar has solved scaling by then).
- Multi node, rolling upgrades, database refactoring.
- Multi node, distribute previously centralized subsystems one at a
time, based on what is the bottleneck (profile first).
--
Esko Luontola
www.orfjackal.net
Esko Luontola
> Right now I'm able to work on Dimdwarf only a few hours per week (see
> http://github.com/orfjackal/dimdwarf/blob/notes/workhours.txt), so the
> progress is slow. By working 5 hours per week, I'm estimating it to take
> 6-12 months for Dimdwarf to catch up with RedDwarf's current
> functionality (plus transparent references, garbage collection and DI
> support).
Of course if somebody would be willing to sponsor Dimdwarf's development
by hiring me to develop it full-time, then I could catch up with
RedDwarf in a couple of months.
How long it will take to complete the multi-node version is harder to
estimate. Making the software run on multiple server nodes is not too
hard, but making it scale well requires solving some research problems
which AFAIK have not yet been done before. The biggest question is that
how to detect automatically that which tasks modify the same data, so
that they should be located on the same server node. There was some
experimentation on community detection algorithms at
https://games-darkstar.dev.java.net/servlets/BrowseList?list=dev&by=thread&from=2084098
before Darkstar was closed by Oracle.
--
Esko Luontola
www.orfjackal.net