I did a bunch of work on it yesterday (and today), here is the progress report for yesterday - I'll post the one for today a little later...

Today, I implemented several things I am now very excited about. I am nearly ready to start working on the game and not just the game engine now!

Here are some features I added:

• Implemented quest & quest task system. Quests are polled & issued to the player via Map Startup scripts (a new feature I added) and NPC Scripts.
• NPCs are fully scriptable, their logic is defined in three individual files. The first is the js (javascript) script file which allows one to program logic such as dialog routing\driving & quest polling\tasking. Basic things like battle logic can also be described there. This file is linked to by a jnpc (jeva npc) file which describes basic attributes of the NPC such as View Distance, Field Of View, Visual Acuity, Visability Factor etc... This jnpc file also links to a jdf (Jeva dialog file) which describes different routes in dialog one can take when talking to a NPC.
• Quests are now described in individual jqf (Jeva Quest File). Quests can contain several tasks - and are directed by the logic which issues\drives the quests (i.e, NPC, who can select its dialog via its jsf by polling the status of quests.)
• Improved UI Element TextArea, now supports formatting characters such as \n (newline)

Below is a short video I created demonstrating this (what you see in terms of quest and NPC interactions is fully scriptable):

http://www.screenr.com/3zCH

Lots of progress since the last update - wow. Just been too busy to post the progress reports inbetween builds. I would psot a running applet, but at this stage, the process of obfuscating and protecting code has become much more complex and I will only put myself through it when I need to.

Lots of exicting stuff now. I just finished the four main components to the game\engine and have hopefully (for now at least) written the final lines of code for all of the them in terms of their core code.

I have implements the Character Dialog Editor, the Map Editor, completed the Core of the engine, and completed the RPG Game extention to the engine. This means from here on out, I am just editing map files\script files\other resource files to get the game I want running on the engine (you may see a resource request on OGA coming up soon.)

(The mouse effect isn't me, it is the video recorder.)

http://www.youtube.com/watch?v=0uwxNC3ZEaw

Throughout this video you will see all except for the Dialog editor which started throwing some exceptions last minute and I couldn't include into the video. Essentially though, the dialog editor allows you to create complex dialog paths and have parcticular events raised when an option is chosen, or when a route taken etc in the dialog. The NPC can then invoke the dialog starting at different entry-points based upon internal script logic (like how far is this character on quest X)

You can see in the scripts how quests are accessed etc (in the video).

In the video you see the RPG Extention - there is nothing stopping you from writing an RTS extention as well. Quests are not an intrinsic property of the engine, and they are implemented via the RPG Extention with just a few classes.

TLDR: Just watch the video here http://www.youtube.com/watch?v=0uwxNC3ZEaw and pelase leave some feedback - even if it is just full of complaints!

I'm working on a little story I can implement into the engine to show-off and hopefully get some people for a different project that will use the same engine.

In that story, there are a couple scenes outside, I just quickly whipped this outside scene up (I am a horrible mapper\artist) using http://opengameart.org/sites/default/files/grassland_tiles.png in my map editor

Here is how it looks in-game:

Thanks for the input Charlie. I don't know where I stand on making this open-source. It is definitely something I would like to do and something I have considered - but I think it would be bold of me to make such a remark this early in development. So I'll leave it at: I hope so eventually. Until then, I know there are tons more powerful open-sourced Java isometric engines out there.

Here is where the game engine & game is so far, I intend on writing a few more quests - I want gameplay to be about an hour before I release the game.

http://www.youtube.com/watch?v=sjMPOPcpZzU

Some notable core changes:

While I said I wouldn't be making any more changes to the engine I am afraid today was forced to make a few:

- Moved the playSound script bridge routine from Actor to Entity. It didn't make sense to introduce this routine to objects only after they inherited Actor and I figured it made more sense to allow entities to also omit sounds.

- Introduced a leave() script bridge command in the entity object. Entity objects can now remove themselves from the scene via script. This is useful for when you want an entity to walk off of the map and then disappear.

My screen recorder video did an outstanding job at absolutely wrecking the image quality of a playthrough video, so I instead decided I would just post screen-shots of the engine's progress.

For anyone interested, I also maintain a blog on GameJolt where I plan to eventually publish this game:

http://gamejolt.com/profile/jeremywildsmith/blog/84041/

It is the only Java games platform I have found that supports Achievments and provides Cloud Storage. Any other ones floating out there that people are aware of?

Armor games is Flash only... hmm.

Just did some small core optimizations - the engine can handle absurdly large maps now (I tried with 500x500 and it was rendering fine.) All those tiles were static - but there typically won't be many dynamic tiles in the world map.

Anyway, I'm implementing an inventory system for game characters now - along with that will naturally come along a looting and trading system for the RPG Extention.

Hopefully next week I can implement basic networking (really, the way the engine is structured right now, I don't think it will be much of a challange at all to inherit a few classes and implement a networked solution.) The engine partitions the CPU time into sectors and only renders visible sectors. All entities and dynamic tiles have their logic updated regardless to how visible they are though - it's only static entities\tiles (which is I'd say at least 85% of the map) that actually benifit from this optimization. Since nearly all tiles on a typical map are static, this is quite good.

I've now implemented items. Each item can be bound to script to perform a scriptable routine when consumed. Weapons\Armor can scripted regarding how & what to do to the attackee & how to scale the attack damage on the attackee\attacker (i.e, armor will scale down damage or negate it completely if it is fire armor vs. fire weapons or something.) A fire sword might ignite the target on fire etc...

Here is a screen-shot showing the looting system I created. I am going to add an onEnter function invocation for entity scripts so they can properly initialize, for now I just use this hack (This is a quest spider, so its script is a bit more tedious than usual) You can see it provides itself with a health pack at the initialization routine that it can (itself) consume using me.consume(...) or it can keep it and die with it so that the player can loot it later:

[code]
var isDead = false;
var init = false;

function onInteract()
{
    me.cancelTasks();
    me.dialog(0);
}

function onDialogEvent(eventId)
{
    return -1;
}

function onIdle(isIdle)
{

    //Stupid init hack until I implement an onEnter function.
    if(!init)
    {
        init = true;
        me.addItem('item/healthpack.jitm', 1);
    }

    if(isIdle && !isDead)
    {
        if(game.getQuest('quests/almostatcontrol.jqf').getTask('initial').getState() == quest_inProgress)
        {
            me.idle(2000);
        }
        else
        {
            var target = core.getEntity('player');
            me.moveTo(target.getLocation().x, target.getLocation().y, 1);
            me.attack(target);
        }
    }
}

function onAttacked(entityInfo)
{
}

function onAttack(attackee)
{
    me.playAudio('audio/spider/sight.wav');
}

function onDie()
{
    isDead = true;
    me.cancelTasks();
    me.playAudio('audio/spider/die.wav');
    game.getQuest('quests/almostatcontrol.jqf').getTask('helpEric').setState(quest_completed);
}
[/code]

Finally got a solid quality recording uploaded:

http://www.youtube.com/watch?v=kNLXVcxmFSM&feature=player_embedded

Today, just refactored some code and implemented entity state saving\restoring.

I've done tons of stuff today:

 - Implemented a basic particle engine for blood\projectile\healing effects

 - Added Character menu screen that shows level\equipment

 - Fixed several UI bugs (actually, mostly this week I have been profiling and tracking down bugs)

It is a quick particle engine implementation, it can handle ~30000 until the lag gets pretty bad. I can optimize in a few places but I won't bother because I won't have more than >1000 particles on the screen at any point in time with the game I am going for.

Anyway, here are a few clips of the particle engine in the game doing some stuff - they still need a bit of fine tuning:

Attacking (Blood effect):

Medium amount of particles

Absurd amount (15000-30000) particles on the screen:

New game-play video showing off a bit of the combat system and item system:

http://youtu.be/G0bxGhwkaNs

Thanks for the response @JblueEntertainment

This game in particular started as an excercise for the engine - so I could figure out where some core limitations are etc.

Here are some idea I have for the engine, the current one is pretty simple, ntext next few are complex in nature (simple to implement) and likely appeal to a smaller audience. (I'll be brief)

Now, lol, give me a break because I am not a great writer.

The current one:
[inspiration: Looking at the assets I have on hand and trying to put together a game to excercise the engine]

Essentially, you are a military solider who has woken up from a short state of unconsciousness - you are unsure where you are and what has happened to you - you hardly know your name. You learn that you where the leading member of a small squad that had accompanied you to what you later discover to be 'Sector 3' - an enclosed area full of biological life in a very large military research facility. 
 
You hear a gun shot and upon investigation you discover a solider - the solider tells you that he was sent to recover you and explains that you are in Sector 3 - the 'playground' for biological warfare and development - i.e. creepy biologically engineered species developed for warfare\research call sector 3 home. 
 
You encounter creepy and disturbing experiments performed - enlarged spiders, fungus that infects test subjects and turns them into zombies etc. Once you return to what the soldier, Eric, calls 'control' you discover that the research center has had its security breached and that all the biological research subjects had escaped into nearby general population. The game ends as you fight your way through the sectors to come to this realization that you now live in a post-apocalyptic world.

The one I hope to develop later:
[Inspiration: Notches incomplete game 0x10c]

I discovered an incomplete\unreleased game by notch called 0x10c - it was mainly about space exploration but that wasn't really what made the game great. Each space-craft had a programmable CPU onboard it - users would program their own operating systems and write their own emulators for an instruction-set that wasn't even developed - this was the heart of the game. Users _loved_ rewriting what we had years ago - people tried to implement DOS clones etc and it became an incredibly popular games based off of fan emulators etc. Something in us drives us to these challenges and I think it is what makes a game really great. People would have conversations regarding security, hacking, etc.

So my idea was to implement a sort of 'server-tycoon' game. Each user would be provided some initial funds and could purchase a 'server' (the server would be a virtual computer - a very primitive virtual computer - I'm talking 16 bit, no memory managment unit etc - 100MHZ - this challenge is what made 0x10c so popular). Those 'servers' could interface with virtual peripheral devices like keyboards and monitors. Then, the user would connect their virtual server house with a game server, or the game-lingo term would be "ISP" and they would be assigned an "IP Address" (really just some sort of way the game server can ID the user) these servers people write the software for could then communicate with each-other, people would create their own virtual 'internet' and could implement things like games in games etc. Finally, these "ISP"s could expose their clients to real computer via the browser. I.e, an in-game CPU could implement a minimal HTTP web-server and then you could browse to it via your webbrowser.

The coolest thing about it all though? It brings back the days of hacking servers (except the servers being hacked wouldn't be real servers.) The days of buffer-overflows etc - I think that would be a big part of the game to.

As you get more connections to your server you would make more money - and then could purchase quicker adapters (to transfer more data to the "ISP") and purchase more expensive hardware (I.e, one with an MMU allowing for more complex operating systems.)

The market sounds very small for this game, but when noche released it - with such a simple 16 bit CPU _kids_ were learning to program these primitive applicaitons for this very primitive CPU.

I've acheived a rough implementation of dynamic lighting - this was really quite tricky in Java2D because you really don't have any access to pixel shaders or vertex-shaders which means you need to be quite crafy when implementing the lighting effect. I feel obligated to explain how I managed to do it since I feel that there is a serious lack of material out there for pure Java2D Isometric lighting algorithms.

The lighting effect is unpolished - i.e. there are still a few small things I need to do before it looks pretty but you can see it starting to shape up:

I did a lot of research since I posted this question - there are tons of alternatives and JavaFX does intend (on a later release) to include its own shader language for those interested. There is also a ofcourse LWJGL that will allow you to load your own shaders onto the GPU.

 

However, if you're stuck in Java2D (as I am) it is still possible to implement lighting in an isometric game it is just 'awkward' because you cannot perform the light shading on a per-pixel level.

 

How it Looks:

 

I have achieved a (highly unpolished - after some polishing I can assure you it will look great) effect for casting shadows, depth sorting the light map, and applying the lighting without experiencing a drop in frame-rate. Here is how it looks:

 

http://imgur.com/SkXB7ck

 

You'll see in this screen-shot a diffuse light (not shaded in but that step I'd say is relatively easy in contrast to the steps to get there) casting shadows - the areas behind the entities that obstructs the light's passage BUT also in the bounds of the light's maximum fall-out is shaded in as the ambient lighting but in reality this area is passed to the lights rendering routine to factor in the amount of obstruction that has occurred so that the light can apply a prettier gradient (or fading effect of some sort.)

 

The current implementation of the diffuse lighting is to just simply render obstructed regions the ambient colour and render non-obstructed regions the light's colour - obviously though you'd apply a fading effect as you got further from the light (that part of the implementation I haven't done yet - but as I said it is relatively easy.)

 

How I did it: I don't guarantee this is the most optimal method, but for those interested:

 

Essentially, this effect is achieved by using a lot of Java shape operations - the rendering of the light map is accelerated by using a VolatileImage.

 

When the light map is being generated, the render routine does the following:

 

1. Creates an Area object that contains a Rectangle that covers the entirety of the screen. This area will contain your ambient lighting.

2. It then iterates through the lights asking them what their light-casting Area would be if there were no obstructions in the way.

3. It takes this area object and searches the world for Actors\Tiles that are contained within that area that the light would be cast in.

4. For every tile that it finds that obstructs view in the light's casting area, it will calculate the difference in the light source's position and the obstruction's position (essentially creating a vector that points AT the obstruction from the light source - this is the direction you want to cast your shadow) This pointing vector (in world space) needs to be translated to screen space.

5. Once that has been done, a perpendicular to that vector is taken and normalized. This essentially gives you a line you can travel up or down on by multiplying it by any given length to travel the given direction in. This vector is perpendicular to the direction you want to cast your shadow over.

6. Almost done, you consturct a polygon that consists of four points. The first two points are at the the base of the screen coordinate of your obstruction's center point. To get the first point, you want to travel up your perpendicular vector (calculated in 5) a quantity of half your tile's height [ this is a relatively accurate approximation though I think this part of the algorithm is slightly incorrect - but it has no noticable decay on the visual effect] - then ofcourse add to that the obstructions origin. To get the second, you do the same but instead travel down.

7. The remainder of the two points are calculated exactly the same way - only these points need to be projected outward in the direction of your shadow's projection vector calculated in 4. - You can choose any large amount to project it outwards by - just as long as it reaches at least outside of you light's casting area (so if you just want to do it stupidly multiply your shadow projection vector by a factor of 10 and you should be safe)

8. From this polygon you just constructed, construct an area, and then invoke the "intersect" method with your light's area as the first argument - this will assure that your shadows area doesn't reach outside of the bounds of the area that your light casts over.

9. Subtract from your light's casting the shadow area you constructed above. At this point you now have two areas - the area where the light casts unobstructed, and the area the light casts over obstructed - if your Actors have a visibility obstruction factor that you used to determine that a particular actor was obstructing view - you also have the grade at which it obstructs the view that you can apply later when you are drawing in the light effect (this will allow you to chose between a darker\brighter shade depending on how much light is being obstructed

10. Subtract from your ambient light area you constructed in (1) both the light area, and the obstructed light area so you don't apply the ambient light to areas where the lighting effect will take over and render into

 

Now you need to merge your light map with your depth-buffered world's render routine

 

Now that you've rendered you're light map and it is contained inside of a volatile image, you need to throw it into your world's render routine and depth-sorting algorithm. Since the back-buffer and the light map are both volatileimages, rendering the light map over the world is relatively optimal.

 

You need to construct a polygon that is essentially a strip that contains what a vertical strip of your world tiles would be rendered into (look at my screen shot, you'll see an array of thin diagonal lines seperating these strips. These strips are what I am referring). You can than render parts of this light map strip by strip (render it over the strip after you've rendered the last tile in that strip since - obviously - the light map has to be applied over the map). You can use the same image-map just use that strip as a clip for Graphics - you will need to translate that strip polygon down per render of a strip.

Anyway, like I said I don't guarantee this is the most optimal way - but so far it is working fine for me.

I've added tons of features since I last posted here.

There is a video of me showing off the scripting engine (and accidently a bug I found - which I have since resolved):

If anyone is interested, I also maintain a much more frequently updated blog at java-gaming.org

http://www.java-gaming.org/index.php/topic,30313.msg279530.html

(You have to watch in 720p to read the script I am tryping into the engine via the command console):

http://www.youtube.com/watch?feature=player_embedded&v=pmf7vrsz0TY#at=21

Thanks.

I've done tons of C, C++ and C# .Net - if I were to port it to anything it would probably be C# .Net.

There is absolutely no reason for me to port it over to an unmanaged environment so I would never consider doing that.

That said, I am pretty confident with it as a Java application right now and I know porting it to any other managed laguage will be relativley easy.

JevaEngine - Undeground Demo

Info:
You can download the compiled JAR file below. This is purely to show off some feature in the engine via the command console, the game is nowhere near complete (this is a demo really.)

Feedback\Bug Reports are welcome.
Contains Course Language

Features:
Some of the latest features of the engine I can remember:
- Fully Scriptable, scriptable scenes, events & NPCs (Scripts are written in JavaScript - go figure)
- UI Is entirely skinnable and customizable - Jeva Core provides a solid infastructure for most general UI components.
- Basic particle engine (implemented primary for attack\heal\projectile effects so not too fancy, but can handle ~30000 particles on the very low-end machine I develop on)
-Entities can save states and reload states (essential for game saves). States are can be saved on an integrated back-end that works over GameJolt API for Achievements, Scoring and Cloud Saving
- Fully capable quest system & dialogue system (dialogue can be complex with various pathways which effect any internal variables of the character (i.e. moral))
- Most of the engine is entirely extensible - with logical partitions in implementation logic between Java and external scripts.
- Map Editor & Dialogue editor
- Dynamic lighting and scriptable weather subsystem
- powerful debugging console - very powerful user interface via scripts to engine. Both through the console and entity configuration files.

Download:
Executable Jar:
http://www.filedropper.com/jeu

Applet:
It can be downloaded as an executable JAR (See Above) OR run as an applet here:
http://gamejolt.com/games/rpg/jevaengine-project-d0/16225/

Please post comments\suggestions etc.

Known Issues:
  - Precaching has not yet been implemented, as such you might get random FPS drops as the game prepares resources.
  - Using the command console to invoke commands like load unvisited areas will cause the quests scripts to screw up etc.
  - Sometimes the quests don't trigger properly, this is an error with the quest scripts, not a big deal though.
  - Use of Area object is risky as I found a bug in the JDKs implementation of it, while I haven't encountered any issues with it since, symptoms will be a freeze for about 50 seconds and then a crash due to lack of heap memory.

Modding:
If you want to write a Mod etc, just add the .zip extension and snoop around res folder - there are tons of cool things you can do, even add your own NPCs etc.

Command Console:

How to use the command console:
http://pastebin.com/iciidRCv

I've started to implement the networking subsytem.

Planning the implementation will not be an easy task but I feel that by using Reflection and Annotations I can pull off a relativley nifty implementation that doesn't leave too much of a 'footprint' on the existing code in the engine.

It needs to be done very carefully so I do tend on spending a good two or three days planning out this implementation thoroughly before hacking into it. The networking Sub-System for the engine's core will, without a doubt, be one of the more challenging implementations I will have to do on this engine.

That said, so far, I am relativley impressed with the minimal amount of code-refactoring that has needed to come out of scaling the engine accross multiple larger functions, so I hope that the design of the engine as it stands will allow me to do this very easily.

Network Subsystem is nearly completed, I believe I will have some basic networking to show off soon.

It looks like server-side scripted entities are actually going to be quite easy to implement, and all features in the game (minus dialog which will require some tweaking since dialogs pause the server-side world state) will seamlessly be handled on the server-side and fed to the clients.

The network-subsystem took a bit of work, but with the current implementation I am hoping for minimum bandwidth consumption.

The networking is going to be implemented outside of the engine's core. This makes most sense to me since the actual model used for networking can be most optimally chosen outside of the core of the engine. I.e, if movement is strictly tile-based (as it is for the RPG Extension) then movement can be abstracted to a very low-bandwidth per-tile level. If it is more complex than that (i.e, not strictly tile based) then obviously it may require some more bandwidth intensive operations etc to portray velocity, acceleration location etc and a more complex client-side prediction.

The current networking model communicates to clients using snapshots broadcasted at a fixed frequency. Using snapshots allows data network data to be queued for a fixed frequency and then dispatched to the client (and vise-versa) This is an avantage as compression ratios are best with larger chunks of data and it avoids redudant data being dispatched over at a very high frequency (wasting bandwidth.)

Anyway, updates to follow.

Video of Server & Client Networking Demo (Watch in 720p)

http://www.youtube.com/watch?v=4aJhpaTUDro

Networking is fully operational:

Here is a demo of the game server and client. I am still polishing up a few things then I intend on creating a simple game out of it to do some server load testing. The server is on the left, the client on the right. This demo illustrates only one client - though the server is capable of managing many clients.

The Screen Recorder I use eats up CPU Cycles like a monster so I can't record with a decent frame-rate.

Load Times:

The load times for the spider sprite in particular is quite slow. This is due to the Spider's texture file being absurdly large and inefficeint. You will see the client Freeze and the server Freeze as the spider is loaded into the world for about 5s, usually the assets would go through a precache process to avoid the load times while in-game, but precaching is not an immdediate concearn and has thus been thrown on-to the 'do later' task-list.

The load times for worlds are slow, this is because the worlds are currently stored in a plain-text (sort of like XML but with less overhead) format. This means that with large worlds and many layers it takes a large amount of CPU time to parse them. Optimally (and in later stages of development) these worlds will be stored in a binary format. Once the map files have actually been parsed, my profiler informs me that the actual LOADING of the map using the intermediate data structures fromed via the parsing process is very quick.

Security from client-side tampering:

In theory (if I'm not missing any bugs here) it is impossible for the clients to alter the state explicitly of any server entity without first asking the server so the game should be safe from game tampering. Additionally I have employed data encryption and code obfuscation\optimizations to ecourage would-be hackers to give up. The worst someone could do is to throw the client out of sync with the server, but it would have no effect on other clients or the server.

Please post any feedback, it is appreciated.

What I am doing now:

- I will be resolving a very obscure and difficult to reproduce bug in the server
- Polishing & finalizing the server & networking code.
- Creating an actual multiplayer game out of the recent advancements in the engine to do some load-testing on the server.

I'm not sure where I am going to deploy the server... I can't deploy it on this piece of crap because it barely does two things at once and I need access to my IDE. I have another computer I could deploy it on but it isn't 'mine' per se.

JevaEngine now has a very solid networking implementation, that includes entities such as AreaTriggers and NPC Characters and various other basic entities (doors etc...)

The way it works is something like:
 - Every networked entity has a script associated with it. There is a client script (stored and executed on the client) and a server script (stored and executed on the server) Both work exactly the same as entity scripts did before (i.e, with single player.) Server scripts work on the entity for i.e movements etc. Client scripts do the same for strictly client-side tasks (like playing the 'die sound' when a character dies) While client scripts can technically alter states such as location, they will be resynced with the server when the next snapshot is recieved.

I am going to be releasing a basic game to demo this, the game works something like this (and will be published on game jolt) I will deploy the server on my computer which should be good for ~45-50 players with 175 complex entities (that is, entities with very active AI constantly mutating states that need to be shared accross clients):

1. Players spawn as soldiers on the map - except for the two top-ranking players of the previous map. Soliders play a sort of Rpg Perspective - they can loot for better weapons and level up per round (i.e, after the round is reset - their character is reset) If I can, for the first couple of releases, I want to avoid having to keep track of players beyond individual rounds etc because that requires a backend database implementation that detracts for the purpose of the first couple of releases requires more serious security considerations.

2. The first of the two top-ranking players will be the master of the World's spider hive. I.e, they play a sort of RTS perspective of the game and control the spider NPC army of the multiplayer game.

3. The second of the two top-ranking players will be the same except for Zombies

4. Spiders and Zombies work together to kill the soldiers and vise-versa. Trophies are earned for being a top-ranked player for a given period of time, killing x spiders etc.

Latest Networking Demonstration:

http://www.youtube.com/watch?v=v-52aKJ4Smo

JevaEngine - Underground Outbreak Online is a multiplayer game I have been working on while also advancing the multiplayer capabilities of the engine. I will be hosting the servers hopefully sometime tomorrow night for a solid day or two if anyone is interested in joining me and testing out some networking code.

Here are some early screen shots of multiplayer (sorry for the simplistic scenery, I was a little tired making this map...):

JevaEngine's first game, Outbreak (A simple multiplayer Zombie RPG) is almost ready.

Currently there are a few things being touched up. Here is some of the latest:

- Snagged a very tricky bug in the Jeva Communicator library that caused network entities overlap IDs in one another in a very inconspicuous way.

- Fixed a few problems found in the path finding algorithm that went largely unnoticed up until now.

- Enhanced the TextArea UI Component a bit.

- Added a chat-system to the Multiplayer RPG module.

- Windows 8 Builds seem to be having trouble with rendering JevaEngine at optimal framerates. This may be due to a misconfiguration of the machine I am working on and I do intend of traveling to School this weekend to try it out on a few machines and determine how sufficient the networking is.

- Movement Synchronization seems to be a little rough due to latency in server transmission - it is a simple fix and will likely be implemented after the initial release.

Thanks for staying interested!

After the inital release I am going to fine tune the engine, add some features on my to-do list that are implemented in the engine but entities don't have sufficient access to via scripts (lighting, particles, projectiles) and then potentially start looking for a team depending on how well the initial release does.

Thanks for the interest Ryan Dansie.

Unfortunately I have just discovered that the rendering performance issues seem to be occuring on the school computers - which all have the same on-board Intel graphics device. I have discovered that this is because Java uses OpenGl if possible and falls-back to DirectX only if it needs to. However, the Intel chipset I am testing on in particular I know to have incredibly poor performance with OpenGL, so I'll have to find some way to force Java2D to have a preference for DirectX.

As a Microsoft user, I have never been fond of OpenGL, it never works well on any of my computers... I think it is infamous for poor driver support unfortunately...

It should work find with AMD Graphics Devices though (I develop on a computer with an AMD graphics device which is why it went unnoticed for such a long period of time.)

So I didn't launch the server into complete disaster, I isolated the test with a few friends, here are some bugs I found & notes I made:

- Use a tile selection indicator to remove confusion
- Dialog to give intro\tutorial
- Targeting too recent of a JRE, most potential players lag behind
- Move chat dialog to top right
- Chat input not working sometimes?
- Server disassociates all players
- Client doesn't recover from disassociation
- Mouse drag != click, it should
- Remove deassignment in ServerCharacter! Just there to hack out a release.

So I'll be fixing those first before I go more public with the release.

Because I am now a student at school, and also because transistors suck and their a huge pain in the ass to study for and I wish they were never created, I have less time to work on this project unless it is over the weekends (where I binge code) I hope to have everything ready for this upcoming weekend.

Here is the online release:

http://www.java-gaming.org/topics/jevaengine-outbreak-online/30717/msg/2...

Don't count on the servers being up long. It won't take long for someone to do something to crash the server.

Thanks for the response Ryan. I have had a couple issues with deploying this application. I believe that error you experienced is due to a misunderstanding on my part regarding the Launchj4 configuration. I have update the download link with a solution, give that a try.

I have also removed some world entities since I started to notice poor networking performance.

I did some trials last week and noticed various problems. Some causing some server threads to crash (they were isolated to individual users.)

I also located some networking performance errors. In response to these issues, I have increased the frequency at which snapshots are dispatched from the server. Surprisingly, this had a small impact effect on output compression ratio (from 50% to 60%)

You can view the summary of the networking performance here:

https://docs.google.com/spreadsheet/ccc?key=0AslAio6c5EhhdG5RNWNNYVJUZm1...

In conclusion (if you find any errors in these calculations, please contact me) - note some values were 'toyed' with to give more realistic predictions:

Data Dispatched (per user)  

Total (Kb) 110.918 Time (s) 25.688
Average Compression Ratio (%) 63.6927951924051
Datarate(kb/s) 4.31789162254749    

Server:

Upload Rate (kb/s): 256
Max Users: 59.2881948827061

I am relaunching the client and server. Please notify me if you find any issues regarding networking performance (rubber-banding, player twitching, etc.) as I haven't had a chance to test these changes remotely.

Thanks.

Download:

http://gamejolt.com/games/rpg/jevaengine-underground-online/16225/

The following will be finished shortly:

 - Adding support for OGG media formats, which will reduce the distribution size significantly

- Adding interface to lighting & particle subsystem via scripts (allowing for things such as torches etc...)

- Writing a pre-loader for the applet distribution of the client.

I managed to recover my development platform. Faulty video drivers abruptly reset my computer, which was in the middle of some sort of file-system operation. This corrupted the NTFS file-system. This was pain-stakingly fixed by grabbing an external HDD and plugging it into my computer to run chkdsk via the functional OS on the other storage medium as my computer does not have a USB-HDD boot option and I have no spare CD ROMs.

In the mean-time, JevaEngine's underlying Communication library has been improved in such a way that it will reduce the difficulty of managing remote connections and thus help me not encouter bugs when I am using it. Specifically, it now supports object pairing graphs.

The Server is now able to run multiple instances (worlds) parallel to each-other. The server also partitions these instances well, if one goes down the remaining can (in theory) remain fully operational. Players can travel between these instances by walking over a scripted trigger that will transport them to another instance.

Instances are lazzily initialized (but can be pre-cached in server scripts.) They're also weakly referenced which means if they remain inactive for too long (and the server is in need of some memory) they will be shut-down and reinstantiated when needed.

Thanks for the interest.

This video illustrates the server's ability to run multiple instances (worlds) in game and to transfer entities between them.

http://www.youtube.com/watch?v=HYgz8NRXDzw

The interesting bit is near the end. Ignore the poorly written JavaScript codes, they are very quicky hacked up and rehacked and rehacked until they don't work anymore. They're not well written because they only last a couple of days until the engine has some changes that need to be reflected in the scripts.

Several bugs were also found and resolved in the way the engine deals with entities.

Any frame-rate issues are induced via Recorder.

Thanks for the interest.

Thanks Ryan.

Yeah, some computers are having some performance difficulty, I assume it is due to the way Java automatically configures the graphics environment for my application. Some devices run it very well others run it very poorly.

I'm pretty sure it has something to do with Java's preference for OpenGL on platforms where support for it is lacking, but it also sometimes opts out of hardware acceleration on some intel-chipsets arbitrarily, I will contact oracle about it maybe they can give me some advice.

I have done tons of optimizations on the networking since though.

Thanks @StumpyStrust

I've been playing around with the java2d flags and I'll post back which configuration I find works best.

I'm not sure forcing it to use OpenGL will help much, but I'll figure out shortly I suppose.

Thanks.

I've just finished networking quest synchronization and character dialogue, I am now at the stage where I am going to develop a bit of a foundation in terms of story for the game.

This is what I've written so far (I am not a good writer, so please keep that in mind when providing feed-back):

https://docs.google.com/document/d/12k79pHAkgA9wigJMbbGr1ueyzQ9M7e-5nQZ7-_mOhaw/edit?usp=sharing

Thanks.

I've resolved various bugs, discovered some new ones. Notably, I discovered a very sneaky thread synchronization dead-lock that occured.

I've also been polishing up the game (and code.) Here is the latest online play (the is running over a stressed server [video recordings really drop my fps for some reason]) so don't be surprised if you see a bit of rubber-banding in the video:

http://www.youtube.com/watch?v=rWA8bajpVXg&feature=youtu.be

I've imported several assets from PARPG and will try to be consistant with that style from now on (since it is more directed towards where I want to take the game.)

Here is a sample map (you can see it in the background.)

Servers are now online and will be for the next three hours (unless there is a serious bug brought to my attention)

You can download it from gamejolt here (place the preloader in a folder, since it will create a folder called 'data' where the game will be updated\installed into)

If you get any performance issues, try disabling D3D and enabling OpenGL.

Download:

http://gamejolt.com/games/rpg/jevaengine-underground-online/16225/

Ryan, if you have free time, I would appreciate it if you could try this:

 - start the preloader and let it update first and then close it.
 - Don't start thet game through it.
 - Open up command prompt and navigate your way to the folder which contains preloader.jar and the updated data folder
 - in command prompt, type:

java -cp data jevarpg.net.client.Main

Note jevarpg.net.client.Main and not javarpg.net.client.Main

If it says something about not being able to find java, replace java with the full path name of your java executable image (somewhere inside of your Java installation folder [probably something like this:] C:\Program Files\Java\jrex\bin\Java.exe in quotes)

Thanks.

Alright thanks Ryan. I am pretty sure I know what the cause of that is. Thanks.

This project has now been open sourced under the GPL V3 License:

https://github.com/JeremyWildsmith/JevaEngineSrc

@ryan.dansie:

That audio bug is a really easy fix, I just haven't gotten around to resolving it yet. I'll try to get something done about it tomorrow. I have committed an issue for you in the hitgub (*edit* that is by far the weirdest typo I have ever made so I am going to leave it. What I meant was github) project page.

If anyone is interested in contributing to the project (in terms of code, game concept or game story, quests etc...) you can contact me.

I am sorry that there is no JavaDoc at the momment, I intend on adding that in the near future.

The engine is pretty flexible at the momment. What I have up right now is strictly just for demonstration purposes. If your game concept idea is (for example) a multiplayer city tycoon game (the most opposite genre I can think of off the top of my head) I can develop an extention from the engine for it to do that very easily (granted, gameplay mechanics obviously need to be written.)

If you want to contribute to the programming of the open-sourced engine, I am more than happy to accept you as a contributor.

If you want to work with me on some comercial project (a commercial game etc) I am willing to do that as well. I am also willing to negotiate the project under a difference licenense if it conflicts with your interests.

Thanks.