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.
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.
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.
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...
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.