togoGame Dev

2008-11-29T17:31:00.000-08:00

Been working on a new concept:

Here's a quick description of the theme:

"It's hard to be a dad--especially when your no-good family has driven you into the depths of alcoholic rage! Use your brawn and wit to remind your wife and child who's boss around the house, and with a few well-placed back-hands, some broken furniture, and a little luck, you might just be able to bring this house in order--and regain a little dignity in the process!"

The real point of this is to make a small game using Box2d for the physics and O2d for the graphics. Both are fast and great bits of software, as far as I'm concerned.

The player would look something like this:

Here you can see that Box2d is up and running.

Even added a 'wife':

Here's an example weapon:

the protoDbMgr is almost here...

2008-02-22T20:56:00.000-08:00

The 'protoDbMgr', the latest concoction, is capable of saving the basic attributes of Sprite instances via a combination of a shelf for storing complex data conveniently and a buzhug database for sorting data in large populations. The buzhug db, however is limited as far as to what types of data can be stored.

To 'convert' the Sprite instance into a format that can be inserted into the database, the shadowSprite class copies all the attributes of interest from a Sprite. The dbMgr can then take those formatted attributes and insert them into the database. Similarly, records can be read by shadowSprites and then the data may be initialized into a new Sprite (or other class) instance.

The shelf is responsible at this point for retaining the id numbers of the objects as the value to the game_id key of the object. The databases can be nested, so it is important to have a global dict of the ids of the objects (though this is not fully implemented yet).

So far, the protoDbMgr is capable of:

creating unique databases, referenced by a name (and path)
adding, updating, sorting, and deleting of records
storing and retrieving groups of Sprites (can filter arbitrarily)

Eventually, the dbMgr will hopefully be able to store and load complex Sprites, with attached children, etc. This is why each db has its own directory but there is only one rec_ids dict. That way, all the objects can be accounted for and accessed easily, but at the same time be nested using record fields that reference other dbs.

Ahhh, well that's nice...

2008-02-15T21:17:00.000-08:00

Thanks to shang, the intrepid brains behind Opioid2D, the halos around alpha pixels are now gone.

The current flaming ring to jump through is the finalization of the base objects and map structure, with an emphasis on data persistence and ease of to-and-fro between memory and disk. Not very exciting, but very important.

May We All Have a Valentine...

2008-02-03T19:47:00.001-08:00

Things that have changed since the last post:

Migrating to double the resolution for objects and ents (note face and gun)
Implemented basic map traversal functionality
Added 30+ real-world weapons (will increase substantially)
Started implementation of entity attributes, skills and stats
Some basic animations added
Console improved and code cleaned-up (slightly)
Began implementation of mini-gui (test-phase)

The code can be downloaded here. Note: you must have python, pygame, and Opioid2D to use this.

Run main.py to start. The keys are as follows by state:

NormMode:

W,A,S,D - move/face the current map obj
Numpad 1-9 - move camera
Numpad 5 - center camera on current obj
Mouse Buttons - set to test some actions
F1 - Toggle ConsoleMode
1-8 - different weapons by category

ConsoleMode:

most regular keys - write to console
Enter - activate console command
Enter (blank) - last console command
tab - clear console text
Numpad 1-9 - move camera
Numpad 5 - center camera on current obj
mousewheel - scale camera

Escape exits the program at all times. The console executes from the scene's scope and 'ent' is a shortcut to the map.obj, 'map', and 'cam' for the camera.

The talking functionality has a few interesting features. Try 'ent.talk_string('your own text') and the mouth of the ent will open for each vowel in a word, with pauses in between. Eventually I'd like to combine this with speech for basic communication.

Also, weapons have been added, although they are simple, non-animated, and based on photographs.

In an ent's hands, they don't look so bad, especially considering how 'detailed' the ent is.

EFX + Console

2008-01-03T19:43:00.000-08:00

Here is the console triggering an effect, which is signified by a type ('fart'), which leads to a class (fartEffect) that is then bound to the object until the termination of the effect. Later, these effects will be incorporated into more complicated actions, such as dying.

In the case of the little camp fire next to the highly detailed man, it is a special mapObj class that has its own functions to trigger the effects. The fire can be lit using campfire.light() and then put out with campfire.snuff(). Furthermore, the img of the logs changes, so the embers glow when lit, and are dark when not.

All I need to do now is add a coat-hanger you can bend straight, add an inventory, and fill it with marshmallows...

Early EFX implementation (custom class)

2008-01-02T16:12:00.000-08:00

I implemented an effects class that utilizes Sprites as its basis. This allows for the efx to be attached_to(objs), thus allowing for the efx to be layered appropriately within the map structure:

Here is an example of a 'drunk' state, with booze bubbles (or whatever).

This effect hopes to indicate when an ent takes damage (from bullets).

And finally, this is a (lame) burning effect (need to add the smoke!).

PS: ...hey, this isn't smoke!!

Combined Test (menu & map)

2007-12-30T19:34:00.000-08:00

The map, gui, and text elements have their own layers, which are ordered accordingly. The console has also been implemented, trapping input using state-specific event handling and executing from the Scene's scope.

Unfortunately, the gui adds overhead that makes it too costly to order the tiles using layers, so the ordering glitch is back.

early GUI implementation

2007-12-28T20:43:00.000-08:00

2007-12-25T23:04:00.001-08:00

2007-12-25T20:26:00.000-08:00

Here is a 100% view of the map using the layer-per-tile scheme, and is consequentially running quite slow. The tiles are, however, ordered correctly so this is still a good prototype.

The tiles and objects are initialized using images as maps that are then converted using a 'filter' (or dict) that generates an object from the data in the image by translating the color at a particular location (x,y) on the bitmap into a corresponding object on the map. For example:

GRASS_TILES = [

'gfx/tiles/Lgrass1.png',
'gfx/tiles/Lgrass2.png',
'gfx/tiles/Lgrass3.png',
'gfx/tiles/Lgrass4.png' ]

CEMENT_TILES = [

'gfx/tiles/Lcement1b.png',
'gfx/tiles/Lcement2b.png',
'gfx/tiles/Lcement3b.png',
'gfx/tiles/Lcement4b.png',
'gfx/tiles/Lcement5b.png' ]

Are our images to be randomized for each tile type. This can also be a single image in a list: [ 'img' ]. These are then assigned to color values in the bitmap like so:

FILE_MAP_FILTER = {

16777215:
65280:
'dflt':

CEMENT_TILES,
GRASS_TILES,
['gfx/tiles/Ltile01.png']

}

Note: the function uses 'dflt' when the color is not in the dict, but also not = 0. (x,y) positions with a value of '0' are not assigned a tile, and are not valid keys for tile lookup.

Here is the base tile map for the map screen shown above:

The green pixels correspond to GRASS_TILES, the white to CEMENT_TILES, while the red and yellow pixels are not registered so they generate tiles from 'dflt'.

Next, objects are generated using a similar methodology. The dicts that store them are more complicated to allow for state changes, direction, and other categorizations. Simply put, in this case they use the values returned from pygame.surfarray.array2d(surf):

16711680 :wallNW
16776960 :wallNE
65280 :wallSE
255 :wallSW

This is the object map:

In this early stage as a quick fix, I used a single-wall-per-tile functionality. If you look carefully, you can see that the walls aren't indicated in the way they are seen on the map (see below). The walls are put in between two tiles, so they can be attached to either one. If you were to program it so that the wall objs were linked to the interior tiles, convex corners require a single tile to contain two walls (one for each side of the corner). To work around this, I simply placed the walls on the outside, only using tiles inside for the convex corner (thus reversing it).

The intention is to later include the functionality needed to have interiors with mapTiles that can accommodate more than one wall object, and can be arbitrarily occupied by multiple objects of different types, and exhibit other unique behaviors.

Here is an example of the map zoomed out a bit:

*Note the artifacts on the screen to the right of the bldg... a problem with Opioid2D (Alpha 6 3) when scaling and moving objects. Seems to be related to edges of bounding rects and alpha pixels.

The tiles are composed of images that are aligned so that the center is located appropriately:

The wall tiles are then put on top:

These are only test images, so they are fairly bland. The illusion of depth functions, though, so at least I know the map's working correctly (but slow).

2007-12-22T00:14:00.000-08:00

This is the way the map has been rendering without using separate layers for each map tile. They seem to shift somehow in sets along the y axis, moving one tile over on the x axis...

Notice the FPS in this case is 83, a good number, which illustrates the utility of Opioid2D (when this problem is resolved).

Early Stages...

2007-12-21T03:10:00.000-08:00

This is an early representation of the basis of the map system. Notice the FPS is only 40 (which is the minimum for the game engine), a result of the fact that the tiles won't order correctly unless you give each of them their own layer.

Welcome!

2007-12-19T16:04:00.000-08:00

Welcome to the togoAlpha project page.

I have been working at a snail's pace on this project from the beginning of time (or at least it feels that way). Originally a set of utilities written in qBasic for font and vector object creation, I have been using Python since 2003 to code this perhaps-a-little-to-ambitious game. While the specifics have changed over time, the overall goals have remained constant:

A large, persistent world.
High interactivity between player, NPCs, and environment.
Adaptive AI that counteracts player behavior.
Extensibility, flexibility, and portability.
User modifiable and amendable content.

"Well", you may say to yourself, "that sound like what any game would want to have!"

"Correct!" I would say.

Being the type of person who was basically nursed from infancy on video games, from pong and asteriods to Final Fantasy VII and Halflife, I've been a witness to many different concepts and approaches to game design. Nearly all games, though, lack the ability for the user to alter the game they have spent $50 on and gotten bored of in a month. Operation Flashpoint by Codemasters managed to avoid this problem by allowing users to create missions, add content, and otherwise tweak the game to their liking. Needless to say, the hundreds of hours I've spent playing that game weren't spent battling through the (lame) campaigns!

So, in the hopes of both paying homage to the oldies, such as Jagged Alliance and Syndicate, as well as newer games, eg Grand Theft Auto and Metal Gear, I've settled on a general concept:

An isometric map (such as that in Jagged Alliance)
Large, persistent world (eg Ultima VII or GTA)
Assignable behavior chains (FFXII)
Customizable player/NPC avatars (Ultima Online)
Complex plot/behavior mechanics (Covert Action)
Randomized maps, objects, plots (to improve replay value)
"Plus much more..."

Recently, I have scrapped the original togoAPI (emptyRun, blankRun, etc) and subsequent versions of the self-authored game engine in favor of a third-party engine, Opioid2D, that is far superior to anything I could come up with at this point. Also, I've been unable to focus on content other than for testing purposes while developing the engine, as it is a very time consuming process. Thankfully, the Opioid2D engine has much of the functionality that I'd been trying to code myself (with some exceptions).

--Zorbicon

Old ScreenShots...

2007-12-18T00:34:00.000-08:00

This was 'bomberMode' using emptyRun, an old engine I made that is just a game loop with helpful functions in its local namespace.

This is from a missle command style prototype.

This was my favorite, 'drivingMode,' which has sound and the car can be moved around. The projectiles used vector velocities and were part of a collision system with pygame.Rect's.

'Cannon Mode' used parabolic paths for projectiles and had gravity and velocity parameters. The boxes explode and distribute debris (particle EFX). This was a more advanced prototype of the features tested in the previous examples.

specialTest or ssMan was the culmination of the efforts on the togo engine. Animations, collision detection, physics, behavior sequences, etc.