Since the middle of jan I’ve been working on this engine in what spare time I have while working a full time job.
What is attemptX:
AttemptX is another attempt at a game engine after I lost count of previous attempts… Currently this is only an offline engine developed in java 1.8 ( you may need to install or update java to run this) that mimics graal development interpreting gani and nw file formats. The client itself is built using libGDX for rendering, audio and input and luaJ for script interpretation. I have developed a server alongside this client however I fear it’s inability to conserve bandwidth so I’ve omitted it from this demo.
Steps to use:
Out of fear that unixmad would somehow try sue me if I were to distribute graal assets as part of my own client, such assets have been omitted and therefore it’s assumed that anyone running this demo has access to the standard asset suite as supplied with the graal reborn package distribution. [LIST=1]
[]Extract the supplied ZIP to a directory of your choosing
[]Run cache-fill.jar and point it at your graal reborn root folder ( this program will read through all relevant files and place their paths in a filecachemanager text file which you will find in the same directory as you ran the JAR.
[]Run the cache-fill.jar again and this time point it at the test-assets folder supplied in the attached zip.
[]Run client.jar
[/LIST] You should now be able to walk around, swing your sword and observe the client interpreting the lua scripts supplied in both the level and external files. I would’ve made something more complete but I felt the process was dragging on far too long hence why I chose this point in development to demo the client.
To build your own scripts, just take a look at what I’ve scripted and you should be able to work it out but if you have any questions, feel free to post them. Eventually I will release a document describing each of the functions or I may just append them to this post…
Note, I have only confirmed that this works on a windows OS. It’s likely that seperate builds are required for linux and mac based operation systems due to how libGDX works.
Would’ve thought there’s enough information on the internet for popular graphics libraries? Let me know how that goes though. libGDX has some pretty powerful features in terms of openGL rendering.
Java is my go to language for anything I’m unclear about how I’ll develop. I find it a great language to build prototypes in a relatively quick and effortless manner. Not only that, but it’s pretty good in execution speed. Is there a problem?
The only problem I have with it is that it requires JRE to be installed so it’s less friendly to the average user. I wouldn’t have chosen Java for that reason but whatever, you know better than I do.
I thought it would be common for people to have the JRE installed, plus it’s not even a huge download.
Yeah, I thought the same thing on the outset looking in on other people’s examples. Syntactically, it’s a pretty simple language though and you can do lots of cool things. You may notice I’ve tried to ease the burden on developers by supplying a variable called ‘this’ that points at the npc you’re writing the script in, and that variable can be passed around to other npcs which can then invoke functions against it. Development is made even easier with the ability to import scripts that provide generic functions, as time goes on I’ll build on these and make them available to anyone to interested.
Additionaly, being quite the established language, there’s lots of examples on the internet only a google search away.
We had an issue on FTO with people having multiple versions of java installed, no JRE installed, windows defender warnings (required constant white listing) And so Benoit ended up packing the JRE with the client/launcher and solved all those issues.
I look forward to seeing more progress on this and let me know if you need anything in terms of graphics or levels and I will try get it done.
I was just wondering why you didn’t use Tiled instead of Graals level format?
Packaging the required JRE doesn’t sound like such a bad idea. I think i’d rather write some code that searches common installation directories of java and checks if the machine has the required version, pointing them to the JRE download if they don’t.
There’s no reason I couldn’t parse the tiled level format, it’s just rather generic and inspecific (there’s a lot of things you’d never use) and I felt providing a graal format parser was the better option for the initial phase in terms of letting people play with the engine. I’ve actually started writing my own editor which will house a few more features compared to the graal editor hopefully providing for a smoother development experience as well.
As far as assets are concerned, they’re not a priority at the moment however as my list of features to implement draws to a close it would be nice to create a demo package showcasing the power of the engine in a visually aesthetic light, that however, is still quite a while off given I only work on this project mainly during weekends.
Currently working on a level editor which will closely mimic the graal editor’s behaviour and add a few new features such as layer support. I’d like to thank chicken for the sexy icons
Are there any features you guys would like to see that you feel the current graal editor is lacking?
Note as of currently I have implemented the following non-standard features:
-smarter painting : while dragging a tile selection across a level, the editor will apply modular division to ensure the tiles lain don’t overlap
-proper undoing: the level’s state is properly saved after a modification event and can be reverted back to its original state(up to 100 moves)
make it so you dont have to hit a stupid ‘play’ button. i should be able to be able to move the character around inside the editor as if im playing the level.
WSAD camera movement is a 100% must. If you haven’t had it before in a map editor, you have been missing out XD also within the tileset to move around. Using Tab focus to swap between what you’re moving through.
Would be nice if the tileset was dockable / detachable
I made a list of features on my OP about Evora’s tile editor. Most of it is basic and you’re probably taking care of it already but I did have
Zoom in/out for when you are editing levels that are part of a bigger map
Switching between the components. So, you could have WSAD movement within the tileset selector for ease of movement/finding tiles and then you have WSAD movement within the level / main camera movement. With perhaps a Tab/focus select shortcut key. Not necessarily Tab (could be reserved for swapping layer groups or something to that effect Tab, Shift + Tab)
Seems like a lot of work for what seems to be not a lot of gain. The thing about the play button is it’s a nice deterministic start to any behaviour you might want to observe.
I agree. You don’t want to have something like the level creator scripting an infinite loop and crashing the client as they’re editing the level. You want to crash it in a separate process and hopefully retain valuable information from that crash.
Besides that creates one of two really bad issues, which is either:
You lose all your progress editing the level since your last save because the level editor crashed due to writing something like an infinite loop, or a number of other bugs which could potentially crash the client.
It DOES autosave a backup of your work during the crash but then how are you supposed to open the backup with the most recent save in the level editor without crashing the client each time or severe lag?
These are the kinds of severe issues you could face runtime editing a level unless the level creator knows exactly what they’re doing.
