Amber IDE - 2D/3D Java game editor

Amber IDE is an open-source Java project well underway, which when completed will open the door to Generation IV+ game development.

Amber features everything essential to creating your own game, the way you want: a built-in Ruby editor, and a map editor comprising of both a 2D and 3D mode.

An abbreviated list of features can be found below:

• 2D/3D map editing
• Infinite tilesets per map
• Infinite map height
• High quality sound in wave, aiff, ogg, and midi formats
• Ruby scripting
• Syntax highlighting in 17 languages

What follows below is technical rabble. If you are a brave soul, read on. If you prefer to see the engine yourself, ignore the following section.



This post is incomplete, as I can not link any media to it yet.

I shall augment this post with more in-depth info, images, and helpful external links once I reach the 15-post barrier. Until then, you may view images of the editor in action from the attachments section of this post. I apologize for the low colour depth of the images.

If you are experienced in either Java or Ruby (or both!) and would like to assist us in this venture, or would just like to chat, feel free to join us at #amberide on the esper.net IRC network.

This has caught my eye quite a bit. When I first spotted the thread I thought, oh, another Java engine that's going to be a complete bust and disappear after a few months, but when I read this thread, it got me a bit excited. I'm impressed by the fact you're implementing ruby into this. It gives a great potential for those who have been used to coding in RGSS the ability to move over to this engine without having to learn too much. From what I can see at the moment, you have a basic shell of the engine made which, is pretty impressive compared to most I've seen so far, but I can also see it's going to be a big work load. I'd try help out in anyway I can, although my time is fairly limited. I wish you the best with this project.

Thanks for the input. I was originally considering using Python via Jython as I have more experience with Python than Ruby, but decided against it when I discovered the performance issues of Jython. Partial RGSS compatibility is also a plus, of course, though the scripting design is closer to a directory-based program structure than the id-based RMXP event system. So though this allows for more flexibility, it might seem alien to those who are used to RMXP.

Since my original post, I have made some great improvements to the map format and editor. I was previously using an abomination of XML with CSV nodes to represent the map data. Needless to say, the maps were massive and bloated. Hence, I've switched to a compact binary format resembling the Java class file format. Tiles, audio, and models are stored in a header 'constant pool', with layer definitions following sequentially after.

Additionally (and perhaps more excitingly), I've added tile angles when in 3D-mode. Currently, you can place tiles at 180, 90, and 45-degree angles, allowing for mountains, bridges, and caves to have the same feel as the official Pokemon games.

There are two images depicting this in the spoiler below: the first of a cave segment, and the second of a portion of what could be a route map.



And now, for something even more exciting: the source code for Amber, and a working build! Please report any bugs to our ticket tracker at Github. There are plenty of bugs, and the faster we find them the faster a proper release of Amber can occur.

This looks fantastic! I should be able to help a little bit, but, a suggestion - Maybe have both Ruby and Java support? My "native" language is Java, and, as such, if this supported Java, that'd be awesome :D

Anglican said:

This looks fantastic! I should be able to help a little bit, but, a suggestion - Maybe have both Ruby and Java support? My "native" language is Java, and, as such, if this supported Java, that'd be awesome :D

Click to expand...

Indeed, not having support for Java would be a shame. That said, it would become a hassle to manage between both Java and Ruby scripts. Thankfully, JRuby allows interfacing between Java and Ruby code. So essentially, you could write your scripts in Java (building against ahead-of-time compiled Ruby scripts), and then use a simple wrapper script to bridge between the Ruby and Java portions. Essentially, since all Amber projects have a Ruby-script 'entry point':

By doing this one is not only limited to Ruby and Java: one could build against Jython to allow for Python scripts to be written.

Now, since a lot has transpired since my last update, I thought it would be about time for another.

I've reworked the map editor significantly to be more user-friendly, and have fixed a long-standing bug causing seemingly random crashes. I've also switched from using a natively-bound display to LWJGL's AWTGLCanvas. Though it took a bit of tinkering, rendering is up and running again. The main improvement is possibility to have multiple map windows open (the previous approach was restricted to just one).

I've also tentatively begun working on 3D-model support. So far I have a basic Wavefront OBJ model loader implemented, complete with material support. Looks (and works) quite nice. Models have been donned their own tab in the resources section of 3D-enabled map editor components. Each model has a 2D-representation drawn ontop of a button. Their tooltip text shows basic model info: name, number of vertices, faces, materials and so on. Finding models has proven a tad bit difficult, however. Regardless, I hope to have models rendering in-game in a few days.

Icyene said:

Indeed, not having support for Java would be a shame. That said, it would become a hassle to manage between both Java and Ruby scripts. Thankfully, JRuby allows interfacing between Java and Ruby code. So essentially, you could write your scripts in Java (building against ahead-of-time compiled Ruby scripts), and then use a simple wrapper script to bridge between the Ruby and Java portions. Essentially, since all Amber projects have a Ruby-script 'entry point':

Code:

def on_start()
   myJavaPackage.mySubPackage.MainClass.onStart
end

By doing this one is not only limited to Ruby and Java: one could build against Jython to allow for Python scripts to be written.

Click to expand...

So, would one run a Java method simply with package.subPackage.class.method(parameter1, etc)?

Still a bit confused though - when we're using Ruby code, are we able to initialise Java objects, and vice versa?

Anglican said:

So, would one run a Java method simply with package.subPackage.class.method(parameter1, etc)?

Still a bit confused though - when we're using Ruby code, are we able to initialise Java objects, and vice versa?

Click to expand...

Yes, that is correct. For example, if I wanted to create a new Java File instance, I'd do `java.io.File.new(".")`.

Now, for a progress report. Over the past while I've taken a general break from Amber to relax and spend more time not programming. However, the past weeks have not been entirely devoid of progress!

I've been collaborating with the__end, and with his insights I've been able to iron out a set of new features and improvements for Amber. Many things have changed, but overall I feel Amber is one step closer to a full release.

Most importantly, I've written a system to import models (in the Wavefront Object format) into 3D game maps. A preview of the model prior to being added to the map is shown via a wireframe rendering.

I've done some preliminary work with terrain flags. Rather than the per-tileset flag definitions, terrain flags are 'drawn' onto the map like the tiles themselves, complete with a flood-fill option. I'm considering adding a global flag definition area (per-tileset), but I am unsure how or where to implement this neatly. This system also allows only one permission per tile, so an alternate system might have to be designed, with fewer restrictions.

In the hope of eliminating the need for external applications to be created for Amber to be fluently used for creating games, I've created a simple plugin system. Supports both Java and Ruby plugins, hereby referred to as 'tools' – they are not plugins in full.

A tool can be placed anywhere in the project file tree and upon opening it (by clicking it), will open a new tab in the editor which contains a component created by the tool. Tools can opt for new windows instead of a tab to display their contents. The addition of tools allows game-specific content, like Pokemon world map image generators to be added without the need of external applications.


I've been told numerous times that my error handling in Amber was, to put it mildly, horrible, so I've redesigned the way error handling is done in Amber. The result is smaller, smoother, and more error-specific dialogs for each error.

In this attempt to remove all known bugs from Amber, some sacrifices had to be made. A group of features which simply were more trouble than they were worth were cut out. I've removed Amber's capabilities for fancy tab docking – FlexDock, the library which I was using for this is much too undocumented, leading to issues unfixable with my current knowledge.

I've also reverted my commit to add the option to rename resources after they are added. My reasoning for this is simple. User creates a map with a tileset named 'A'. Renames tileset 'A' to 'B'. The map still stores the tileset by reference. And since tileset 'A' no longer exists, it becomes corrupt with empty tiles. So instead of wasting valuable time with implementing a complex history system that may or may not work, I removed it. For the same reason, the option to change a tileset's image has also been removed.

Since tilesets are not the only type of resource – audio and models exist as well, this change affects them as well.

Wrapping up, in the next few days I'll be implementing a copy/paste/cut/move function. With any luck, during that time I'll think of a better way to handle terrain flags.

Icyene said:

I'm considering adding a global flag definition area (per-tileset), but I am unsure how or where to implement this neatly. This system also allows only one permission per tile, so an alternate system might have to be designed, with fewer restrictions.

Click to expand...

I thought a little about it and IMO, in RMXP, there are not many differences between terrain tags and events. The only difference is that the terrain tags are placed on the tilesets and the events on the maps. But because you changed that, you could also put terrain flags and events together and call it "event system" or "events" instead. You could add a button on the menu that opens a window where you can define and edit all the events (including terrain tags, which are basically events). The defined events should be global because there is no important reason why they should be tileset restricted. Of course there needs to be some predefined events for common occasions like text boxes and NPC. The flood-fill feature should be disabled for these kind of events. You should be able to change the input data (text for text boxes, moving range for NPC) on the map editor and there should be a small window with all the defined events. Predefined ones should be placed above the ones that the user defines. You could simply select the event you like from this window and "draw" it on the map. Afterwards you can simply edit the input data by "right-clicking" some events where it is possible. ;)

Obviously yes. This thread hasn't been posted in for nearly 2 years.