The Riddler updates – And what about the visual identity of the game?

After some time just doint some ant work, I’ve finished both the game mechanics and the levels.

Now its time to give it a visual identity. One thing that annoys me today is the number of graphically similar games and I can understand why it happens. Take Riddler for instance: It is currently using all 2D graphics from Angstron1! Of course I still have to update lots of stuff, but most developers forget to change some of the graphics as they still have the balance from the development time.

Other important thing is the configuration and asset management. After you finish your FIRST game, and you go for the second, you might wish to use the same code base and you will have to came up with a scheme to switch between assets of the two games. Its not a easy thing to do and Im facing it right now.

Being a cerebral game (instead of a action game, like Angstron 1&2), it must have a more bland (Myst!) visual, more calm. Even with the fact that the user must acomplish everything in 40 minutes.

To make this more clear, compare Prince of Persia 1 & 2 (Shadow and the flame) with the newer ones. Specially the first one, they were puzzle+action games and his pace didnt disturbed the gamer.Funny enough, the marathon games also had this pace, even being a “Doom clone” (how unfair! Marathon is SO MUCH BETTER!).

Now, ,grab some paper and pencil and back to work!

Installing the Maemo Gregale SDK – an updated guide

Im writing this as of august/2008.

FYI, Im not responsible of the consequences of this tutorial or anything related to it. If your N770 turn into a zombie TabletPC and start a zombie-run looking for fresh penguin blood, its not my fault.

Lots of things happened to the Maemo community and its fair that they moved on (they’re pushing the edges of penguin mobile computing to the edge, and the EeePC , in my point of view, is a direct consequence of it). The documentation on the installation of the SDK is a bit outdated, so Im going to deliver a more updated view on it.

My system is a Ubuntu 8 x86 32bit box.

My reference: http://maemo.org/development/documentation/tutorials/maemo_2_2_tutorial.html

as you finishing extracting all the scratchbox packages, please run /scratchbox/run_me_first.sh

I dont know why they omited this, as it was part of the docs before.

then proceed the installation as indicated until you have to login into scratchbox for the first time.

then , you will probably face some weird error messages:

You have to add these two lines into  /etc/sysctl.conf :

vm.vdso_enabled = 0
vm.mmap_min_addr = 4096

After this, reboot your system.

Then, as you proceed, you have to copy the rootstraps to /scratchbox/packages. Make sure you change the file permissions to allow everybody to read them.

Also, as you login, the guide will instruct you to run sbox-config. This tool was replaced with sb-menu. So you have to configure it in a new way. When you have to select the rootstrap file, there is another catch: You have to place the cursor above it ,PRESS THE SPACEBAR AND THEN ,ENTER.

And finally, when it is asked to you where to install the stuff, select all the options. It will complain about /usr/include/asm, but you can safely ignore it (I guess so).

I just tried it with a test build of The Riddler running fullscreen on the 770. Works fast! Even with the lightning on!

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!

SVG updates

billboards

wall texture.

wall textures

I didnt expected SVG to be such a savior for BZK, but it is becoming one. After implementing it, I got it working first for 2D images (useful for scalable menus) and then for 3D (first as billboards – useful for effects. Every actor now has one) and after that, I made a hack so we can have it as wall texture (only walls, no floors – this will be fixed very soon, or not.) , and then I finally extended the GEO format (and of course , updated conbed) so it allows a texture to be specified.

It is now perfect, there are some memory leaks here and there and there is a lot of waste in terms of allocation. Im not re-using allocations when I actually could. I will create a resource manager in the next few days.

The most surprising effect I got with curves. I dont render curves,instead, I draw a strainght line between the points (curves are not very suitable for mobile 3D applications – a good designer knows how to use polygons instead). But if you draw “free-hand” on inkscape, it will create lots of very small curves that when rendered as straight lines, show the same effect as the curves! Dont belive me? just look at the pictures!

PS: Why is it getting so hard to handle pictures in wordpress?