So LOWREZJAM 2020 comes to an end... I finally submitted a playable project but with a lot of unfinished features. For a start there is no AI, In the remaining time I would not have been able to add a proper "smart" AI so I prefered to leave the game as 2p game only (or for those wanting to challenge themselves balttle yourself!). Sound is totally missing... I will be welcoming sfx and track contributions... that area is not my best. You can check it also in it's itch.io page
At this resolution (mode 3, 64x64) and with the constraints in time for the JAM I "abandoned" that cart and started focusing on rewriting things on a 128x128 more organized cart (keeping all the good things in this one) so expect to keep hearing from Fantasy Tactics HD ;)
This is a simplified "tactics" game (Final Fantasy Tactics, Tactics Ogre and so many more...). There's two opposing sides, The Kingdom and The Undead and the objective is wipe out all the opposing forces. Every turn a unit can MOVE and perform an ACTION.
Activate a unit with ❎ and it's move area will be displayed in RED. That area is calculated based on the MOVE trait of the unit but considering units cannot go trhough other units, rocks or trees, that you cannot end your move in water (but you can jump across 1 tile of water) and that you cannot jump up more than a height difference of 2. Press ❎ again to select where you want to move or 🅾️ to cancel the action and release the unit.
Press ❎ on an empty tile to get the TURN MENU that helps you find units that have not yet moved and allows also to end the turn inmediately
After moving, the ACTION MENU will show up with the available actions. After selecting ATTACK or to cast a SPELL a TARGETTING AREA will be displayed in GREEN. Any potential target in the area is tracked and you can iterate through them with the cursor keys to pick the target you want. If the unit is carrying POTIONS and it has lost some HIT POINTS it can drink one of them to restore up to 3HP. SUPPORT spells automatically succeed and apply to the targetted unit. You can cancel your orders with 🅾️.
ATTACK and OFFENSIVE spells initiate a combat roll. Combat is DICE based. The attacking and the defending units roll a number of dice and depending on the results the combat is resolved.
- BASIC ATTACK: The roll is ATTACK vs DEFENSE traits. HIT symbol is SWORD, DEF symbol is SHIELD
- SPELL ATTACK: The roll is "SPELL LEVEL" vs DEFENSE trait. HIT symbol depends on the spell, DEF symbol is SHIELD
The combat result is the defending unit looses as many HIT POINTS as the count of HIT minus DEF symbols
Archers: Fast moving, attack at a distance, carry a potion
Halberdiers: Sturdy and with a long reach, carry a potion
Axemen: Strong attack, carry a potion
Priests: Weak attack, SUPPORT spell HEAL (+4HP)
Wizards: Weak attack and defense, OFFENSIVE spell FIREBALL (LV 4, HIT symbol FIREBALL)
Lancers: Avg attack, low defense, long reach
Swordmen: Avg attack and defense
Reapers: Strong attack, low defense
Necromancer: Low attack and defense, SUPPORT spell MEND (+4HP)
Lych: Sturdy wraith with strong attack and defense, OFFENSIVE spell MIASMA (LV 4, HIT symbol SKULL)
I am working on a project for URL LOWREZJAM 2020 and I think it is time to present it here to get some comments maybe.
The cart is quite far from being playable but as there's been some expectation around it I've dediced to keep the wip cart here so ppl can comment and try it. Don't expect too much out of it, still very early
Updated with a bugfix... using potions broke unit release
It's going to be a "tactics" like game (tactics ogre, final fantasy tactics...). Still plenty of work to do and not sure if I will be able to put everything up for the Jam but for sure I am gonna keep working on this to a point it becomes a playable game. For now working on 2 carts... the game itself and the editor and probably I will release the editor/isometric renderer on it's own cart in case someone wants to experiment with it once it's kind of "complete"
Project is in MODE 3 as the jam is 64x64 and I am using some odd sizes around (my general sprite/object box is 10x16) even though I am adding full support to custom sprite sizes for the renderer itself.
At the current version it moves 20x20 tiles at 85-90% cpu at 60FPS but I think I can bring that down a bit... There's a few optimizations like truncate tile rendering when outside the clipping boundaries (some hidden blitting is already in place but need to push that a bit further)
Some images on how it has evolved to the current state:
Hope you like the idea, comments appreciated.
I've tried to upload several times a new version for a cart but seems something breaks that cart in particular... everything runs fine locally (windows machine) but the uploade version gives a syntax error in an odd place (inside one px9 generated string)
I saved the cart a few times but results are the same... any idea on the reason and a potential fix?
Probably everyone has one of these... sharing in case you don't and need a quick wrapper around the mouse support.
The library implements an OOP like MOUSE object that supports 2 buttons and provides the following methods:
- enable() : Enables mouse suport
- disable() : Disables mouse support
- pressed(<num>) : true/false if button number <num> is pressed in current frame
- clicked(<num>) : true/false if button number <num> is pressed in current frame but was not in the previous
- released(<num>) : true/false if button number <num> is not pressed but was in the previous frame
- inside(minx,miny,maxx,maxy) : true/false if mouse is inside the defined rect boundaries
Would be quite easy to extend, mouse cursor can be set to any spritesheet index and would be easy to handle animated cursors, bigger cursors and such...
The demo cart shows how it behaves... pressing buttons changes background color, clicking and releasing draw some points on the screen (in green hues for btn 1, blue hues for btn 2.. brighter for click, darker for release)
Took me a while to debug and identify why this was happening...
I was taking advantage of RESET to clear clipping and palette and as a side-effect RND() started to misbehave returning always the exact same number. I guess that RESET also sets a fixed srand seed and that's why the pseudo-randoms go stale... Probably worth documenting that RESET also does that or if this was unintentional fix it...
Will post here my experiments with particle effects...
Experiment 1: Fireworks... basic explosions
version 1: very basic approach
version 2: added gravity pull and callback update/draw for particles to operate multiple particle types (f.e. rocket and spark in the test)
Experiment 2: Additive blit particle fire
version 2: Supporting sprite-based blendop palettes (for now only partial additive palette included), next goal blit optimization
version 3: PEEK/POKE BLIT without great results... per-pixel blendops still kill it, updated color and added some toying controls
While starting work on my little deflektor project I decided to have classic 7 segment led style numbers, my first iteration (the one currently in the game...) is based on sprites but I wanted something a bit more versatile. This is a basic line drawing small library to handle 7 segment led like any digit length display. It should be fairly easy to define a text set and draw 7 segment text desplays (just need a table with the segment mapping for every letter and put up a wrapping function that receives a text and not a number)
It supports background displaying of segments ("off" segments), color configuration and segment width configuration. The cart includes the library and a very basic demo on what it can do
I might be working on reducing token size a bit (library itself is around 300 tokens) and I think there's some salvageable space there, but don't count on it for now
Hope it helps someone out needing a 7 segment style display
I've invested some time working on a demake for one of my favourite games from the 8-bit era, Deflektor (by Costa Panayi). Your goal is to guide a laser to the receiver on each of the levels, access to it is blocked until you destroy all pods on the level. Laser overloads when it hits mines or if the emitter gets feedback.
HOW TO PLAY (you can go through this tutorial in the game itself)
- 1 MORE LEVEL (now totalling 8)
- 1 MORE LEVELS (now totalling 7)
- 2 MORE LEVELS (now totalling 6)
- ADDED safety pre-check so levels don't start on full-reflection or overload status
- FIXED tutorial can be run multiple times
- FIXED bug duplicating player cursor entity...
- FIXEX tutorial scrambled if you play before running it
- Massive rewrite (almost 80% of it is new...)
- ADDED a few more levels
- REMOVED editor mode... it is now it's own cart... was too big
- ADDED Tutorial, Intro screen, proper game over and End Game sequence
- FIXED a few nasty reflection bugs for the laser beam
- FIXED bug with negative angle reflections not causing overload
- ADDED some more basic FX
- EDITOR MODE early version (reqs. mouse)
- ADDED laser loading phase at start level/new live
- ADDED end level scoring
- WIP bgmusic (in the cart but not playing, unsure if it will stay)
- FIXED bug in map loading that made optical fiber to crash (main reason to re-release)
- ADDED some basic SFX
- FIXED optical fiber pair coloring
- some minor token salvaging and code clean-up
- FIXED extra greediness in beam capture at mirror centers causing odd reflexions
- FIXED color error on initial rise for the overload meter
- MASSIVE spr sorting to allow for a reasonable leveldata format
- Level is loaded from data (level info will live in 0x1000 to 0x1FFF unused shared map/spr space)
- Crude leveldata persister as a prototype for leveleditor mode (unsure if editor will be a separate cart)
- Optical fiber interaction
- Laser grid scatter interaction
- Level can be completed
- Interaction with the receiver (connected status to end level)
- Removed displaying laser point debugging
- FIXED metal wall reflexion failing for some situations
- Basic intro page
- Beam generation and reflection
- Player movement
- Mirror interaction and auto-rotation
- Beam interaction with mirrors, walls, mines and pods
- Full HUD control
- Crude live / energy / overload management
- Hardcoded level mapping
- MUSIC: title music from the original and maybe a bg loop while playing
- SOUNDS: laser connection sound
- VISUALS & GAMEPLAY:
- live lost sequence
- level transition
- extra detail in end game sequence
- gremlins from the original game... unsure if I will be adding those
- a few more levels... the plan is get around 20-30 levels in place
- CODING: even if I refactored a lot, there's still quite some junk... could be I do some more