KREPES (Kid Radd Existence Project Engine System) Game Framework

[kthakore]

well, since I am working on a game framework, and there is also SDL::Game, I was told to write a "ticket" on what I am doing.

Now just so you are aware, yesh, there is a good chance that through work on KREPES I will be sending patches to SDLPerl.

Anyways, KREPES, Kid Radd Existence Project Engine System, is a very object orientated game framework, done similar to the mechanics of the various 2d systems by Nintendo. Somewhat inspired by the cult classic comic Kid Radd.

A few things first hand: we likely will be using Perl Magick for image rendering. This would make it easier for people to use their particular loved format, without much work on my part to add the code to the Framework. IIRC, this would allow people to run demos using PSD or XCF files. Though, after the imagery is figured out, only then, will we send the data to PerlSDL.

Next, I will prolly be going with an outside sound library. Something that covers most of the issues that will be on the target system. I kind of will likely be looking at a library that allows ogg, flac, WAV, mp3, modplug and midi formats. This still needs more research at the current stage.

The networking, as well, will not be based on SDL, but will use Perl Socket code. This just makes more sense to me. The network code will likely default to using SSH, since this is a game here.

Now the engine itself, will be arranged very similarly to a console... however, it will be a slightly higher level of concept.

There will of course be the near primitive type for the images. This will be turned into other things, such as the "screen" itself, portions of the "OAM" memory, and others.

The "screen" will be based on a generalisation of console hardware. Generally being at least one tilemap, with the ability to do tiled or "object". Object is not being worked to be implemented right now. Tiled, is a one dimensional array of ids to the tilemap being pointed to by this layer. Each tilemap is allowed to ask the OAM to "spawn" sprite data. The sprite data is then destroyed once this tilemap is destroyed. The spawned sprite data in a copy of it, and allows the OAM to have on base time for a certain sprite, and the copy of it on the tilemap to be a copy of it. To make scrolling easier, a screen will have a camera associated with it, that can pan across the screen.

The camera, is merely just a set of coordinates-- x,y tiles and height and width in tiles. There is no reason however that what is shown on the camera ever be on any visual medium btw.

The OAM, largely contains the sprite sheet of a sprite, as well as suggestions for AI, network input, keyboard input, mouse input and joystick input. Physics of the character will also be put here. Also, the hit detection information should also be suggested here. Mind you, these are only suggestions and should be able to be changed when this OAM item is called into memory. This is mostly to reflect how the characters work in the Kid Radd comic. It should be noted that this code merely given signals when a button is pressed from the input and network code. Sort of in a similar style to how libBoost or QT4 handle events.

The tilemap, will just be a series of tile images, arranged in a one dimensional array. This section of code will not allow tiles that are too small, and will fill in accordingly. If a tile is two big, it will default to cropping. However this behaviour should be able to be changable to resize.

Hit detection is a little more complex than most box hit detection. The hit detection system is made up of hit tiles. Hit tiles are one dimensional arrays of "pixels" that call events elsewhere in the code, with 0 meaning noop. Hit tiles are recommended to be the same dimension as the normal tiles. The hit tiles are then arranged in a one dimensional array, to correspond with a screen. Some basic functions would be: Stop Left. Stop Right. Stop Up. Stop Down. Hurt. Heal. These of course could be combined in a pixel. In the case where slopes are used in a level, it is suggested that the tile map is copied and converted into the hit detection area, and modified that way.

Input will likely be a section of code that continually checks for input, and sends input events to the areas that need it.

Networking is a weird section of code. It is rather hard to abstract it into MVC. So it will act as sort of its own device. Input can be requested from it. Output can be send onto it. I will try to have it run RSA by default, but the user likely will be able to do it via cleartext if they so desire to do so. Not sure why.

Sound I really have not research this one btw. However, I would likely have the user set up how many sounds can be outputted. Say, two music channels and two sound effects channels, or something. There would then be a buffer that could have sounds put into. Then ran as they can be. Buffer underflow would not really be an issue, as sound would just stop as a default behaviour. I may allow them to tell certain sounds/playlists are to be looped. Buffer overflow will be an issue defining where the developer has told the game to play a list of sounds that has caused the game to become annoying. This is a game design issue, and not an engine issue. Any attempt to curb this, will likely only be bug filled, and annoy developers. WAVs are acceptable, but the library will try to cache them as FLAC if possible. WAVs are suggest only for development use. The WAV cache system will largely be SHA based, checking if the WAV being given matched what we put into the cache. If not, recacheing it, if so, just playing the entry in the cache. This also does not allow a developer an excuse for distributing bulky WAVs, when they could just grab the FLACs cached for them.

Another component here, is I will be working on a very competent logging system. Generally any time anything is done in the code a message should be sent t the logging system. Setting flags can modify the logging level of the system. In the case something is not to be logged, the instruction to log it, will mostly equate to a NOOP.

The idea of this framework, is that you can drop a character into the system, and have him usable in most games that make use of the system. The system itself, is similar to Nintendo Hardware, however can be extended and modified in manners than you cannot do on a GBA, NDS, NES or SNES. With logical areas being the similar, OAM, tilemap, screen, input, sound and network. Except these components will be slightly more high level than their console counter parts.

This system is to be designed so that it is possible to act as a game server, even on a system that is entirely headless. It should be runnable without a GUI present if it does not make use of any GUI features.

There are no plans for 3d in this system at the current stage.