|
In order of no progress to done:
Red,
Orange,
Yellow,
Blue,
Light blue,
Green,
Light green.
Last updated 2/12/09 at 12:01 am PST
Cripes! 2.0 -- See the Class Layout
Arenamatic Code w/ cConsole
  Short update on Nucleus | 
Posted - 7/16/2009 8:13:01 PM | Nucleus is moving along nicely, although for some reason I keep putting off the event queues in favour of other features that, while essential, really can wait a little while. 
One such "essential" feature is support for loading external modules. This may seem obvious  , but until now my test modules have been in the same project, and thus loaded at compile-time for me. I did a little research into ClassLoaders, and found a standard URLClassLoader class. I can (indirectly) pass it a File object on construction, which means I can directly control where to look for classes without relying on the classpath.
The idea is to have a configuration file containing everything the Nucleus needs in order to run. One of the datums involved is a list of paths to look for modules in, which allows the user to decide exactly where the modules will be sought after. (The configuration file itself will be found either in the same directory as Nucleus, or passed along as a command-line argument)
These detour-ish additions are vital to Nucleus, because they give power to the user. You could run Nucleus with one configuration file as the "main" server, and another file as a "development" server. And I'm working on some so-called "hotloading" functionality, to allow modules to be reloaded at runtime. It'll certainly be interesting, that's for sure. 
| |
| matt_j is gonna kill me | 
Posted - 7/15/2009 4:04:23 AM | Sorry Matt... Cripes 2.0 is frozen indefinitely. 
In slightly happier news, I've made quite a lot of progress on a new Java-based project of mine, called Nucleus. It's a modular, event-based system that heavily utilizes reflection, and the idea is to use it for MUDs.
Nucleus - The extensible MUD kernel
The idea behind Nucleus is to implement low-level details like networking and timers, basically supplying basic features, while also allowing third-party modules to be loaded for extra functionality. Each module runs in its own thread, protected from the other threads except through certain core mechanisms, such as events. And speaking of events, each module is backed by an event queue in the core, which calls the module's Main() method after it's done with its current event.
If a module really wants to run independantly of events, it can create a separate thread (or threads), but the Nucleus won't care in particular.
One of the planned modules is an interop module, acting as a binding between Java and another scripting language. There will be one interop module for any given language, and you can plug any of them into the Nucleus to allow part of the application to run in another language such as Lua or Python. This is the planned route to implementing MUD logic. You could even write your own language and binding module; I know many MUDs use a proprietary language for their scripting needs.
The Events System
One of the bigger obstacles for me was defining an acceptable events system between modules. Obviously, no module can be expected to accept any kind of event argument. After many days of thought, and one night of particularly hard thought, I came up with a pretty easy solution. There are three kinds of events in the Nucleus: Broadcasts, Events, and Requests.
Broadcasts are sent to every module. To allow this, I just create a Broadcast type in the core. Simple, because every module will have access to the core packages anyways. This could be used quite easily for input to a debug-logger module, which takes any broadcast it hears and writes it to a file. No module would be required to make any changes to accommodate the logger.
Events are sent from one module to another. This implies that the source module has prior knowledge about the second. This also restricts the kinds of events that can be sent: only ones the target module knows about. It's relatively simple from there to suggest that the target module define events it will accept, and have the source module import those events. The only part that's in the dark about the events themselves is the core, and it will solve this by looking for a @NucleusEvent annotation in module packages, reflectively loading their definitions as Class objects and storing them per-module.
Requests are much the same as Events, except that the target module is expected to return a value. Simply marking a named method with a @NucleusRequestable annotation is enough to trigger the core to load the proper definitions.
I want to put some code up here at some point, but right now I'm still working on actually implementing this system.
~Jonathan
| |
|
| S | M | T | W | T | F | S | | | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | | | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | |
OPTIONS
Track this Journal
ARCHIVES
August, 2009
July, 2009
March, 2009
February, 2009
December, 2008
November, 2008
October, 2008
August, 2008
July, 2008
June, 2008
May, 2008
April, 2008
November, 2007
July, 2007
June, 2007
May, 2007
April, 2007
March, 2007
February, 2007
December, 2006
October, 2006
September, 2006
July, 2006
May, 2006
April, 2006
|
