Back when I was initially designing Atlarius, I toyed with the idea of using Django to create it. In fact, I went so far as to begin to describe the data models using Django’s system. I found, however, that a limitation in the way I could describe the models caused me an issue at the very start. I forget exactly what it was, but though I probably could have found a way around the problem it caused me to think “If I have already hit a problem, should I take the chance of encountering ones with no solutions later in the project?” So, I scrapped the idea and went with PHP.
However, recently I have found myself applying for a developer position involving Django. For this reason, I decided to take a closer look at Django. In a few easy steps, I created myself a simple blogging system allowing user comments (screenshots here and here). I was quite impressed by how easily the administration module and HTML forms were created with Django.
So, here I am, both impressed by Django and wanting to learn more about it. I am considering using Django to create a simple version of the Atlarius engine and see how difficult it is. On the other hand, that seems like such wasted effort. I’ll have to see if I can think of another useful project to create with Django. Or perhaps a worthwhile project to contribute to. Decisions, decisions.
The time is almost here. Many, many hours of development have gone into the overall product. Now, finally, that effort is about to come to fruition. It is almost time for the Atlarius closed alpha! So for all the people who have offered to test the game, your time is almost here. I want to thank you all for your interest in Atlarius; without it, the soul of the development effort would be gone.
I hesitate to promise a date. There are always last minute problems that cause many more headaches than expected. However, barring that… fourteen days at the inside. Twenty-eight at the outside, and the game server should be ready for multi-user alpha testing. I hope everyone reading this is looking forward to it as much as I am 
You can see screenshots of the default game engine interface here (one, two, three).
Now, here is the same code powering a new template I dropped into the gamedata folder: One, Two, Three. None of the engine code was changed to make this new interface. Delete the gamedata folder and it all goes back to the default interface automatically.
That’s right. It’s here. The release you’ve all heard absolutely nothing about and thus couldn’t possibly have been waiting for!
Nevertheless, it is a very important release. Before this, creating a custom interface for your game involved modifying the engine code. Now there is a complete custom templating system that allows users to reuse engine interface components and control the style entirely via CSS. Drop a new game interface into the “gamedata” folder and it automatically starts working. Remove it and the engine interface starts up.
In addition to the interface templating system, the entire UI for the game engine (including all the reusable components) has been redesigned in XHTML 1.0 strict using CSS for the layout and style. Screenshots are available at SourceForge.net, or you can download it now and try it yourself.
Disclaimer: This is a development release. It has not been fully tested and is not meant for production use. The XHTML hasn’t been validated against the w3c parser yet either (it will be before v2).
As of tonight Amun final has been uploaded to the files section of the website. Some significant bug fixes have been implemented since the release of the beta, so you may wish to grab the new release asap. At this point, to the best of my knowledge, the game design interface and the ticking engine both do what they are supposed to. I’m also just as certain that more bugs will show up eventually; c’est la vie. Such is software development. I’ll squash them as I find them, but if you see one please send me an e-mail and I’ll fix it.
Amun Beta, so named after the Egyptian god of creation, has been released! It has been a while since the alpha release of the Atlarius game engine. That release was merely a shell, a ticking engine with nothing around it. Now that the beta has rolled around, it is so much more. Besides the vast number of design improvements to allow for much more dynamic game content, I have also created a web interface and installation script to support the engine. Now it is simply a matter of running install.php then putting your database username/password into the config.php file and you are running Atlarius!
So go ahead, try it out, and most importantly find out what isn’t working and let me know so I can fix it. The beta version will be feature-frozen for seven days of debugging before the final release. Now is the time to try and break it!
Short post. I made a site for the engine. See it here.
This is a very happy moment for me. I’ve written a lot of software over the years, and I’ve used most of it a fair amount in my personal life. Until now, however, I had not created a complete, release-ready piece of software suited for public usage. There was always something more important to do during university than, for example, to polish my web portal system up to release standards when there are so many other ones available.
Be shocked. Be awed. Be amazed! Look upon its beauty and bask in its glory. Right, enough talk, here’s the good stuff: Atlarius v1.0a source code, released under the GPLv3. Part of the release notes quoted below:
Features:
-Fleets of ships owned by players.
-Fleets can attack or defend other players
-Fleets can take over enemy planets
-Attacking fleets loot enemy planets
-Resources are salvaged from destroyed ships by defending planets
-Players can upgrade their motherships
-Players can research new technologies
-Players can construct items on planets
-Players can produce more ships
-Resources are mined from player-owned planets
-Mothership repairs itself and regenerates energy
As of now, my game’s combat system is functional. I can (and did, for quite some time) sit here and run the ticker over and over, watching the test fleets attack and defend each other. I certainly wouldn’t venture to say it was the best possible way I could have written the combat system, but there are major advantages. Even at worst possible run time, it’s nowhere near O(n), with n being the number of ships in combat. In fact, it will generally run much closer to O(y), with y being the number of fleets involved in combat. It will actually be a multiple several times this number, but on a much smaller scale than the total number of ships.
Well, it’s around quarter of three in the morning now. Probably a good time for me to get some sleep. Or maybe I’ll go watch a few more ships destroy each other. 
One might recall a previous post I made about upgrading to KDE4. One might also recall certain problems I had with KDE4. I didn’t mention then the full extent of it, but rest assured there were many problems, including my idle cpu usage being at around 90% for one core and 60% for the other core. I finally figured out what was causing the majority of the problems: A ridiculously poorly made little widget that checks for new messages in a few different applications. I thought it would be handy. Instead it made my desktop unusable. Now KDE4 is running quite nicely, with my idle processor usage being at around 5-10% per core.
On another note, development of my game is going quite well. For those interested, I intend to release the game engine under the Gnu General Public License version three. The game content itself will not be so freely available, for which I apologize. I am torn between my want to give developers the ability to use my code and the need to make some sort of profit off my software. This is the compromise I have reached. I hope it is satisfactory to all. You will have free access to the code, to do with as you please (even make your own commercial game if you so choose) as long as you release your own code. I ask nothing in return except that you please not attempt to copy my own game content. It would be unethical.
The project is moving along on schedule. In the past few days I have put together several hundred lines of Python code which includes the database description (models in Django which are translated into tables by Django’s code), a script to add test content to all the fields in the database, and several functions within the ticking engine. I am currently at work on the combat system. It is, even more so than I would have imagined, a very tricky process. So many comparisons to do, so many choices to make. Who does each ship attack? A random target within its weapon class match? Do ships alternate between opponents? Should I take an event percentage of ships from each adversary? What about possible bonuses to attack damage and defense from each opponent ship? Should I take a lower percentage from those better defended? Or should I send more attacks against those more heavily armed? And most importantly, how do I decide all this in an efficient manner?
I’ll be honest. It is giving me headaches. I could easily program a brute force method for any of the above. What I need is an efficient way to do any of them. I believe I shall settle on taking an even percentage of ships from each adversary. This is after almost two days of considering the ups and downs of each aspect of the problem. I think I can code that in a relatively efficient way: Which is to say, I think I can code that in a way that does not require O(n) loops, where n is the number of ships involved in the combat. I can instead perform generalizations about the groups, and have less calculations and comparisons required. This pleases me.
Well I’ve rambled enough for one day. Adios my friends.
