Angstron 2 – finishing touches

UPDATE: wanna try this? so follow this link - http://batterypoweredgames.blogspot.com/2009/05/angstron-2-droid-hunter-beta-test-2.html

Finishing the last debugging, improving speed (for the first time, Im quite satisfied with most of the game speed. but level 3 is still my concern) and – to my shock – solving some plataform specific issues:

- Sound in maemo. I dont know whats wrong, but the sounds is not working with the 770. I will look over the old angstron1 code @ garage to see whats wrong…

- Memory footprint in EZX. The A1200i handle the first two levels graciously, but the game dies when loading the third, after a lot of time loading.

- Also on EZX: The chapter screens need some serious re-work .Ok, they need some re-work on all plataforms, but on EZX  its far worse.

- And finally, on EZX, I dont seem to get the icons working on the menu again. I had it working in the past. I dont know whats wrong now.

For desktop PC and EeePC  everything is fairly done.

And now, some teasers!

My plans is to have the game finished and released for the Rio Game Show 2009

Angstron 2: Droid Hunter finished-almost

UPDATE: ITS FINISHED!!! http://corporatedrones.wordpress.com/2009/07/22/angstron-2-released/

Hello folks.

I guess I’ve finished all the ingame  assets for Angstron 2: droid hunter. Sure the render is not ready for prime time (but it does perform decently in most cases), but this is a matter of time.  In any case, I’ve got a OpenGL version of it fully working and a OpenGL ES version is on the way.

My previous decision of scrapping level 2 was aborted (hence you will see the horde of morcegos in all its glory), but almost all the levels need some better POV-BSP-prunning during rendering before shipping. There are several points with some minor visible artifacts , some culling errors here and there and a few slowdown spots. While for a freeware game where there’s no compromise, I cant simply allow this to be released.

The game play remained unchanged from the previous beta releases, with some adjustiments still to be made.

The 2D artwork is seriously faulty and in need to be re-drawn. This is going to be a looong paper-and-pencil-than-flatbed-scanner-then-inkscape process. Dont hold your breath.

The game was somewhat delayed due to my lack of luck with UNIX this last weekend (http://corporatedrones.wordpress.com/2009/04/14/solaris-ubuntu-xandros-eeepc-problemas-meu-dia-de-azar-com-unix/)

The release will reach both Maemo 2.2 and the upcoming Maemo 5 (“fremantle”, powered by hardware acelerated OpenGL ES!), EZX , EeePC (this time, with a better packaging system, from the official SDK!)  and desktop linux.

Mid Feb 09 Report

I just realised how screwed up I am! I “released” Riddler about 6 months ago and consistently looked at it for most of this time (but still I dont consider Riddler a finished product, as I consider Angstron) and never got it:

a HUGE typo in the game logo!

I dont know I missed that for so long. But thats it. these last two days I had a really HARD work to adapt the menu system I wrote about a year ago (back in Toronto) to work with vector graphics and parsing its contents from a XML (very similar to WML). Maybe its time to ditch all the art, and maybe even change the game name. The game itself doesnt contain any riddle! More on that later.

Now, for something completely diferent

You probably heard it before: ” Never optimize it early. Always make sure it works from end-to-end first, and then optimize it”. I just saw it on a book Im reading (again):  “Data structures and program design in C++” by Kruse and Ryba. Its a nice book. kind of a encounter of the old school and the new tendencies from late 90s. Kind of a entry-level art programming book. You would rather read this before reading Cormen or Knuth ( Kruse->Cormen->Knuth).

But about this lemma, I have a counter-argument when we’re dealing with open source software.  Optimizing it early attracts attendion and helps gathering momentum to the project. And every possible consequence to the Linus Law. And goes in acordance with “release it early and release it often”. Others will come and fill the gaps on functionality and fix bugs. The important thing is to show something compeling.

Of course, dont take my work to the last extremes. As my wise teacher , Vinod Rebello ,from college once said in class: “there’s always a trade-off”.  Developers might get frustrated by the lack of functionality or maybe readable code. Indeed, Im very surprised on how people could actually read the Linux Kernel code.  Its very annoying! But thing is: Linus released a very 386-optimized UNIX-like kernel and that attracted atention. Plan carefully your releases, even when releasing often. Repetitive and irrelevant releases might also get away with help. I learned this the hard way…

As a last note:

From the last post, I said I was about to test World of Goo. Well…

HOLY SHIT!!!111 Too bad I cant buy it from Brazil. This game is AWESOME! I dont remember playing a Linux game so well finished. Unreal Tournament 2004? not even close! I felt like playing some fancy video game in a last generation game console.

Other game taking my time is Warzone 2100 – a former closed source comercial game made open source and ported to linux. The game is simple, but very inteligent (well, not its unit IA)  and very adictive!

BZK_Vacuum2 for PocketPC – finally!

Thats right! I finally got it working!

And with minimal code changes!

Thanks for the CeGCC project for making this possible!

One thing worth of note:

Its extremelly slow (without any -O at compiling time and with gx.dll, on my iPaq 3660)

I must also add that the game menu is not very QVGA friendly. you cant really see the menu. Only part of the Angstron logo.

This is actually a unfair comparission…with the Nokia 770. The build running on the iPaq was compiled with -O3 and the Nokia is running a -O2 build. The Nokia not only has a complete Linux OS, but also a lot higher resolution and sound. I didnt expected the iPaq to perform so slowly, but its quite proportional to their Quake versions. I probably have to rework the way BZK run on such plataforms…

Global Game Jam update

Try our game!

http://www.globalgamejam.com/games/it-came-cave

dont forget to vote sincerely!

Ok,  now Im quite recovered from the big thing.

I’ve attended the Rio de Janeiro instance of Global Game Jam (it was on my university anyway!)

Anyway, after a lot of preparations, installing Windows XP, Visual Studio (from Academic Alliance) and XNA 3.0 and a Ubuntu 8.10 fresh dual boot I was “ready” for it. Kind of.

Day 1:

In there I faced , in the first 5 hours of work, a unworkable enviroment. I didnt know where to begin. I wasnt used to create games creativily in such a crowded place. I rambled. And to complete my dispair: My XP got a virus from Carlos thumbdrive, the wireless only worked on Ubuntu (!!! more on this later) and this Ubuntu was very unstable.

Getting on track was a difficult step, but certainly a great step. Once I got the pace of things, it was very easy and after a faux start (I misundertood the theme), I started codding: The basic graphical core of the engine was done in about 2 hours!

After that, I spent another 4 hours on a SVG render for C# – Me and Rubia wanted sleek graphics that a sprite renderer couldnt provide. And SVG was the answer. Or at least looked like. After about another 2 hours since I started , I had a SVG (the BZK Logo) working on a GTK# window (code done in Mono!) and another 2 hours fiddling this code and the weird XNA polygon pipeline and I gave up. The SVG always laked a few vertices that made the image look wrong.

After dropping the SVG idea, I had to get some sleep. The sun was shinning again.

Carlos stood behind, still coding something like a random terrain generator or something like that.” He’s crazy anyway!”

Day 2:

After some 6 hours of sleep (looks like I had more sleep that some teams alltogheter and maybe I hold the sleeping record of the GGJ), I was ready for some more.

Time for some game mechanics. Carlos wants me to code it OOP, but Im all Structured-Programing here. There’s no need of OOP for such a project and such time constrainct. He kept complaining until very late of that day, while there still I had the chance to do it with classes, but I , as the captain, got as stubborn as I could to resist the idea. He wasnt really wrong at all. And neither was I.

By that time, the BZK gaming model came to my mind. Diferent states being diferent numbers and treated like different entities, but somehow related by a number range. The result is very buggy but its almost working.For the IA we had a very loose definition on how the IA should work and we settled on two basic algorithms , to make the monsters run into each other. One being very smart (“cheating”) and the other being dumb. (Angstron IA algorithm).

In the afternoon I decided to try to clean up Windows, as a new virus had appeared and was getting in the way. Unfortunatly, ClamAV couldnt solve the problem and I lost 2 hours on this. Damn it! I also finally came up with a good song for the game: We vs Death – And how we translate it. I already had this file in my computer, from a pack of CC music I downloaded. And after a quick check, their Creative Commons restrictions allowed me to use it! Great!

Also during this scanning time, I went out of the room with Carlos’s Palm Zire 72 to record some sounds. Mine got shabby, but then I discovered in Carlos a real voice talent! With him, we recorded some taunts the miner would say after killing the monsters. Carlos is a real Duke Nukem!

Almost in the end of the day, I finally had the smart IA algorithm working (after two tries) and everything else was in place. Rubia had just finished the artwork in SVG and during the final 30 minutes of the virus scan I was turning everything into sprites and adjusting the aspect ratio. After we got the final artwork in place, the thing started looking like a game! I got confident that  we could finish the game! Rubia was very excited. She never have seen any of her drawings turned into a interactive animation!

Carlos had just finished his algorithm and was getting it into the game engine (And he didnt test it before porting it from Delphi to C#!). He pointed that me the fact his algoritmo worked better with BIG maps and all I wanted was a small -no scroll- map. I was afraid the player would get lost in easily. But Erick (from the Torresminho Team) gave the idea of a minimap and showed me how to implement it. Finished! The sun shines very hot though the window – Time to get some sleep.

day 3:

Sleepy sleepy boy. Another 6 hours of sleep!I was working on the IA and the game mechanics. After a a while, I finally came up with a idea of a dumber IA algorithm. re-using a scraped IA and mixing it with the smarter IA. And it works VERY WELL!

Time to finish it up! Rubia got into creating still images for the “menus”, Carlos was fixing timming and I was finishing the game mechanics. In the end , we paired to fix the losing and victory conditions and we still had to code the game state for the tittle , game over and victory screens. In the end, we got it, but quite on mark. Almost 20 minutes to the deadline. And I perceive the gamestate as the only annoying bug in the code (aside from some defective “gameover detection code”). Quite good for a 43 hour gaming marathon. Too bad I overslept , lost too many time eating and scanning the computer. And there also the times I needed internet and I had to reboot for Ubuntu.

Aftermath:

The actually enjoyed this game more than I expected. While the code is messy, its functional and somewhat stable. Game Design-wise its  very solid(Carlos had the great idea) and entertaining. I want to port it right away! Carlos also told me so yesterday. Too bad XNA is not very cross-plataform on itself , but it should be very easy to port it to Java.

What I got from all of this:

- I can do more than I imagined

- I must trust Carlos even more (we always do our assignments togheter, as we know and trust each other’s methods)

- I got a SVG C# reader!

- I want to port Carlos map generator and make it generic

- Wireless is a bliss

- Audacity rocks

- Gimp and Inkscape too!

- Lack of sleep makes me moody

UPDATE: for a while, we were:

1º in Rio de Janeiro

1º in Brazil

4º in the Global ratings. Nice er?

Now the stats got completely scrambled again, but at least I had this peak!

playing with FSM and guns

It is possible to implement some good games with simple FSM and a good load of creativity.

To show you this, a simple exemple: using the actor FSM and a second FSM for the frames (I know, I should use only one FSM, but hey, one step at the time), I could reproduce a ROTT-like double gun effect:

the original:

my version (SVG guns):

Angstron paper toy 1

The first to come!

my next model will probably be the biker itself!

instructions:

- fold everything with a black line in it

- gently apply glue on the red marks and use it as sticky-tabs

finished model

all prototypes and finished version

just print, cut and assemble

The Riddler – public beta 4 – Release Candidate 1

A few friends had the chance to try it out, but now its time to a public release. The game is mostly done. There are only a few rough edges. And I also want to lit the game little bit more.

Please, test it and let me know of the results.

UPDATE: This revision RUNS on EeePC 2G Surf running Xandros AND in Ubuntu .

news from this release:

- since I lost the code from the newest version, I had to re-work everything from a snapshot on the EeePC’s SSD that was a little outdated. As a bonus, we got back the EeePC compatibility.

This is the final beta release. If this works out, I will remove some last debugging messages and package it properly.

some minor improvements in speed and now it runs on fullscreen.

the matches have all been lit!

update:

http://batterypoweredgames.blogspot.com/2009/07/riddler-final-release.html

Only Linux builds for now…Eee and Maemo builds will come later…

Indie game development using ubuntu desktop Linux

In the past years, indie game development went from sitting on dark basement, staring a black and white screen, fiddling cryptic messages to decode the VGA registers in order to achieve the maximum performance to sitting on a dark basement while staring to gorgeous GNOME or KDE screen while tossing the maximum perfomance from your GPU with no sweat. (Of course , some of us still love that darn pretty black screen)

From this dark ages to current days, linux game developement went from an adventure to some serious play, as the tools matured and CG companies took linux more seriously as a development plataform.

This article intends to present the reader with some good options on linux game development, while analysing the reasons of this linux-gamedevelopment-takeoff.

the dark ages
Picture this: You have a prety console screen on your machine. Whats your gaming options? None, you might answer. You cant be more wrong that this.

Before XServers were commonplace, there were already a struggling game development community. Most of them came from the existant BSD community and saw a good potential with that “fast and lightweight UNIX” that linux was (today, both Linux and BSD seen to be in the same level) and then we got our share of console games, like dopewars and other console classics.

Needless to say, developing this games was more challeging than playing them, as they didnt have the tools available today. But these dark ages wouldnt last long.

The golden age of unix graphics evolution
Since the start of the modern computing industry, UNIX was the standard defacto for serious applications and before the macintosh take-over, UNIX was the absolute king for computer graphics.

Then it came. The graphical revolution for the UNIX workstation. First, it was a indutry or office thing only, but then, we gradually , got a XServer running on our machines.

But still, coding a game is XLib can lead to a suicide. How we got such great games like Planet Penguin Racer or Super Tux?

The main reason should be two invetions here:
OpenGL and SDL.

OpenGL opened a new world in computer graphics. Being mostly a Silicon Graphics thing, it was for sure a UNIX-friedly thing. Of course, after passing the hurdles of getting a X window with OpenGL content. With OpenGL we could finally get our Quake after a hard work day.

And while OpenGL did great things for 3D graphics, It carried unessessary weight to 2D Game Development. And the developer had two options: use the unacelerated but closer to other 2D APIs XLib or to go with the (sometimes) acelerated but unatural OpenGL; Some of them ran to GTK and other toolkits, but most got lost on this. And then came this man, Sam Lantinga unify our battlecries.

Sam Lantinga had to port a Macintosh emulator to windows and linux…But hey, coding a graphical system for every Operating System sounds a crazy thing. And it is. He had a simple but dauting ideia: write a abstraction layer, called SDL, and the rest is history : He got Doom ported to SDL is 3 days!

Now we can use SDL in a huge variety of plataforms, ranging from mobile devices (more about this below), Video Game Consoles , and lots of mainstream and obscure operating systems.

With SDL, developers could actually go through the “create window for OpenGL” novella in less than 10 lines of code.And binding for other languages spring every month or so. I bet he didnt saw that coming.
The Java monster

The hearts of millions of programmers (those include even John Carmack) were touched with this promisse: “Now we can write or own AAA game for all plataforms”. Unfortunatly , it took somewhat for the idea to catch on for real. What the java applets really were able to do was a little below that. But still, as Sun released their JDK for Linux, it was quickly possible to write java applets on a linux box and see them running on Macs and windows boxes.

Basically , this was a time for small arcade clones and advergames. And for several startups funded for advergames, the linux +  java applets were the killer combo. Most of the technical staff of those came from those tech geeks using linux since college.

But still, the premier time for smooth java game development was yet to come, and we will return to this later.

Take it in your pocket
If mobile is the name of the game, you’re lucky. Mobile development under UNIX have been strong since the beginning , with J2ME mostly, and now, more recently, with Linux Mobile.

With J2ME , there are plenty of possibilities -Some more mature, like NetBeans and sun WTK, and some brand new, like Nokia’s WidSet. Linux is being taken seriously by the big players, as most inovations in terms of design comes from freedom fighters, like us. The only possible downside of the approach might be the plethora of proprietary protocols mobile phones use to comunicate with a computer through the data cables. Be sure to take a phone that speaks “Mass Storage Device” to the computer.

Recently , we have seen some companies going with linux for their mobile OSes. We all gain with that: this mobile linux is not that diferent from our desktop machine and most SDKs use technologies broadly available. Its like playing with your childhood friend’s child.

One Common point when dealing with mobile game development is the use of Simple DirectMedia Layer. Most mobile distros allow SDL apps to run with privileged speeds. The biggest distros here are: QTopia, from Trolltech (the guys that gave  us libqt), EZX (QTopia based), from Motorola (some warnings apply here, as it doesnt run native applications right out-of-the-box), and mostly Maemo (the one yours humble writer like the most to code on its day-to-day), from Nokia and finally OpenMoko, that is a joint effort to produce a distro for mobile phones.

Also worth mentioning that Ubuntu Mobile is to become a great mobile OS, incorporating the UI from Maemo. Looks very promissing.

The dawn of the desktop

As Linux evolved from the last decade, we could stop worrying about or desktop and could concentrate on producing something. This is a byproduct of projects like Ubuntu, that aims to bring more focus to the developers, putting them to do their best were they excel.

There are also smaller efforts on some countries, like Brazil, to use Linux as a medium of knowledge broadcast, creating social projects that called for more average-joe-friendly desktops. Those are fertile field for Linux gaming.

Also, there are other companies using linux for notebooks (but this distinguish from mobile linux, as there is a full linux machine experience), like ASUSTEK with its EeePC and OLPC (the last one making big bets on educational gaming),each being too big use case to cover here.

Name your monster

Now that you cant wait more to get yout hands dirty, I will show you some good options to develop your own games.

Desktop:
emacs (or your favorite text editor) & g++ :
Thats right! chances are that the exact machine your are using to read this text is capable of game development. Althrough the experience can be somewhat spartan, its perfectly possible. Except for a few moments I ran for some better tools, I went this way to develop my own 3D mobile game engine (www.sf.net/projects/bzk).

Mobile:
If you’re going for java, make sure you take NetBeans, as it have a very strong mobile support. Dont forget your “mobility pack” for the chosen mobile device proile.

If not, you’re gearing towards linux mobile, good and bad news:
The good: most of your existent desktop code will work out of the box.
the bad: you will, probably (as most mobile devices use ARM processors, incompatible with our x86 machines) need to recompile it with some exoteric SDK. And this will depend on the target plataform. Some are easy, some are not. Make sure to also research whats the best settings for your workstation – sometimes, virtualization can be a viable option.

One good advice might be using SDL. I can attest this, as  I do most of my development on my desktop enviroment and when I feel the need, I just switch to the mobile SDK (in my case, Maemo SDK under Scratchbox), recompile, generate a debian ARM package and test it on device (Nokia N770). This can save you valuable debugging time.

Art:
With the arts departament, the best tools (but now the only ones) to use is Gimp and Blender for graphics (with the advantage of running also on Windows, for that goofy friend of yours that still uses Windows) and Audacity for sound (GNU Sound being another viable option). Rose Garden got some fame to be good, if you can get over the JACK nightmare, when producing music (if you cant use Rose Garden, just invite that friend of yours to play their songs, but make sure to turn of the vocal’s mic )

Conclusion:
With so many options, anyone would wonder why are you still reading this instead of producing your next Quake 5. Now , GET BUSY!

Angstron debian package final releases

Finally, I’ve learned how to create debian packages the correct way, so here we go =-)

update:

Release candidate 2 – now with good icons, full sound and music (no music for 770 version due to the lack of native OGG support )

http://sourceforge.net/project/showfiles.php?group_id=167767

EeePC users:

if you have a customized menu, Angstron will override it. In order to run , take the binary from inside the debian package (angstron-0.99-EeePC/data.tar.gz/./usr/bin/angstron) and copy it to the same folder of the regular debian package.

OR

you can always checkout the source code from sourceforge (http://www.sf.net/projects/bzk ) and run angbuild.sh. I did it several times FROM the EeePC.

Now, I must state this:

I wil stop working on BZK from now on. I have to graduate and this gamedev thing got on the way. I will probably fix demanded bugs and work on it for my grad-thesis, but no new feature will be incorporated.

I will also stop the work for “The Riddler” and every other side-project I have. Very sad, but true…

PS: the last Maemo release still worth as the definitive, as I changed little things since then.

The saddest thing is that the EZX release was around the corner and even more the PocketPC port, as I had it compiling, but not linking…

funny icon, huh?