(Receive email notifications)
Hc Svnt Dracones!?
Yes, I know it's latin for "Here Be Dragons" but it's also the name of a furry-themes role-playing game currently on it's second (MUCH improved) edition, but that has a character creation system that involves some number-juggling at times as you start with an amount of XP to spend on a broad sheet of bonuses, and juggling the numbers can be taxing even for the math-inclined.
So... I re-implemented it more like a video-game skill tree, though without any deeper details of what the various parts mean yet.
X toggles rectangles
Left/Right decrease/increase a given row
Up/Down switches between rows
There's quite a few more sections I need to implement, and taken by itself this one 'screen' won't make much sense I admit; I do plan to implement most/all of HSD character creation on this tool as I have time.
Entirely back-end changes in preparation for expanding to more 'pages' to handle the other components of the character sheet, and eventually handling multiple character sheets in a single cart.
(Receive email notifications)
So this started on this thread by weeble but I ended up rather... running away with the code idea and overhauling it drastically.
While I've resumed working w/ Weeble on this in his original thread, I'm keeping this thread updated as well as I make changes.
Also with V2.1 I've moved the various data tables needed outside of the sprite sheet, copied up from page 3 which is the one tiles are rendered into in-game, so all of the first two sprite pages are available for graphics as is the first two rows and change of page #2.
With V2.2 I've added the initial code for clipping regions, to avoid redrawing the entire screen every frame. This is a MASSIVE speedup, pushing CPU usage outside of screen-transition periods down to 5% CPU at 60fps in most cases. I'm working on a '16x16 bitfield' based solution that will instead re-render the screen in regions as small as 8x8 pixels per frame, allowing for multiple moving objects that way.
I've also cut the CPU used for baking the tile graphics in half from ~2.5 frames at 60fps to ~1.3 frames at 60fps with this release, while the token count and overall codesize has actually gone down.
Finally, the game picks a random room in the entire 16x16 grid to start you in, so you get different areas of the maze each time you restart the cart. So hit Ctrl+R a few times to see all the various biomes.
As a caveat I have removed the 'biome viewer' in this version for now, as I'm redesigning the interface to be a general-purpose editor for the maze itself, including setting biomes on the maze and editing individual biomes directly.
As of V2.3 I've integrated newer 'cavern generation' code that weeble came up with, to avoid blocking paths and allowing for much denser 'crazyness' to occur, as well as my 'context sensitive dithering' code which makes the transition tiles look much more alive and distinct now.
I'm working on some additional cavern smoothing functions to retain the 'crowded' feel without having quite so many dead side-passages at times, and adding a caching layer for the more expensive parts of the room-generation, to allow much of it to be generated in the background as you walk around a room to get to the next exit.
V2.4 adds a fourth unique room design for some biomes, one with much deeper, winding passages and a crowded feel.
V2.5 adds a MASSIVE speedup to the bake_tiles function by calculating the 'masked' tiles a full 32-bit row of 8 pixels at a time. So one fourth as many calculations in exchange for a bit of bit-shifting to load/save the values, but overall it's a HUGE win, including on token-count! Only 2814 tokens current! :D As a note, the masking colors are now 2/3, 4, 5, and 6/7, with values 0, 1, and all those above 7 MUST be avoided in the masks now.
As an interim release, V2.5-caching includes a further sped up tile-rendering codebase which is also moving some data from peek/poke memory to lua memory, taking up roughly 128k of the 1MB available with pre-rendering graphics tiles organized for faster rendering. This transition is freeing up enough speed that I am preparing to remove the 'biome' approach and allow direct per-maze-room assignment of walls, floors, and borders (including palettes) to simplify world painting. The trade-off is worlds will take ~768 bytes of sprite/map memory to store instead of ~512 bytes as they are now.
With V3.0 I've completely removed the concept of 'biomes' from the codebase; the walls, floors, borders, and their respective palette choice can be assigned fully independently per-room now. I've not yet modified the map to show off this feature, though as a side-effect screen-transitions are even faster now as the engine only generates those tiles which are absolutely required.
Also new is a full fledged built-in editor allowing you to modify the maze design with a realtime view of the room in question when customizing the palette/textures for each component. Note that editing the actual palettes used by the tiles is done by editing the lower-left corner (sprite tiles 240 and 241) with the upper row being palettes 0-15 and the lower row being palettes 16-31.
To access the editor go into the in-cartridge menu (P by default) and select the appropriate menu item; likewise to exit the editor choose to either discard or save changes in the menu.
I'm still working to improve the rendering system, but felt releasing this version with a fully functional editor built-in is a valid point where games could easily be made with this engine.
(Receive email notifications)
I have further ideas to add to this game and plenty of space/resources left to do so, but it is 'feature complete' to release as a Cartridge instead of a WIP at this point. Remaining ideas:
- More options; missile swarm sizes, enemy types to enable/disable, etc
- Attraction/Arcade Demo mode during the "title card"
- Improve the 'how to play' panel further
- More varieties of enemies
This is a 60FPS cart, vaguely based on the '16 gifs' SCHMUP in overall structure but written in a very different style using sub-pixel accuracy (including movement and projectiles) and circle-based collision detection instead of rectangles. The 'drunk missiles' are still using the same basic 'linear movement + circular spiral' pathing, but there's a lot more variety going on with spiral size, etc.
Gameplay is fairly trivial, hold down Z to fire, shoot down missiles and avoid running into them. Like many SCHMUP's only the 'core' of your fighter can be hit. The color shifts from blue -> green -> yellow -> red -> dead, and your projectiles match your current health status color.
X button starts a new game if dead, to avoid having to bring up the Pause menu every time, and if anyone has any further suggestions I'm open to hear them!
- Persistent high-score
- Basic 'manual' panel
- Initial 'options' screen allowing you to disable the starfield if you find it too distracting
- Much improved collision detection
V1.2 is mostly bug fixes
- Converted from 'integer sub-pixel' to using the 16:16 fixed-point math PICO-8 already supports
- Fixed the 'hold down for an easier game' exploit by blocking movement inputs instead of only capping position
V1.3 adds music and sound
- Better 'death' explosion
- A simple projectile firing sound tuned to not be annoying to have running near-constantly
- A per-hit 'splat' as your shield weakens
- A longer and randomly generated 'explosion' noise when you die
V1.4 is mostly polish and overhaul
- Difficulty is raised as a result of more even screen coverage by missile swarms
- Credits panel added to 'attract' mode
- Code has been organized better
V1.5 is final polish and the last release in the "1.x" line
- Minimized the music, it was overly verbose and could be reduced to half as many patterns used
- A few minor individual-pixel touchups on the title graphic