Talk:Game development

GCS (Game Creation System)

Something like MegaZeux would be cool. Back in the DOS era it was used by many kids to create games. Maybe with more advanced features, like real graphics, but what counts is the easy-to-understand concept behind it. --193.170.48.146 15:48, 10 October 2007 (EDT)

Yeah, that'd be pretty cool. Or something like Verge, Ika, Sphere, RPGMaker, Ren'Py, etc. I've seen several homegrown OLPC game-maker efforts mentioned on this wiki, like ISIS, Choose Your Own Adventure, Simple Game Library, and Treenimation. Of course, one might argue that the Pygame or EToys toolkits that will be available for the XO are already Game Creation Systems. —Joe 19:44, 10 October 2007 (EDT)

Doom details

So... Someone apparently got Doom running on the XO. I recall also seeing a video of a console emulator on the XO, but it seems to have since been taken down. The framerates seem a little sluggish but still playable. The active screen area is inset quite a bit, presumably for performance reasons. Does anyone have details on the implementation of these things? Was it GTK running on Sugar/Matchbox, or was a custom solution used for performance? —Joe 16:22, 18 March 2007 (EDT)

SDL is OK

Tux Paint uses it.

The rpm files have problems. SDL_mixer drags in Qt via timidity and the KDE sound deamon. Don't bother with SVG, that drags in GNOME!!! I think OLPC is going to hack up some alternate RPMs, but really this is a Fedora problem.

The screen is using 5:6:5 color, which is bad in more ways than I can count. You can see green/magenta banding (posterization) easily on a smooth grey gradient, especially if that gradient is bright and radial like a highlight.

There is a way to do your own swizzle for better quality and bit depth. See this kernel patch for a way to sanely enable it. (without that patch, an ioctl on /dev/fb0 will do the job) Games could look very nice with smooth 18-bit color if this were used.

AlbertCahalan 23:44, 18 March 2007 (EDT)

Whoah, Whoah! what's all this talk of 3d?!?! 3d on the olpc is overkill. I'd stick with 2D only. --> We want to encourage both but definitely the heavy emphasis is on 2D right now. In terms of 3D we need to set a "standard" early so those that do want to pursue it have some direction - Bensawyer

I think for the games, the key is to code them very well - modularly and very well structured, with clear code and comments (localization might be a problem here).

Code them in such a way that the game specific code is very slim, and hte core code extensible. My recommendation on this is to mainly code just what you need for the game itself, for simplicity sake, and for the kids' sake - let them do more than just stick pieces together.

I'd also do an isometric engine, btw. -- It's in our spec! -- Bensawyer

(From above - "Don't bother with SVG") - ah, hell no!! SVG is great. I'd implement the mobile subset - it isn't that hard to implement badly (proper impls might take a while...), and allows for awesome vector graphics. If not svg, some other vector format is almost mandatory.... Also a vector editor. I know there was soem discussion of inkscape, though it's a bit heavyweight, and cutting it down would be difficult - the code is fairly hacked together and non-modular. It could be 1/2 the size if rewritten, better if it was rewritten in a language other than c++... It's about 300KLoc, btw.

Michael Sloan, 22 March 2007

Game control

see Talk:Games as learning motivation#Game control --Fasten 07:32, 22 December 2007 (EST)