05.31.07
Posted in News at 6:44 am by Jordi Fita
Yesterday Google released a new open source API called Google Gears that makes possible for web applications to work offline by using a local database. Google Gears is installed as a browser’s plug-in that synchronizes the local database with the web application’s remote database when the plug-in detects the user is online, so when she goes offline the web application can still access to the data downloaded.
Currently the first web application that uses this new API is Google Reader, but I guess that pretty soon we’ll see more applications soon and not all of them will come from Google.
Permalink
05.30.07
Posted in Amoebax, Projects, Thoughts at 11:52 am by Jordi Fita
A few days ago Ferran, Amoebax’s Windows® coder, sent our latests release through IM to one of his friends so she can tests it and send us some feedback for our non-GP2X builds since we did not make too much “advertisement” of them and so very few people has tested them.
After some problems installing the game, related to a badly installed Microsoft® Windows® Installer which I believed it came with Windows® XP but seems that no, she asked: “So, shall we start a game?”. Of course she though that the game was playable through Internet which is not.
Nowadays is so common that a game has a network mode that most players expect them to have it, not matter the game type or the intended audience: the game must have a network mode, either cooperative or competition but they must be able to play it through Internet, not only on a LAN. No excuses!
Then, why Amoebax does not have a network mode? Because I designed the game initially for GP2X only which does not have any communication device unless you are using ethernet over USB on you computer, but then the console becomes less portable ;-). Another reason is the lack of resources: at the beginning I was the only programmer Amoebax has, and I am still the core programmer, so I though: “well, it is difficult enough to make the whole game with all the available modes and all the artificial intelligent players, adding network here will end up being too much work for me alone.” Besides I’m not very good at network code, but that’s not an excuse 
I’m almost sure that, if we release a final version of Amoebax, the most requested enhancement will be a multiplayer mode over Internet. Heck, I even believe that a multiplayer only version of it would be more popular than the current version, like TeePop does, but then we would exclude the whole GP2X comunity, something I do not want to do.
Will Amoebax have a network mode available sometime? Perhaps, I don’t have a crystal ball :-). What I do know is that it won’t be available on the next version. Time will tell.
Permalink
05.29.07
Posted in Thoughts at 12:19 pm by Jordi Fita
Lately I’ve been thinking about a possible indie game business model that gives away its source code using an open source license. This is my opinion, so don’t take it too seriously ;-).
First, let me introduce my logic into thinking that keeping your source code “closed” is not always a necessity (but sometimes, perhaps, it’s a must).
Currently, most indie games use registration codes or files to prevent unauthorized copies by the so called pirates. My guess is that if there’s about 1,000 millions of users in Internet chances are that any of them will break your copy protection scheme. So, if you are indie, why waste time into an worthless “feature” instead of putting this effort into making your game better, when there’s such so little chance of not being copied? And that’s more interesting if you take into account that most times copy protection measures are more an annoyance than anything else.
Now lets imagine that I arrive at the conclusion that copy protection is not worth the effort because I can’t avoid piracy and I must learn to live with it. If that is my conclusion then I will give full copies to registered users without any copy protection, which means that anyone could copy it. Is this bad? Perhaps, but I already discarded copy protections because they weren’t effective 100%, so what’s the difference?
So, if I give the game without any copy protection, then why I need to save the source code only for me? I could put the source code under the GNU General Public License and give it to my registered users as well as the binaries for their platform. Why will my users buy the full game when they can fetch the source (or even the binaries) from another place and compile the full game? Well, not everyone understands how to compile from source code, and they don’t care, so they probably will do so to prevent the headaches. But more probably because I’ve given the source code for free (as in free speech) but I didn’t do so for the assets, which are licensed in another more restrictive license. Now if you want to get more levels or pass the point where the asserts are not free (as in free speech and free beer, that is the demo version) then you have to pay and promise to not distribute them, as you did for other games’ binaries ;-).
Someone, when listening to my idea, asked me: “But this means that if someone made the missing assets, they will have the full game!“. And it’s true, but I think that if they have taken enough time to make all the graphics, music, sound effects, levels, etc. necessary to run the full game she deserves it ;-). Seriously. In fact, this happened to other open source games and I don’t see any problem, providing they give the binaries and the source code under the GPL as they must do since the original source code is licensed under such license.
Now, after all this, what are my benefits? I don’t have the resource nor the knowledge to make games (in general, but more specifically) for other platforms than Windows, OS X, and Linux. So if someone likes my game enough to make a port (with their own graphics) to other platforms like PDA’s, then they have the obligation to give out the source under the GPL, so I can also have support for this platform without too much effort for my part. This also happened to other open source games :-D.
OK, this was my thought. Perhaps I’m too naive, but I think it’s doable. Of course you have the right to think otherwise, but I would love to know what you think about my idea.
Permalink
05.28.07
Posted in Thoughts at 11:37 am by Jordi Fita
Recently I bought the game Tribal Trouble by Oddlabs through Gibbage.co.uk as “[...]every penny of profit this site gains will be plugged directly into funding future independent game projects.” (in case you are interested, I also bought Professor Fizzwizzle by Grubby Games and Eets: Hunger. It’s emotional by Klei Entertainment.)
Tribal Trouble is a very good 3D strategy game made with Java and so runs on Windows, Mac OS X, and GNU/Linux. Now, I don’t really like Java (personal preferences) and normally I tend to associate Java with slowness, but surely I have to change this misconception as the guys at Oddlabs made an impressive work: the game looks very professional and I haven’t noticed any slowdown on my Intel-based Macbook.
I haven’t played much yet, but what I liked all I’ve seen up until now, specially its update system. The first time I used Tribal Trouble’s update feature didn’t had any update to do so I couldn’t test it properly, but yesterday I had a problem with the last game’s tutorial: when I moved from tutorial 5 to tutorial 6 the game crashed!
When the game crashed a popup dialog informed me that a “NullPointer Exception” was thrown and that if this error happened while playing I should send they a bug report. I started the game again and indeed the report bug window appeared prompting me to enter a description of the error. Before that I tried to go directly to tutorial 6 from the Tutorial menu to see if it was just a “glitch” or the game had really a bug. It crashed again. This time I wrote my bug report and sent it.
After sending the bug report I saw the Update menu option again. I though that I should have updated before sending the bug report, but it was already sent I went to the Update option and this time there was update to do. While updating I saw some file with an interesting name: they ended with the “.svn-work” extension. At first I believed that I had misread the file name as they passed too fast, but then I couldn’t resists and I looked inside the package to see if I could locate the “.svn” directories that they should be if they were using Subversion and indeed I found them. Of course this is not a secret, they even tell so in their FAQ, but I think this is a very clever way to use an existing architecture: why wasting time implementing an update feature when there are so many nice options to choose from? 
Oh, by the way, the problem was solved when the game has been updated 
Permalink
05.21.07
Posted in Amoebax, Projects at 11:41 am by Jordi Fita
Right, is that time of the year again: we released Amoebax version 0.1.2. Actually, it doesn’t have anything to do about the time of the year since we are releasing versions as soon as we have enough new features to do so
This time, Amoebax’s “big feature” is the addition of the tournament mode. This mode is the only available mode that lets two, three or four players play at the same game, but not at the same time of course ;-). The tournament mode creates matches of two players that fight each other. The winner gets promoted to the next match while the other competitor stays at the same place crying out of shame (well, not literally). Here are some screen shots:
What does it mean for the GP2X version of Amoebax? Well, in a previous post I already gave hints about a two players mode that we were working on for the GP2X version of Amoebax. This version is the first public version that includes this new mode only available on GP2X in which two players can play a match on the same console. I’m a bit nervous waiting for comments of the people who will test it
Hopefully this version will be the last “development” version, since we implemented all features we designed for the first stable version. So we are now in a “polish” stage where we won’t add new features but fix bugs and make some minor enhancements to the game.
Permalink
05.16.07
Posted in Amoebax, Projects at 12:12 pm by Jordi Fita
I’ve been playing with the devkitPro’s devkitARM toolchain for the last couple of days, just out of curiosity to see if I could do something that could run on the Nintendo DS. It’s not that I own a Nintendo DS, but a friend of mine does and he always asked if I could be able to build a port of Amoebax for him
Since I’m not new to cross-compilers (I’m not an expert either) I had little problems installing an running the devkitARM toolchain on my GNU/Linux box, although I presume it’s more for the fact that the guys at devkitPro did a wonderful job putting together a binary tarball that just works out of the box. Then I found a port of the SDL for the Nintendo DS created by Troy Davis, and that gave me that feeling that Amoebax could be compiled for a Nintendo DS.
Of course, just having the SDL libraries available doesn’t mean that Amoebax could be compiled and run as easily as it can be done with the other supported platforms. I had to learn how the sample Makefile works, how to put the graphics inside the DS rom, and which emulator to use
At last I was able to do it, but there’s a lot of missing “features” that renders the game unplayable, yet, on a real DS: no joystick support, no sound, no music, and it’s really slooooww.
Anyway, here are a couple of screenshots take with no$gmb emulator just to prove that I was once able to run Amoebax on a Nintendo DS:
I’m pretty sure that the Nintendo DS version of Amoebax (if we actually make the port) won’t be the most downloaded version, but for sure I’m taking a lot of fun with it.
I was also thinking about a PocketPC version of Amoebax, but I’m having problem building the toolchain. I’ve tried with the cegcc and mingwce version, but then I wasn’t able to compile the SDL library. I also tried Microsoft’s embedded Visual C++ 4.0 but I had the same results as with the GNU/Linux toolchain. I’ll keep trying, though
Oh by the way we are going to release the next version of Amoebax, version 0.1.2, Sunday 20th May. For more information about this version, see the milestone page on our Trac.
Permalink