Hey, I just wanted to show off a game I am making with an isometric game engine I am working on in Java - primarily deployable as an applet. All graphics assets are credits to OpenGameArt.

The engine consists of a Map Editor, Dialogue Editor, the Core engine and the RPG Engine extension as of now. It implements JavaScript as the scripting engine for NPCs\entities and is easily extensible into an RTS or RPG.

Some of the latest features of the engine I can remember:- Fully Scriptable, scriptable scenes, events & NPCs (Scripts are written in JavaScript - go figure)- Centralized Server Networking Implementation for Online RPG Games. Entity scripts, world triggers etc work seamlessly off and on server.- 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.

You can just ask me if you have any questions - I just put the log there because I thought it might be interesting to some.

I had some spare time, lol

But you might want a short summary of what you're actually talking about to avoid tl;dr responses.

Yeah, you have a good point. It is an exhaustive read that is neither well summarized or presented alone. I am finalizing a few features right now - when I get that done I'll upload some solid gameplay footage for it & better improve the description. Until then, it's all night ahead with a solid cup of Java (Coffee)

What do you mean, tiled?I don't like the swearing in the game, delete it

I pressed Ctrl + F and searched for the text 'tiled' in my post, and I can't find it. I don't know where you got it from.

I am not going to delete cursing in a video game of which I administrate on your account - if it is offensive to forum users here and is a violation of forum guide-lines I will sensor it from the forum (actually, I'll probably remove such material all together since it isn't worth my time.)

Haha you dont know what 'tiled' is? You have got a lot to learn bud...Ok, cursing in a game = bad game for me, so I will dodge this topic from now on...

I normally don't respond to trolls, but I feel like my point about cursing is a general point worth making.

It isn't that I don't know what tiled means, it is that you asked:"What do you mean, tiled?"

I interpreted that as, "What do you mean when you say it is tiled."

To which I responded "I didn't say that it was tiled."

We can argue interpretations here, but the fact is that you haven't constructed a proper context for that sentence and that obscures its meaning.

Cursing allows one to develop character and express emotion in that character. Now, I'll admit that I am not a great writer (I am a programmer not a writer) - but before you argue cursing in writing with me, please take it up with Stephen King first, than maybe we can talk about it.

This game is dark in nature, so before you get offended by the cursing you may want to take a second and look at the big picture.

Haha you dont know what 'tiled' is? You have got a lot to learn bud...Ok, cursing in a game = bad game for me, so I will dodge this topic from now on...

Unacceptable attitude, seriously. You're going to go to someone's else's WIP topic and just order them to removing cursing from the game? And then you chastise them for not knowing something on a forum that's supposed to be for learning? I don't want you on this forum.

Apologies @Jeremy - most people here are not as arrogant or rude as Herjan. If you have a question, most will answer it helpfully.

Haha you dont know what 'tiled' is? You have got a lot to learn bud...Ok, cursing in a game = bad game for me, so I will dodge this topic from now on...

Unacceptable attitude, seriously. You're going to go to someone's else's WIP topic and just order them to removing cursing from the game? And then you chastise them for not knowing something on a forum that's supposed to be for learning? I don't want you on this forum.

Apologies @Jeremy - most people here are not as arrogant or rude as Herjan. If you have a question, most will answer it helpfully.

+1 to Jimmt.

I loved the scenario, seems really fun!I would just would say to you implement a flame thrower and hm, make it bigger so the black borders dont show up ( i guess that goes without saying ,sorry )

Haha you dont know what 'tiled' is? You have got a lot to learn bud...Ok, cursing in a game = bad game for me, so I will dodge this topic from now on...

Unacceptable attitude, seriously. You're going to go to someone's else's WIP topic and just order them to removing cursing from the game? And then you chastise them for not knowing something on a forum that's supposed to be for learning? I don't want you on this forum.

Apologies @Jeremy - most people here are not as arrogant or rude as Herjan. If you have a question, most will answer it helpfully.

It's alright, I know that generally this is a great forum. I've been lurking for a while lol.

Thanks for the reassurance though.

@Andre Lopes Thanks for the feedback. When I created that map I hadn't yet done the optimizations required to render larger maps (I haven't started optimizations till yesterday). With the latest optimizations I can render much larger maps so the boarders aren't a problem anymore.

Entities can now have their states stored and recovered via scripts. This is particularly useful for the player, where there inventory has to be saved\recovered inbetween loading worlds.

Since the filesystem implemented assumes read-only access to resources, states are loaded via a particular component of the filesystem and general resources like sprite sheets through the other. This partition is intuitive as it allows one to implement state management systems that work with a cloud or server. This will be useful for when I want to store game save states onto the GameJolt cloud.

I didn't have the time to develop a larger map to show off optimizations, here is the latest play through of the game.BEWARE Strong language - and poor writing - ahead.

- 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:

I've implemented some cool new features (mainly dynamic lighting - you don't see it until the end because there are a few bugs I am working out of it) I also improved the combat system a bit (you'll see me use two different weapons - both of which are scripted)

Course Language & Animated Blood in the below video (the blood particles on the main menu was just some testing with the particle engine - I do intend on removing it)

You're right this thread is a complete mess. Lol. I'll work on cleaning it up.

It is using Java2D - I'm going to try and stay at Java2D unless I really hit a brick wall in terms of performance (I've had to jump through a few hoops, do some trials to determine the quickest route to get something done in Java2D but its worked out so far.) Especially since the machine I develop on is really low-end.

Applets are dead - but I think Java is killing them with all those bloody "Your computer will explode if you press okay - DONT PRESS OK" warning messages that pop up. I'm still thinking about how I'll deploy the game - but I think I'm going to give applets a try.

Applets are dead - but I think Java is killing them with all those bloody "Your computer will explode if you press okay - DONT PRESS OK" warning messages that pop up. I'm still thinking about how I'll deploy the game - but I think I'm going to give applets a try.

IMHO applets are really a waste of time and effort. The amount of potential players gets reduced to a fraction near zero.Nobody will install Java just to play another Indie game.

Applets are dead - but I think Java is killing them with all those bloody "Your computer will explode if you press okay - DONT PRESS OK" warning messages that pop up. I'm still thinking about how I'll deploy the game - but I think I'm going to give applets a try.

IMHO applets are really a waste of time and effort. The amount of potential players gets reduced to a fraction near zero.Nobody will install Java just to play another Indie game.

The JRE is a requirement either way.

There really aren't any special requirements to get a java application to run as an Applet (aside from the obvious tendency to avoid the need for elevated permissions etc) so I'm not too afraid to target an Applet and then swapping to a different method of deployment. Keeping dependencies short wherever possible.

Shipping as a desktop application allows to silently use a bundled JRE, Android has its Dalvik machine.But having to install a public JRE is a major drawback, giving Java's reputation and not speaking of the latest security problems.But anyway, first there needs to be a game, so happy developing

Hmm, I've decided I'm going to put-aside the current lighting implementation and portentially implement an algorithim I found on gamedev.net which is likely more appropriate for isometric engine - "Razorblade's Isometric Dynamic Lighting Algorithm"

Essentially tiles & actors have a normal map packed with their RGB colour data. I'm pretty sure that if I stick to VolatileImage & only update the lighting on these tiles when they are in the fall-out range of the dynamic light sources are when one of the surrounding light sources have been put into a 'dirty' state I should be able to pull off decent performance.

Warning: VolatileImages are glitchy. Basically, drivers don't work well with them and the performance is gone when adding in transparency on windows. They are fine as long as you use them as backbuffers only and even then avoid them.

Tips on performance in java2D: Keep draw calls down. g.draw stuff. So particles will probably be a bottle neck unless you are doing some crazy stuff with writing to BufferImages.

Warning: VolatileImages are glitchy. Basically, drivers don't work well with them and the performance is gone when adding in transparency on windows. They are fine as long as you use them as backbuffers only and even then avoid them.

Tips on performance in java2D: Keep draw calls down. g.draw stuff. So particles will probably be a bottle neck unless you are doing some crazy stuff with writing to BufferImages.

For particles I can usually get good amount rendered on screen at a decent frame-rate (and considering the machine I am developing on is very old, I'd consider that acceptable.) That said, that number is relatively variable and has been higher - I haven't isolated it and run it through a profiler really so it's performance is anyone guess - but it has been working fine for me and I don't really ever intend on having more particles than that on screen.

I'm not sure how well VolatileImages works for dynamic lighting - but I have experienced a very large performance boost by using them in areas where my image buffers experience frequent change (which is why I figured I should use them for my light-map). What do you mean by glitchy? I know that the VolatileImages can have their contents discard and be displaced in memory - but if that happens(and you check to determine the contents have been lost) you can revalidate it (it will try and allocate an accelerated surface - if it can't, it would instead allocated one in system memory - which can't be any worse than using a bufferedimage.)

You will get bizarre results when trying to render with it. Flickering, jacked up colors, anything really. Setting the opengl flag fixes most of the issues but makes them impossibly slow on windows. I have not done much testing on other OS but it seems that the way to go for VI is to use them only as backbuffers. If you look at a topic I made today, I posted some real time lighting stuff. It is not isometric but it is very very fast. I use a VI as a backbuffer and draw onto it which is what you said you will be doing, so that is great.

What are your "old" system specs? I get 10-15k particles at solid 60 fps with other crap going on. That is about where you want things at. Above 20k draw calls and you will bring most systems down below 60 fps. Key thing is to avoid draw calls when ever possible. Use sprite sheets for particle effects if at all possible as you can go from 200 particles for one effect to 20using animated particles. Fillrate will rarely be an issue. In openGL land, fillrate is the first bottle neck in 2D games.

You will get bizarre results when trying to render with it. Flickering, jacked up colors, anything really. Setting the opengl flag fixes most of the issues but makes them impossibly slow on windows. I have not done much testing on other OS but it seems that the way to go for VI is to use them only as backbuffers. If you look at a topic I made today, I posted some real time lighting stuff. It is not isometric but it is very very fast. I use a VI as a backbuffer and draw onto it which is what you said you will be doing, so that is great.

What are your "old" system specs? I get 10-15k particles at solid 60 fps with other crap going on. That is about where you want things at. Above 20k draw calls and you will bring most systems down below 60 fps. Key thing is to avoid draw calls when ever possible. Use sprite sheets for particle effects if at all possible as you can go from 200 particles for one effect to 20using animated particles. Fillrate will rarely be an issue. In openGL land, fillrate is the first bottle neck in 2D games.

I would love to see how you come about your lighting in java2D.

Yeah, I've seen your topic on lighting and it looks very impressive. I will definitely be looking at it for some hints later if this algorithm doesn't work out - I'm still trying to figure the best way of doing that algorithm I mentioned above.

The particle engine uses sprite-sheets (but I haven't bothered to do any animations for them) I do tend to keep the particle count lower and just have several particles per sprite.

What the hell? I thought I posted a video here - I suppose it has just been floating around the internet, anyway (its about a day old - since then I did some profiling and improved a lot of performance in the core system)

*Update on Lighting*I figure I am going to stick with my old lighting system for two reasons: - The amount of data that would need to be encoded with my current assets would be A LOT of work to produce. Maybe when I acquire a larger team this would be feasible - but until then I need to move on. - Pixel shading is generally a very poorly performing operation in pure java-2d, while I did come across a few promising algorithms, see (1) for why I am still hesitant to implement them.

With that said, there are a lot of things I can still do with the old lighting system, I'll see how that works out.

Sorry for the frequent double posting - but I am assuming thats allowed in the WIP project as it is a developer log of sorts?

Anyway, I've definitely figured out this dynamic lighting mess. Thankfully, I already had a sort of 'hidden' lighting feature already implemented in my engine that was used for AI purposes. Each tile\actor was associated a (blended) visibility obstruction value that ranged between 1.0 & 0.0 - I can use this range to determine how much light to pass through entities.

The lighting algorithm works much like you saw in previous posts however I have managed to have it cast shadows (the method I use allows for all sorts of lights by implementing an ILightSource interface - I've only written a diffuse but ofcourse the other implementations like directional light is possible.)

The next challenge will be throwing the generated light map into the maps depth buffer - this shouldn't be too great of a challenge (and there are a few shortcuts I can take to doing this) - finally then the lighting code will be finished. I'll post some shots when I get it completed.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org