Back - 21/06/2008, 01:48Hi! I've been extremely busy writing thesis.
Our (Hugo and mine) thesis is finally written, corrected, re-written and approved.
Our thesis is called "Development of framework and proof of concept for the Nintendo DS Console". It aims to make developing games for the said console easier with alternative tools (DevKitPRO, DevKitARM, libnds, libwifi, libfat) and using exclusively Free (as in Freedom) Software. And the framework itself will be, of course, Free Software.
I had a lot of fun doing the degree project and I hope to continue working on it after I get my degree. It was a lot of hard work, and explaining it wasn't that simple, but I hope (and I've been told) that the thesis is easy to understand. I will publish it after our professional exam's done, and if I find enough time, I'll translate it to English. (If you want an advance copy in PDF, e-mail me ;) )
Mainly, this is what we did:
- Get MotorJ working on the Nintendo DS
- Write a class to load OGGs as background music
- Write a class to load WAVE files as sound effects
- Write a class to use as a Collision Tree, so collisions between objects can be carried out in an ordely way
- Fix a nasty bug in one of MotorJ's collision detecton algorithms
- Write a Blender->NDS Display List exporter
- Write a class to load the NDS Display Lists and use them to animate a biped character
- Standarize the MotorJ API a bit
- Write a small scenario editor using MotorJ for the PC (heh)
- Write a couple of classes to make networking stuff easier
- Finally, build a concept proof using all the aformentioned developments
We stopped developing the concept proof when we started writing the thesis, so we're going to finish it in the next few days.
Developing a multiplayer game, even if it's a very simple one with little to no authentication, down to the socket level, is a very interesting task. Defining how players interact with each other is not obvious: How do you get everyone to see the same world state at the same time? Which data should be sent over the network? Player controls? Player speed? Everything but the kitchen sink? How often? How should the game interpolate the other players' positions between each update? How do you get two objects to collide with each other and react in the same way, in a distributed world?
One of the issues in developing for the Nintendo DS is processor speed. Most of the previous questions are easily solved if you have a Client/Server architecture. Well, when we're talking about the Nintendo DS, a C/S architecture means getting one console to do a tremendous amount of work, something that will very probably slow down the game. So I decided to distribute the task more evenly: each console, except for player 1, cares only for its player and more or less trusts the updates sent by the other consoles, pretty much the way old games (like Descent, Doom and others) worked. Only one console does more work than the others: player 1's console will decide when the game starts and when it ends, and where some in-game objects appear. Just a bit more of work, but nothing serious.
Another idea could be setting a computer to act as a server and the DS consoles to work as pretty much "dumb" terminals, but I really wanted people to be able to play without requiring a computer.
In my next blog posts, I'll try to explain my findings, both here and in the lab's blog. From now on, I'll probably post most messages in English. I've made a few friends over the Internet from far places who might actually be
bored interested enough to read this blog.
I also changed my site's theme to something that will hopefully not burn your eyes :P
< Back to blog