Skip to content

Instantly share code, notes, and snippets.

@Jire
Created June 17, 2011 16:40
Show Gist options
  • Save Jire/1031771 to your computer and use it in GitHub Desktop.
Save Jire/1031771 to your computer and use it in GitHub Desktop.
CURRENT REVISION: UNRELEASED
==========
IF CURRENT REVISION is UNRELEASED, it means that the program has yet to be released to the general public, and therefore
does not need a revision number. Changes are made too often before release to maintain a CURRENT REVISION before release--
I'd be changing it every update I made, and that's a lot of updates. Only a select number of people WILL see the CURRENT
REVISION being set on UNRELEASED, so if you are one of those people, consider yourself...priviliged. :)
###TODO List (Goes by importance):
1. Reconstruct the thread model for the engine
2. Finish GUI plans
3. Complete the login pipeline so login works
4. Decide on the player and NPC model and how
###Current Error(s)/Glitch(es):
None!
###Changes:
v0.1.0B: Event management system completed, including both worker threads and full Event & EventManager implementation
v0.2.0B: ServerBootstrap implementation added for network port listening
v0.2.1B: SimpleChannelUpstreamHandler implementation started for incoming channel request handling
v0.2.2B: SimpleChannelUpstreamHandler#messageReceived() impl started, which means client-handling is the next step in
development
v0.2.3B: Full Netty networking impl added (full credits to `Discardedx2 from Rune-Server, see README.txt for details) WITH
proper basic support for the RuneScape #508 client
UPDATE: Starting revision changed from #508 to #562
v0.2.4B: Commandline logging impl added for advanced and organized event logging
v0.2.5B: Simple GUI starter created...no features yet (no features planned yet, either)
v0.2.7B: Eventhandling system redone; significant simplicity change! EventManager is now much smaller. Instead of using
a really advanced custom class for handling all the events, we used java.util.concurrent.PriorityBlockingQueue
to handle all the dirty queue work. Testing is now underway. Both worker threads were retained
UPDATE: Eventhandling system passes concurrency check for one event on each worker
UPDATE: Eventhandling system passes concurrency check for a large amount of events on each worker
UPDATE: Test eventhandling log created; includes a log of what happened with two tests. Both tests passed 100%:
PriorityBlockingQueue instantiated.
Thread A started.
Thread B started.
Event added to queue (normal)
Thread A looks for events and finds none.
Thread B looks for events, finds the new event, runs it, removes it from the queue, then lets go of the
lock on the queue.
------------
Event added to queue (high)
Event added to queue (high)
Event added to queue (normal)
Thread A executes the first high priority event, removes it, then looks again and finds the second and
runs it and removes it.
Thread B executes the only normal event, removes it, and all is back to waiting on the queue.
UPDATE: The current eventhandling system is expected to handle most game events perfectly well, but game events
are a definite step up from just printing a message in the console, so we'll see later on in the development
v0.2.8B: Benchmarking added to events to track how long each event takes to run
v0.2.9B: Pretend update server added
v0.3.0B: Login protocol procedure started
v0.3.1B: Login decoder finished
v0.3.2B: Entity and sub-class Player classes added: game world started.
v0.3.3B: Anonymous-level logging removed; method structure in com.rsemulator.log.Logger changed so that all external
users have to pass into them to print a message is the raw class type. The getSimpleName() is done inside
the Logger. Much cleaner usage of the class, now
v0.3.5B: Login encoder completed
v0.3.6B: Simple world server basis completed
v0.3.7B: Logging system removed; it was causing more problems than it was worth.
v0.3.8B: Player saving completed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment