Skip to content
February 17, 2012 / sguergachi

Development Diary #14

Hey there! How are you doing in these fine times?

I’m doing ok, thanks for asking! Today I’m releasing a snapshot that may not seem like much on the surface but contains a lot of much backend reworking of the core and the engine. The major features of r_112 are the following:

  • Aurora Surface Implementation
  • aCarousel recoding

So let me start by explaining the Aurora surface implementation. I initially stumbled on the idea of allowing the ability to skin the entire application by discovering how to simply manage resources in Java using the class.getResources() method and passing it a simple URL to the elements in the packages I was working on, so everything was relative to the actual application. When I first started working on this application I put all the resources in with the Core code which made sense at the time since updating and accessing elements were really easy, but I realized that if I ever want to make small changes to the code I would have to recompile the whole project along with the several .png images into a compressed .jar archive. This was not very efficient to start off, and if I ever want to implement an updater to remotely change only the core code I would have to do some pretty tricky stuff not to have to make the user download the whole 30mb for a small patch. Finally the main reason I decided to finally take out the resources was to one day be able to easily and simply allow for a form of skinning where users could change the graphics in the separate .Jar file and then the next time they run Aurora they can immediately see their cool additions to the UI. A few months ago I took the time to separate the resources from the core into two separate files. This was a simple process but was not enough since the resource file was linked to the Core through the library which meant the getResources would point to the specific Resource file name and nothing else, attempting to change the name of the file or putting a new one in would cause problems as Aurora would not identify it on run-time. I decided to leave it for a while, and have since dubbed these resource files as “Surfaces” which clearly represent what they are, they lay on the surface of the Aurora app.

So in the past week I spent a few hours on and off working mostly at night to fully support the ability to have any file containing the string “_Surface” somewhere in the file name become the Surface of the app. This had to go through the Aurora Engine to therefore support Surfaces on any app that uses Aurora Engine. I created a new component called aResourceManager which works with the aFileManager to find Surface file and then set its internal variables to contain the path. Therefore each class in need of resources would have to create a resourceManager or use a previously created resource manager. This is on hindsight fairly inefficient, since currently the resource manager will look for the surface file every time you call the getSurface() method to return the URL to the location. Not only should a separate set up method be implemented but the fact that multiple resource managers need to be created thought the app is pretty stupid to me (even though I’m the one that made that stupid thing) I have however started thinking as a whole that the engine should have a single class to contain other objects like the resource manager which should be used thought an application and have to do most of the loading once, and the other needed ones on demand. It should also act as the ignition to the rest of the engine, check if the needed components of a generic Aurora Engine app exist ect. That is why I will start working on a new component called aEngine, which will do just that. I will hopefully be able to talk more on this later when I have actually done it.

Anyways, onto the next feature. The aCarousel has finally received  the necessary recoding to work better, allow for more panels, more modular ect. You will see thanks to Carlos’s work that we can add as many panels to our carousels as we want, which would mean anyone can create code that implements AuroraApp and be able to act as a menu item in the carousel. This is exciting because It will allow the possibility of even more flexibility in the future where we will be able to allow separate “APPS” to work inside the Aurora Game Manager platform so to speak. Next we have faster transitions, which was really necessary as it represented a slicker and snappier UI. Finally Carlos went on to add a bonus ability to allow Movement along the carousel using the scroll wheel, which makes the carousel feel much more like a real professionally made carousel.

I have unfortunately not been able to work on the Search selection bug and the Loading bug due to my lack of time. However I will be on break next week, and guess what I will be doing? That’s right, a whole lotta coding. Hopefully I will have learned and implemented the database by the end of the week.

But that’s it for now! Catch you later!

-Sammy Guergachi


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: