Hello everyone,
This will be my last post on this blog, we have been working hard for the past few months on the next big release of Aurora, and I’m happy to announce that the new release also comes with a brand new website along with a nice new blog, meaning I will continue updates there from now on.
The now re-named Aurora Game Hub, Alpha 5 along with the website can be found here:
and you can find the new blog here:
Hope to see you all there!
Hello everyone, long time no see 🙂
We’ve been hard at work on the latest version of Aurora which has been released today.
Alpha 3 contains 2 major features and a bunch of small little changes. Today I’ll be talking mostly about the major features as well as what we have planed next.
The first major feature that some of you may notice right away is better UI scaling. This has long been a problem with Aurora due to the nature of the custom UI we have implemented I blame my self for not implementing a robust resalable UI from the beginning, and that has hurt us in some ways.
The UI in Aurora in the beginning has mostly been fixed, hardcoded values for each element, as time went by I made an effort to make the UI work better for smaller screens, especially laptops by having Aurora check your screen size and if it was below a certain size it would use a separate set of fixed variables optimized for a laptop I have at home. The problem however as you can imagine still stuck, mostly for screens with wider aspect ratios and screens of even smaller size to the 17” laptop I have here at home. I have never had the opportunity to actually learn or understand how using relative values to proportionally rescale the UI actually works.
In this release I’ve made another effort to improve UI scaling by using values relative to the screen size and tested each change on 4 separate resolutions. As you can imagine this took quite some time, and honestly I’m still not super happy with the result. This was done entirely with trial and error and in some cases some UI elements may look weird. In addition I did not spend any time with the UI of the Profile or the Settings since we plan on revamping it completely.
The next major feature we are introducing in this release isBetter Navigation in the Game Library. This feature is something we believe is really necessary for PC Gamers and Carlos has been working on it for a while making sure it works perfectly. Implementing a proper Keyboard and Mouse navigation feature is very important to us. We think we have made some pretty interesting advances in this area some of you may really like that I don’t think I’ve seen done in any application really.
First of all we allow you to navigate the Game Library in 3 separate ways.
The first way is with the trusty Mouse: You can of course use the mouse and interact with the UI as you would normally by selecting games and moving right by simply Hovering over the right and left green arrows in the library. We have however, added the ability to scroll in between grids using your scroll wheel which makes navigating through a long list of games pretty easy.
The second way is using the Keyboard via Arrow Keys: You can, as soon as the Library is loaded press the arrow key Left or Down and the upper left game will be selected. From there you can keep navigating as you will. They way we’ve set up navigation via Keyboard is you have to reach the lower right game and move right to go to the next grid. Its pretty simple and holding down any arrow key will move the cursor towards that direction indefinitely, so you don’t have to keep pressing every time you want to move if you don’t want to . its pretty slick, fast and does what you expect it to do.
The third way is also using the Keyboard however you can navigate using the WASD keys. This is an idea I suggested to Carlos as a nice way to bring PC gaming aspects to Aurora. Basically WASD works just like the arrow keys. However because of the Mouse Scroll Wheel navigation we’ve implemented you can navigate our Game Library as if you where Playing an FPS game. One had on the mouse, and another on the WASD keys and you have found the best way to navigate the Aurora Game Library. You just scroll to the grid you want and then select the game you want to Play by pressing the ENTER key. Simple.
Now, you may notice that WASD does not activate the instant search, but other keys do. This was done on purpose, in the final version you will be able to select the WASD feature from the Settings page and it will probably be off by default.
Other then these two features, I’ve made some small improvements to Aurora Mini(mize), added 50 more games to the CoverDB and some other small internal things.
Now, lets talk about the future. In the past few month both me and Carlos have been away from Aurora for sometime, enough time for us not to remember where everything is in the codebase. And considering we don’t practice very good hygiene in our code, it hasn’t been easy getting back into it and make these changes. As new developers we are continuously learning, and having a clean codebase is one of these lessons we are painfully learning our selves. There is a lack of both structure as well as inherent commenting and flow to our code. I want to fix this before we make anymore advances.
Project Clean Up. We are about to embark in a mission to clean up the code, revisit everything, comment everything. We are also moving to GitHub a bigger Open Source community which should help motivate us to keep pushing. This also means we will move to Git version control system, which I’ve been told is way better then SVN which has admittedly been causing us a lot of problems internally with regards to conflict handling ect. We also have many improvements to the Aurora Engine that I have personally been working on separately. It will take some time to merge the current Aurora engine with the new and improved one.
This will take sometime, and wont be much fun for us. But I think its desperately needed. It will improve the overall quality of Aurora, it will help us release more stuff faster ect.
I hope you are all as excited as I am!
See you soon,
-Sammy
Hello everyone,
I just wanted to let people know that I will be taking the summer of from developing Aurora due to me finding a full time dev job which makes my schedule to hectic for me to work on. There is however an update in the works.
After the release of Aurora alpha we immediately started working on a follow up release containing some features we didn’t get time to do in the alpha release. Two main features are to be expected for Alpha 2 release coming this summer. The first is a better implementation of something called Aurora mini, which is basically a simple mechanism that allows users and the application to interact with the desktop environment (currently done by me and is in our repository). The second feature is full mouse and keyboard library navigation being worked on by Carlos.
There will also be some small additional features, including the fact we are finally compressing our assets which is going to cut the application pay load by almost half, and hopefully provide some performance increase. But as soon as Carlos finishes the awesomely slick library navigation feature, I’ll take some time to release it as part of Alpha 2.
See you all later!
Wow, its been quite some time since the last Dev Diary!
Well, I finally have the exciting news I’ve been wanting to let everyone know for sometime now:
Alpha Release!
Carlos and I have been working on this since the last release. Even through University I’ve been able to make considerable progress. Basically, Alpha has a functioning Library, that actually does something that may be considered useful. Here are the major features now in Alpha:
- You can add games to the Library using the new Add Game UI
- You can run games from the Library
- You can remove games from the library, and never by accident
- The Library saves your games to a local database
- The Library saves the favorite state of your games
Those are the major features added, but that comes with a butt load of bug fixes and some other small changes. I’m going to go into a bit of detail as to how each of these Major features actually work:
Add games to the Library using the new Add Game UI
Well, this has been a long time coming. Being able to add a game to a library with multiple grids in run time, from a database, all to be beautifully displayed is hard work, especially since this was all done from scratch. From the very beginning the rendering of the library was designed to allow for infinite games to be added and removed easily.
It started with the GridManager a component in the core of Aurora which manages all of the aGridPanels which is an engine component designed to contain components in a grid fashion with some added built in management capabilities such as an ArrayList that contains a copy or a list of all the items currently in the grid, this allows for easy manipulation and acquisition of items in these grids. the GridManager has to fill up each grid with the game Object represented in the library in the form of beautiful box art icons and create new grids when appropriate, check for duplicates and finish by adding placeholder images in the empty slots of unfilled girds. The GameCover is one of the Major components in the Core of Aurora, it contains every detail about a specific game, it also contains the UI dealing with the manipulation of the game in the Library. It deals with getting the actual Box Art from our sourceforge web servers, or locally if available. All this came together in the Aurora_GameLibrary class where the transition between grids and handling of major UI is put together.
That stuff had to be built before we were able to add individual games. When that got put together I started working on the interface that would allow for easy in app adding of games. I had a nice simple slide down box done in the previous release, that turned into what it is now. The AddGameUI allows you to add a game to your library in two steps. The first step is simply the name of the game you want to add, typing it in the very visible textbox allows you to see a predictive search of the game you want represented by the Box Art. The list directly to the left of the box art shows up to 10 other games that contain in there name what you typed in, selecting them shows the BoxArt for you to make sure that’s the correct game. The second step is locating the game on your system using the file browser. On Windows the Filebrowser isn’t very good since it uses the Java stock file browser with slight color changes to fit in, otherwise its not the easiest way to navigate your system, and I hope I can fix this in the Beta release. Otherwise the file browser lets you select executable and shortcuts and associate them with the game you want to add. Each steps light up red when they are not done or done incorrectly and light up green if they are both completed. When both steps are green a big green button pops down allowing you to add the game to the library. The AddGameUI pops back up and the game is added to the library. If the first grid is full then the grid automatically moves to the right until you get to the grid containing your newly added game. That’s basically how adding games to Aurora works.
Run games from the Library
Running games from the library uses the new AuroraLauncher which executes the associated file attached to the game object . It displays an overlay covering the whole screen notifying the user that their game is about to launch, when the executable terminates the user is welcomed with the black overlay again and are told how much time they spent on that game then returned to the library. Executing files using Java was tricky at first since we executed things through the command prompt (or terminal) and this caused a bug where the game would not be executed from the context of that directory, so if the game needed any files in and around that directory, it would fail since we were executing from the home directory. Turns out the ProcessBuilder in java makes things really simple. We did end up using the command prompt to run shortcuts on windows since that was the best way to do it with the ability to track when the executable executed by the shortcut was terminated. Overall the launcher is pretty good, we plan on adding tracking information to it later when we finish the actual tracker.
Remove games from the library, and never by accident
Removing games from the library was one of the trickier parts of this release. Many bugs could (and still may) ensue because of the remove game feature. Removing a game from the library we had to deal with all the many possibilities involved with it removing a game. When we wanted to have the remove game feature implemented we made sure that it was done live and instantly as users would expect, when you remove a game the library should reformat to keep the flow of games continuing along the library with no random empty spots, make sure placeholders where re-added appropriately etc. We had to deal with the fact that removing games from a single grid would affect every grid before it. We also had to make sure people would not accidentally remove a game. So I worked on the UI part of removing games and Carlos was able to work the actual logistics and made the adjustments to the GridManager to be able to handle this as we envisioned it. Right now I think it works pretty well, we haven’t had time to stress test it, but hey its Alpha we expect many bugs and bad things to happen!
Library saves your games to a local database
Saving your library is an obvious feature that I managed to implement in a matter of days using a system I thought up called Stores. The idea was to have a “Store” that contained array lists filled with library content, the store would be an in memory database essentially. On launch the store would be filled with library related data from the local database, when a game is added to the game it is saved in the store and transferred to the database directly so that in case of a sudden crash all previously added games have already been added to the database. There is a separate store for the Library, Settings and the Profile each extend the aStore interface in the engine. It works pretty well, there are some database read and write optimizations that I need to do, but for now the H2 Database engine is speedy and works well with Aurora through the aSimpleDB component in the engine which allows for quick and simple access to a database, without even having to know SQL (for basic operations).
Library saves the favorite state of your games
Saving states of whether a game is favorited or not is similar to saving a game as it also goes through the Store, however it required that we updated currently existing records and not add new ones. So new methods were implemented to instantly record whether a game is favorited or not in the library Store. I also changed the adding to library process when Aurora launches to organize the favorite games to be added first and the rest afterwards. I do want to be able to have games instantly reorganize when you favorite a game to be among the first games, but that will have to come later.
Well those are the major new features, and the only ones that really matter right now, there are known bugs with some of these features and some that have been around for ever (UI scaling) and we are working on fixing them ASAP, so expect more frequent releases again.
Also I should mention if you haven’t yet please go to our website and subscribe to get updates when new features come out: auroragm.sourceforge.net
Other than that I hope you get to enjoy Aurora Alpha release, its been in the works for the past 3 months through our free time and we are pretty happy with what we’ve been able to achieve. Please e-mail me if you have any feedback, bugs or just leave a comment!
Hey everyone!
I just wanted to let you guys know we’re still here and we are working hard to get an exciting release of Aurora to you guys. Unfortunately exams has taken a lot of my time, but we have managed to get major progress done! the Alpha release of the Aurora Game Manager with the core features of the library all done including
-Searching through our huge Box Art library to find games to add
-Add games to your library by attaching a game icon to an executable on your computer
-Removing Games
-Playing Games with a cool game Launcher
and more little changes!
Right now Carlos is busy finishing the Remove Game feature and I will be done with exams next week so I fully expect Alpha to be out before the end of April
also, I managed to put out a cool little “coming soon page” sign up to get notifications on all the cool news directly to your inbox
http://auroragm.sourceforge.net/
That’s it for now!
Hello Internet!
So I’m writing this post pretty late, and I should be going to sleep right now for school tomorrow morning, but Carlos just committed a fix for the Carousel recoding we did which resolves the problem where the large screen causes the Carousel to act weirdly, and I was to excited to go to sleep. I have been withholding the huge amount of fixes and improvements I made over the February week long break to make sure that the Carousel (a very important UI component to Aurora GM) was working for the screens most gamers game on. As you might find on the change log a lot has changed in r_134, most of it is in the backend which as I mentioned in the previous post will be a major focus in the next few releases as we approach our Alpha release due date.
The Most important change in this release is the addition of the H2 database engine, which is a very fast, very small and java only SQL database that supports the JDBC API. I spent a day learning all the basics to work with H2 and SQL (had little knowledge of databases until then) and the next day I wrote a simple interface to the SQL and Database through the new aSimpleDB component found in the engine. It allows for a number of parameters to be passed to methods to connect and construct the SQL query for you. It allows for both flexible and simple methods as well as complete flexibility where a query in the form of a String can be passed to do what ever the heck you want with SQL. I included some Java doc documentation for this component because this component can be somewhat complex for people who also have no idea what a database is and how to interact with one.
The second important thing I got done was the Aurora Cover DB which is a simple database containing all 2500 game names and URL links to the actual Cover Art for that game. I created a class in the Core application called Updater which currently only reads a GameDB.txt flat file database of all the names and adds them to the database. It also algorithmically creates the URL for that link and also adds them to the database. Whenever I get a new batch of game Cover Art, I add the names to the GameDB.txt file and launch the updater to create the database which takes around 15min on my laptop. The result is a AuroraDB.db file which is now added to the lib folder. I then added some test code to the Game Library to make the appropriate name query and acquire the resulting URL to download (or check folder) for the game cover art.
Currently there is no plan to add automatic updating into Aurora Game Manager 1.0 due to constraints. But I fully plan on implementing a really amazingly slick updater that would do all the updating before you even launch the application, no need to restart, no huge files download, just really simple and slick updating, that will be in 1.5. Right now the Updater will be for internal use only.
Other than that I did some fixes with the aPrompter, the aAnimate, made Grids and Placeholders work everywhere including Search and also made some initial work towards the Add game UI (finally!). This means I will be working on finishing the Library. I have the backend planed in my head just need to finalize the UI of the whole thing and take the time to implement it. Carlos will also be working on finishing the library with me now that we have fully taken advantage of our SVN repository.
Well that’s it for now, see you guys soon!
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
Hello World!
So yesterday I uploaded r_106 snapshot to sourceforge, the release included some major restructuring of the start up/loading screen:
- Performance improvement in how threading is done for loading and transition as well as removing the need to recreate the entire AuroraUI for the Dashboard
- fixed some memory leak when going in and out of a dashboard item
- Improved and fixed how the going “back” button works
- Major refactoring done for aPrompter component in the Engine
- aPrompter is dynamic and prompts text on the fly
- selective color selection of what color each prompt can be dynamically.
- Text rendering of aPrompter and Time Label visibly better
- Loading now does correct folder checking (AuroraData) and can create profiles with complete folder structure.
- Loading includes slightly smarter internet checking
- aFilemanager now can create files, find files, and fully support serialization and deserialization of objects
- Games Cover Icons now Download to AuroraData folder the first time, then load from folder every other time.
This release has a lot of the stuff I have been wanting to do for a long time especially the recoding done to the loading screen and the various improvements to aPrompter as well as the ability to download game Icons. However I really feel like I’m just going over details and not focusing on the real core features. So here is the plan, I am planning on making an official alpha release by the end of march, which means core features like adding games, removing games, launching games, settings must be done by then, the Beta which will be released later will contain the tracking and recommendation part of the app.
In the next few weeks I will be working on implementing the database for Aurora, which will be a new experience for me since I have almost no experience in dealing with databases. We will be using the H2 Database Engine to handle most of the Game library and probably the tracking data. This database engine was introduced to me by a professor who found it to just as simple but much faster and slimmer than other database engines like JavaDB or MySQL, H2 is purely Java based and uses the JDBC api to connect to applications. I will be experimenting around and researching how to get this to work.
Other than the database integration, there are two things bugging me that I want to work on for the next release, the first of them being loading the dashboard in the loading screen instead of on the spot loading and rendering. It takes a heck of a long time to load the dashboard the first time (with no info in memory), so I need to either do some sort of pre-loading to make rendering all the stuff faster. A couple days ago I was tinkering around trying to scout for where the loading problem occurs and how I would go about to fix it, I asked questions on stack overflow and found some ideas, I even tried to enable Hardware rendering to boost frame rates with both OpenGL and DirectX, both failed to work properly. I think I found a fix that involves how we render images how we should use Volatile Images and Canvas etc. but we might push hardware acceleration to 1.5 and stick to just optimizing code for speed.
The other thing I want to fix is the instant search functionality which works and searches pretty well, except there are some problems with regards to selecting the game you search for in the library and a lostFocus handler detects the need to reset when ever something outside the search component is touched. Hope fully the latter two fixes can be made for the next release.
Meanwhile the rest of the team is still working on their own side projects: Carlos is currently finishing up the aCarousel improvement, which is much needed since its one of the focal points to the whole app. Demetrius should be working on the aInfofeed (news crawler) and do a similar recoding to what was done with aPrompter and make it more dynamic and less buggy. If any of these features are finished by the next snapshots I will let you know!
Thanks for reading!
Have a nice day!
-Sammy Guergachi
Hello World!
This is going to be an exiting holiday for us, I am finally going to have a few helping hands that will make the Aurora Project a reality. Hopefully I will be able to introduce them in a future post but we are very exited to get to ramp up production on the alpha version of the Aurora Game Manager.
Next we have released a new snapshot Aurora_r97 which may seem like a huge update but the revision number increased only because I cleared the SVN repo completely and recommitted everything (Engine and Core) from a local copy since I have been having issues with SVN lately. That actually caused me to consider transferring the project to Github, but we’ll see.
Anyways r_97 has the Lenient Search I have started work on during thanksgiving and have not had time to finish until now. The search works well to display live what you are looking for as you type, its a little laggy I found when you try to type while the Cover Art is loading, but that’s a threading problem with the Game Icon objects that I need to fix. The release also contains some updates to the V.I component of Aurora now called XAVI (eXperience Augmenting Virtual Intelligence) which is a fun side project dedicated to make the application a bit more interesting. The greetings at the launch of the app have been slightly updated and now include time sensitive greetings thanks to an initial contribution by one of our team members Carlos.
The next revision will have some performance boosts in UI loading and fixing some lingering bugs like memory leaks and UX things and stuff. It should be up in a few days (thanks to the holidays)
See you all soon!
-Sammy Guergachi
As some may have noticed I have updated the blog website.
Its a little better looking
It has more info
It showcases a new Aurora Logo
Hopefully you find the changes useful
Aurora Game Manager Blog 