Undercode

After deciding that I was going to enter the Ludum Dare #16, despiste the almost completly lack of time I`d have to work on the weekend, I was able to finish my entry, somehow. Of course, it didn`t turned out like I wanted it to be, most because of the lack of time, but also because I hadn`t really a definite set goal until the last hours.

Deciding to go with javascript was a lifesaver. At first I wanted to write my game with Python and PyGame, but I`d end up spending too much time on rendering and UI implementation, and with javascript that was already hard-coded into the browser for me, so all that`d be left was to write the game logic. Of course, javascript has its issues, like you`re not guaranted fully compatibility between browsers (even with the standard ones, something may behave oddly), and that`s what made me cut that M$ IEerie from the list of supported browser before I even started writing a line of code.

—the concept—

As you see, I think with stories. At first, I was going for a Turn-Based Strategy game with some dungeon crawling, however, since I couldn’t spend too much time working on a fully fledged procedural dungeon building algorithm, I went with the easier maze generation. Yeah, I could’ve just ported the algorithm I’ve written for Underground Tower, but it’s not really done, and there’s lots of issues there I hadn’t the time to address yet.

The player objective would be to collect memories and uncover the game’s story (which I still haven’t thought of besides that introduction up there). While exploring the maze of consciousness the player would gradually fade out by the sweet lies that lies at each one of the walls of the labyrinth, eating away any “silly” try to look at the “real” world. Therefore, collectable reasonings for staying alive would be found lying around the place.

The memories where when the story of the game would come, but I haven’t had the time to code this part. Not that it would be difficult to code the part of collecting memories (it was just a matter of inheriting the cCollectable class), but to arrange it to make a good story would.

It all could’ve work… if only I haven’t tomorrow’s trip planned.

Concept art for Lucy, the bestowal of light (?)

—the goodies—

That said, there were some good parts about this game. First, the wonders of javascript prototyping. I was afraid to don’t even finish my entry, but I was able to accomplish a fair amount of work without really having a gaming library (mine isn’t complete and it hasn’t much useful things for games right now). Kudos for the Prototype and Scriptaculous libraries for making my life easier too, working with pure javascript is not that fun, must I say, but these libraries make your life a heck easier.

I’ve also learned to write a procedural maze generator using Depth-First Search algorithm. It was quite fun, easy and quick to implement, actually, and it works neat. I think I couldn’t ask for more, could I?

Surprisingly, I had time to sketch a main menu background and a javascript motivational. I wanted to color the motivational, but I’m dog slow at this and don’t have a tablet. So… yeah, it’d take me ages D:

Last, but not least, I had quite fun participating. Even with all the swearing while I was shopping and looking at the clock, seeing I was wasting a precious, precious time. Well, I wish I spent more time chatting with peoples on IRC and so, I haven’t really talked on IRC, I guess.

—the baddies—

Well, now to the part that really matters: what went wrong.

• Lack of time (and this must come first, as I planned a game without the proper time to implement it)
• Light handling on the maze has a bug which won’t fade the illuminated cells if they can’t be reached by the player’s light radius.
• Didn’t had the time to implement things I wanted, like the story and the auto-explorers (whom could be cast to search for something)
• Points are meaningless when they don’t mean anything in game.
• No sounds and music whatsoever. I’d want to put a suspenseful music together with the story, and maybe some footsteps sound. But haven’t time for neither.
• Lack of gameplay and difficult progression, since I haven’t time to test any other than “Does it works? Fine, submission where?”
• Things takes so long to load, and there’s no preloader for images. Minifying the javascript and putting everything on a single source file would solve this, though.

—the conclusion—

While I have other projects to work with (RED -spider lily- and some libraries), I think I’ll work on this game first. Either because it’s simpler and shouldn’t take me too long to finish, and because working on it I can work on my Lily library at the same time. And I’m thinking about porting RED -spider lily- to web, instead of continue on Python. But that will depend on some design issues I still have to address.

Some feedback on the game would be really nice :3

So, I just commited the first version of PySiGal to Google Code. You guys can take a look at the project here:
http://code.google.com/p/pysigal/

There’s not much to it, yet.

• Basic screen management using state machine.
• Basic wrapper around pygame’s display to handle small updates on screen.
• Basic sprite and sprite group class with z-ordering for drawing sprites in layers.
• Basic image manipulation functions like scale, crop and tile, using caching algorithm to improve performance.
• Basic packaging object.
• Input wrapper around pygame events.

That’s all to it for now, but I’ll start working on some transitions and a SFont/Font manager module.

I started writing an high-level abstraction of PyGame, named PySiGal (Python Simple Game Library). I like the sound of it, remembers me of Psycho

Anyways, it’s aimed to simplificate game creation with PyGame and also reduces time to code something and make it a bit more cleaner, even when you have to rush things like in PyWeek.

The library will probably be constituited of:

• A screen management object, that will use state machines to control screens that are drawn and transitions used in-between.
• An abstraction of PyGame’s screen, in order to provide better performance with software rendering. It’ll handle updates in the screen on it’s own, probably using some lazy updating.
• A resource management module using cache techniques to improve performance on expensive operations.
• A archiver module to pack all game data into one single file (it actually has obfuscation, but as the library will be open-source… well, you can always write your own archiver object based on it :D)
• A rewritten sprite module based on PyGame’s sprite module, that implements some caching/optimal operations.
• A wrapper around PyGame’s input module aiming to make it easier to get key, mouse or joystick states.
• Image utility functions, like tile or a better crop that won’t crash if the rect is larger than the surface.
• A widget-based gui that’ll use themes and styles with some lazy rendering so to provide better performance and looks better than Java’s swing applications :D.
• An animation module to handle from simple animations to state-based ones.
• Maybe an abstraction of PyGame’s mixer module. I’m still not sure if I’ll really do this, but I could use things like event handling for musics, so peoples could have a hook to handle when a music finished playing or so.

The first items on this list (up to image utilities) are done or almost done, with just something to rework here or there or a better piece of code I still have to think of. After this is done I’ll get down to work on GUI, that should be the most difficult part of it, actually xD But I have an idea of what I’ll do, though I still have to think about it and find a better design for GUI elements.

What I first though about the GUI was to have a parent desktop object that should handle all widgets that gets added to it. This desktop object should be able to organize the widgets in layers (I’m not sure to use layer objects or just keys in a dictionary yet) and send the corresponding events to its childs, like mouse movements or key handling. It also should be able to handle focus, shortcuts and so on.

I should create a project at google code tomorrow and post code to SVN, but I’ll add docstrings and comments first, also make sure it at least follows some of Python PEPs. Maybe I’ll hack the properties decorator as well, for it works only for Python 2.6+ (I’m using @property.getter/setter), also those hacks should make simpler to create properties and their getter/setters.