Revontuli

I have systems in place to create different types of enemies and non-enemy objects, although how they'll ultimately behave is now more a matter of game design than software design - more art than science, really. That takes a while, in the form of sketching, prototyping, and daydreaming, but I still have plenty of straightforward coding stuff to do. I've currently designated bank 7 as the "Menu" bank, where the title screen, control options, ending sequence, and pretty much anything involving text will go. I could give the bank its own graphics block - not absolutely necessary as I currently have the text in the shared bank, but the temptation to add a ton of graphical flourishes is there I'll see how much space I have left once I get the necessary stuff in. I'm adding the option to change your controller setup - whether button 1 or 2 is the jump or attack button, as well as the option for a single button controller. The 1 button setup uses the button to jump and [down + button] to attack. Since your main attack is a fast downward swoop, I'm hoping using the button for the two actions won't clash much in practice for folks. I actually prefer it when playing on physical hardware. Current Bank ROM usage (with tentative plans for currently unused banks: 8780 bytes of ROM space left in the main area of bank 1. <-Main Game Logic 14595 bytes of ROM space left in the main area of bank 2. <-Level Loading and Level Data 0 bytes of ROM space left in the main area of bank 3. <-Main Game "Draw" Section + Level and Enemy Graphics 3098 bytes of ROM space left in DMA hole 0. <-Plotmaps, PlotSprites, etc. for main game loop 4096 bytes of ROM space left in DMA hole 1. 16383 bytes of ROM space left in the main area of bank 4.<- More level data? 16383 bytes of ROM space left in the main area of bank 5.<- Boss graphics and behaviors? 16383 bytes of ROM space left in the main area of bank 6.<- Music and sound data? 15128 bytes of ROM space left in the main area of bank 7. <-Menus, Title Screen, Text screens 7841 bytes of ROM space left in the main area of bank 8. <-Shared Bank (mostly sound + shared graphic block at this point) Very little code duplication in separate banks at this point - I'll likely need to re-use the number and text graphics, since you can only use one graphics block at a time for charsets. The bosses might need some copypasted code for the final draw pass (again, mainly due to wanting a specific graphics block for them), and I'll likely need to copy the level data->RAM routine to bank 4, but it's a simple loop that takes very little space, worth it to get another 15ish kilobytes of level content. I'll see how much more space I'll have in bank 1 as I add more enemy AI, item behaviors, and other elements. I've no doubt I can burn through ~9k, but it doesn't feel claustrophobic yet, and I still have other banks open as of now. If I do use a specific non-shared bank for audio data, I'll want some help on how to loading such into RAM, especially if I commit to using POKEY-compatible audio. I haven't actually touched the extra RAM bank yet, and I have a possible design where I might not need to, but I figure that loading POKEY tracks would be the "killer app" that would justify it. Thanks for everyone's help - this is incredibly fun, but really only possible due to folks sharing their knowledge and tools! I hope posting highlights from my dev diary helps folks a little bit in turn.

It's my first 7800 game with bank switching, too, and I still have a lot to figure out, but it's good to compare notes! I'm glad my notes are helping, although I'm also posting to see if anyone points out any glaring error or inefficiency Having one bank be the "graphics and final plots/drawing" seems to make sense, while having other banks handle the logic. I haven't taken advantage of the RAM bank yet, but it feels like you can store a lot the game state and logic there when you do the final screen drawing. Having a "gosub" bank for operations that aren't as time critical (like level loading - if it takes a few frames to load a level that's usually not a big deal) also seems to make sense. Code re-use at some point is probably inevitable - I want some more ornate bosses, for instance, and that will likely need its own bank - but this seems like a good way to leverage the bank space while avoiding too much redundancy.

I'm curious how the drawscreen/drawwait tempo with the CPU changes (or doesn't) when one decides to use the double buffer. My current multibank setup logic is something like this: Bank 1 - Game Logic, no drawing but a lot of setting x and y of "sprites" to be drawn, goto Bank 2 at the end of calculations Bank 2 - Actually Plot sprites/maps/etc. doublebuffer flip, goto Bank 1 after flipping (Bank2 also has 2 graphics blocks) . . . Bank 8 -(i.e. Shared Bank) with 1 graphic block This setup gives me 3 full graphics blocks when I do want to draw something while having a lot of space for other code on a separate bank. Performance seems ok (for now) and mentally it feels coherent, but if there's an order of operations that would make more sense in terms when the screen is drawn vs. when the CPU is active I would be keen to know

Tile types beyond solid and background! I added in spikes and water - I'm hoping I can get the behaviors for both without adding *too* many more cycles to the block collision response. The details still need a little work, but you can swim and get hurt on the spikes (usually - a few more tests...) I want to play with the exact dynamics, but this is a good test - even graphically being able to add more than "solid or blank" to the level is nice. I also made some optimizations to how I was generating the tile columns - at the very least it's hitting the array a little less, and the array itself is a little smaller. Part of this is due to the decision to have every tile be 16x16 pixels from the graphics block - this could lead to a tile or two being redundant, or not being able to re-use "half" tiles, but even in Dragon's Havoc I only used that flexibility for 2 tiles or so in the tiled stages, and it will greatly simplify bookkeeping here. I have a better idea of how many types of tiles I need and can use, and where I can fit them into the multi-bank structure. ROM breakdown to date: 9594 bytes of ROM space left in the main area of bank 1. 15174 bytes of ROM space left in the main area of bank 2. 0 bytes of ROM space left in the main area of bank 3. 3242 bytes of ROM space left in DMA hole 0. 4096 bytes of ROM space left in DMA hole 1. 16383 bytes of ROM space left in the main area of bank 4. 16383 bytes of ROM space left in the main area of bank 5. 16383 bytes of ROM space left in the main area of bank 6. 16383 bytes of ROM space left in the main area of bank 7. 7861 bytes of ROM space left in the main area of bank 8. custom pokeysound assembly: 743 bytes $18e0 to $1fff used as zone memory, allowing 14 display objects per zone. 513 bytes left in the 7800basic reserved area.

Wall of text incoming - taken from my dev diary: Getting used to bank switching - It's certainly easier to start a project with separate banks in mind than to try and switch halfway through! Here's a current breakdown of the ROM: 9922 bytes of ROM space left in bank 1. <- Bulk of the initialization and game logic 15174 bytes of ROM space left in bank 2. <- Level loading subroutine and current location of level data (which should move to another bank or banks later) 0 bytes of ROM space left in the main area of bank 3. <- 2 Graphic blocks... 3460 bytes of ROM space left in DMA hole 0. <- ...and the "draw code" to actually plot the screen data and player/enemy/bullet/object sprites before double buffer flipping. 4096 bytes of ROM space left in DMA hole 1. 16383 bytes of ROM space left in the main area of bank 4. 16383 bytes of ROM space left in the main area of bank 5. 16383 bytes of ROM space left in the main area of bank 6. 16383 bytes of ROM space left in the main area of bank 7. 7861 bytes of ROM space left in the main area of bank 8. <- The shared block. I currently have 1 graphical block (so I'll have access to 3 when shared with bank 3), sound info, Pokey stuff and other .asm modules custom pokeysound assembly: 743 bytes $18e0 to $1fff used as zone memory, allowing 14 display objects per zone. 441 bytes left in the 7800basic reserved area. A 16k bank can theoretically give me 64 "levels" with 8 scrollable screens each with the way I've structured things at the moment, so a cool 512 screens. Even if I add some header data to expand the number of types of tiles I can use, I think that's double the size of the labyrinth in "Legacy of the Wizard" in terms of screens, so I think I'll have a fun amount of space to play with if devote 1 or 2 banks to level data. I'll see how much space in bank 1 once I implement a set of enemy behaviors, but ~10k I still have in bank 1 is a fair amount to work with to implement the logic. Too many instructions and I might hit performance issues anyway. I'm wary of gosub, particularly to other banks, since that was pretty costly on the 2600 (you usually want to find a way to make it a goto), but I might have more use of it here. It works great with the level loading, especially since I can get away with that taking an extra frame or two as I fade in the new level from black. I plan on including bosses, and that's where I might really appreciate the extra banks - I could probably do a boss or two (plus palette shifted versions ) if I stuck to 48k, but this gives me a lot more freedom to think about what I could do. In "Dragon's Havoc" I had a lot of code for the bosses that looked copypasted from the enemy behaviors, but was *just* different enough that I couldn't really combine the two in an elegant way, so putting boss behaviors in a separate bank might actually avoid the usual frustration of code duplication between banks. I'm bringing in the Pokey engine for music, and the hiscore module - not for scoring, but to allow the possibility of saving your game progress. I also have a plan for a password system for those lacking a Savekey or AtariVox. Most of these modules need to be in the shared bank, so I need to be careful. Thankfully I managed to structure a lot of the graphics and logic so they don't need to be in the shared bank as well, but I'll see how crowded bank 8 will get when I bring in proper music and sfx. On that last matter, I might ask for help from folks in the know about how to manage audio in RAM - I haven't even touched the extra RAM bank in the 128kRAM setup yet, but I have a feeling it will come in handy!

I do see the resemblance - I take from a variety of sources and mix & match 'em, the one in the screenshot above I kind of have a Medusa/eyeless mouth of teeth thing going on, as its title is "Lamia, the Dragon of Fangs" ?

Finally got a system that can load/unload sprites from level data onto the screen. With Dragon's Havoc I always knew where enemies would be coming from (the right edge of the screen), but here they can come from the left, right, or spawn anywhere on the screen if the player drops or flies up a section vertically. I also need to make sure that sprites don't act persistent when they leave the screen by more than a tile or so, nor spawn incessantly if the player moves back and forth over their initial "spawn tile." I *think* I have a system in place - at least, it's working enough to start to bring in enemy behaviors, animations, collision detection, etc. I'm very curious how performance will go once I get all the systems (many taken and updated from Dragon's Havoc) in place. If I can get one basic type of enemy in place, I think I'll have most of the "main" systems in place, at least all the ones that will be running frame-to-frame, giving a good sense of how much space and cycles I'm using. I then plan to look and see what I can properly multibank - I've a few things penciled in, but once I have all of the main game systems in place (collision detection, level loading, enemy behavior, etc.) I can see how much of a footprint each part takes, and how well one system or another can be placed in another bank. I already have the level loading code (with data) in a separate bank, which has been handy. I don't have need of extra RAM just yet, but I imagine I could find use for it, especially if I go the POKEY route (or audio in general - it sounds like placing all active audio in RAM is SOP for multibank games). Each level section is 8 screens worth of scrolling wide - I'm storing each tile column in a level as a set of 5 nibbles, every 4 bits defining 1 of 16 possible sets of 2 blocks. That's enough for a few solid block types, a background tile or two, a danger tile like, say, spikes, and potentially one or two special block types like water. I think I'll try and be clever and use every 6th nibble to store part of the enemy data for a section - The enemy density won't be that high, so I might be able to fit enough data to have a full level section with both blocks and enemies in a 256-byte array. I've half a mind to add another array that could expand the possible tile sets from 16 possibilities to 32 or 64, especially as I fully embrace multibanking and extra RAM, but having a byte-per-tile would be overkill, and I need to keep an eye on my CPU cycles as I generate each new column as I scroll the screen.

I gave the build a quick spin with my Concerto on the 7800 (after trying it on BupSystem). The behavior between the emulator and 7800 seems pretty much the same, no obvious differences in graphics or performance from the minute or so I tried it, dirty tiles and all I'm following this thread in part to see your approach to scrolling - I ended up sticking with the double buffer for my current projects, in part because it was easier to get my head around, but I realize I don't know Display List Lists as well as I probably should. Great looking game, by the way!

I'm contemplating making some adjustments to the final build (which hasn't been made public yet). I am probably going to dial back the difficulty on the last cave stage, just a touch. Not really due to the inherent difficulty as much as the difficulty curve (it was the one level I got "stuck" on more than the others, by a wide margin) as well as the form factor of the Painline Proline joystick I used. After playing for an hour+, I had to give my arms a rest. On a challenging last level in a lengthy session, that's a lot to ask of other players with the default 7800 joystick Another thing I might change is putting the instruction screen as the second or even first image folks see upon starting up. It shows up if you wait, but folks who button mash upon powering up their 7800 will miss it, and button mashing is generally a poor strategy when playing the game... ...I suppose it comes down to: How many folks "get" the rage mechanic after playing for a little bit? Starting with the story blurb feels better, but I wonder how many folks never see the instructions, or never get the dynamic that "hitting stuff = speed up, missing stuff = slow down." I've really only seen a few people play, and most of those were before I put in some of the graphics and sound feedback that help the player know what's going on, so I'm honestly asking how intuitive the "rage" mechanic feels at this point. Putting tutorials in folks' faces can get annoying (especially since you really only need to read them once), but so is a game designer hearing stuff like "Pac-Man? It's an ok game, I just wish there was something you could do about the ghosts chasing you." or "I wish there was a way to power up in Gradius." As a designer, watching a player miss key game mechanics is frustrating, all the more so because a lot of that is on the designer I'm continuing watching this thread for feedback, so feel free to post with any observations, scores, or bugs - Thank you to those who've given kind words, and to those who've given the game a try!

I'm continuing to test the full version (which I haven't yet released) - I felt confident enough to do a proper playthrough of the full game, no "debug mode" or "cheat mode" - I did make use of my continue system, which puts you at the start of a level with your score reset. Of course, I know how the game is laid out, and what strategies to adopt, but I'm not the greatest shmup player in the world. With all that in mind, I was able to muscle my way through the game on original hardware in a single sitting, with minimal yelling and controller throwing. I'll admit the last few levels get tough - the last cave level particular requires some strategy and anticipation of what will come next, and doesn't forgive easily. My temptation to ease up on the difficulty of that stage a tad was overshadowed by the thrill of finally getting through it by the skin of my teeth, so I'm a bit on the fence there ? My high score was 9770 - That was from me surviving the first few levels, but my goal for this run was to "continue spam" my way to the end, so I was not too concerned with score. That will be for later runs - an "ideal" score is much higher - someone playing well in the demo can easily beat that! Separate volumes aren't really feasible with the way I have the code set up for the sound chip, my apologies. The 7800's sound chip was obsolete even in its own time (it's the exact same one as the 2600, which wasn't known for its melodic capabilities), and I have to do some pretty strenuous tricks with the it to have both sound and music on and be halfway listenable, a lot of which involve echoing and controlled volume decay between 2 channels. I will say there's always the option to turn off the music - I try my best with it, but I won't force folks to listen to it It's a classic parallax trick where you strategically shift graphical rows at different rates, combined with cooperative art design. It's one area where it's actually easier for the 7800 to do than the NES or SMS! Thank you!! I wish the 7800 had the audio capability to support something like Lords of Thunder's soundtrack ? I'm still running the game through various tests on hardware to look for any bugs or glitches. I'm still figuring out how I'll manage the full version, but folks still are welcome to continue to play the demo, either though the emulator or SD cart of their choice!

Plotmap, for its limitations, is fast and relatively easy manage. I found the limits to be similar to what you found - honestly, a full scrolling screen + 8-9 sprites is roughly what a stock NES can do (palette limitations notwithstanding), and was sufficient for Dragon's Havoc, and I've been adapting it for Harpy's Curse. The "Under the Hood" approach does seem like a more sophisticated way to do things, and feels like what an in-house expert would use - and seems to play to the 7800s strengths and the way it manages graphics. I imagine something like this was used for Scrapyard Dog. Some of my initial tests suggest it isn't quite fast enough for me to do the 11x10 16x16 tile screen setup I had before, although a better coder or some optimizations could certainly make it work. That said, if I were starting another game from scratch that required scrolling, UTH seems to be a good way to go - like I said earlier, I think some adjustments and strategic design could make it work well for a 4-way scrolling RPG along the lines of Dragon Warrior or Final Fantasy. Again, an excellent technique, thank you for sharing!

I'm investigating this method for an upcoming game as well - my assembly skills are wanting, but I'm tinkering around trying to see if this approach would make more sense than my current scrolling system. My current scrolling technique (see fig.1) involves storing a screen's worth of "tiles", 22x10 blocks (or an 11x10 grid of 16x16 "sprites," that last column being used for the edge of the screen), that I then divide into 2 parts and draw as two plotmaps. Moving where the division is effectively scrolls the whole screen. The beauty here is that all I need to do is update the column that's on the division, via a few pokes, and even that column only needs updating when I've moved a tile's worth horizontally. I'm still not entirely sure how efficient plotmap is versus a "sprites as tiles" approach, especially at the scale of a full screen, but it served me well in Dragon's Havoc. I did make use of the double buffer - even if I could draw a scrolling screen without it, there would be no time to do anything else like game logic. I guess my question would be what (if any) performance gain I would get from switching to a variant of the "under the hood" manipulation of DLLs. Tentative tests suggest I'd still want a double buffer, but I think I could pull that off with the ROM/RAM setup I'm looking at. I'd modify the ShiftZone to allow a "starting x" instead of assuming a line of graphics starting from the edge (which is my current stumbling block - my assembly skills, as I said, are...developing) so I'd be calling it twice per row, and changing where that "starting x" is as the screen scrolls. I could then change the updated column of DLL elements to be the appropriate new tiles as the level scrolls. Fig. 1 - "split screen" scrolling, or a type of circular buffer I guess my main question is, in the opinion/gut check of folks who know a bit more about DLLs, how much of a performance gain would this be, if any? Switching to an "under the hood" direct DLL manipulation could certainly be more versatile (I'm particularly looking at the ability to store color palettes), but my implementing such a system is going to be a bit of a work, and at this point something of a gamble if it ends up being slower or harder to maintain than my current approach. Even if it's just a *little* faster, it's a "devil I don't know." That is, it's a new technique to me, versus an older, more familiar one, so I wouldn't implement it for this project for just a slight boost. I'd likely keep it in the back of my head for when I want to do that 4-directional scrolling RPG I've also been thinking about. But, if it's a case of "What? Why are you doing it your current way? Direct DLL manipulation would be *much* faster!" then I think I'd take a more involved attempt at implementing it for my current game in development. Regardless, thank you for sharing this! This examples have been very informative, and a great tool to have in one's toolbox! EDIT: I might be overthinking this - I might just be able to move the rightmost object back to the left and vice versa, depending on which direction I'm scrolling, like a treadmill for each row. I think that would be fewer updates than some other approaches. I'd also need to figure out a scheme for collision detection if I go this route... My initial question still stands, however - 2 big plotmaps versus a full screen's worth of DL manipulations, how does each approach compare?

Beta Version Released! Latest Public Betas: SaveKey/AtariVox compatible ROMs (SD Cart or A7800/HSC emulator recommended): HarpysCurse_9_20_2023_BetaG_SaveKey.bas.a78 HarpysCurse_9_20_2023_BetaG_SaveKey.bas.bin Password Only (more emulator friendly): HarpysCurse_9_20_2023_BetaG_NoSave.bas.a78 HarpysCurse_9_20_2023_BetaG_NoSave.bas.bin Older Build (Save system with SaveKey/AtariVox Beta): HarpysCurse_8_18_2023.bas.a78 HarpysCurse_8_18_2023.bas.bin Keep in mind this is a beta build - I do my best, but I'm sure folks will find oddities and glitches. Please post what you find (and any other feedback) in this thread, and see later posts in this forum thread for progress and developments on the game! Harpy's Curse You are a harpy - swift of wing and vicious in nature. Banished to a deadly labyrinth, you are tasked with defeating the four keepers of the maze - only then can you face the Great Sphinx who exiled you here. The labyrinth contains legendary artifacts - feathers of legendary birds and beasts that might aid you. Great power might be found here, but you truly wish for escape, and the only way out is through the machinations of the Sphinx. Explore over 500 screens worth of scrolling, sprawling labyrinth filled with vicious denizens and power ups! A password system can help save your progress if you can't finish the game in one sitting. HOW TO PLAY Controls are configurable from a menu on the title screen - one button to jump/fly, the other to attack/swoop (or down + button if you set the controls to a 1-button joystick). You can hold down the jump button to fly, which will be handy when exploring or lining up for an attack. -Defeating an enemy drops their heart, which you can consume to refill lost health. -Large hearts can be found in the labyrinth, which give you a permanent increase in maximum health. -Keys can also be found, which unlock doors matching their color. -Feathers of legendary beasts will bestow further abilities if found - you will get a description of what they do and how they might be used if you can collect them! -Tablets will refill your health, provide a checkpoint if you fall to the dangers of the labyrinth, and give you a password that can bring you back even if you turn off the game. -4 Guardians must be found and defeated before gaining access to the Sphinx, and her defeat means your freedom from the labyrinth! First draft of POKEY soundtrack: HarpysCurse_12_22_2022.bas.a78 HarpysCurse_12_22_2022.bas.bin Build for Concerto + POKEY cartridge: HarpysCurse_12_23_2022_ConcertoPokey.bas.a78 HarpysCurse_12_6_2022.bas.a78 HarpysCurse_12_6_2022.bas.bin -------- (Original Post, preserved for historical purposes:) (This is simply tech demo footage, a proof of concept to see if this will work on a technical level) Something I've been working on as Dragon's Havoc is in the user testing phase. It's planned to be a sort of combination between Metroid and Joust - Imagine if Samus controlled like the Ostrich Knight while navigating a large maze. Horizontal scrolling between several sections, I'm working in bringing in enemies and different block types next. I'm also keeping an eye on performance - I'm expanding off of the scrolling engine I made for Dragon's Havoc, but the collision detection is much more sophisticated now, the level data allows more tiles, and you are now able to move backwards. While I still have a scenario where I can fit this game in 48K, like I have with my past projects, I did some tests and I finally went mulitbank! I started structuring the game early enough that I think I can pull it off. Even in 48K I budgeted for at least 128 screens' worth of game (currently each 256-byte scrolling level section defines an area 8 screens long), but I'm still experimenting with how I'm organizing the level data. No, I won't be moving any of the Dragon's Trilogy to multibank - they work well in 48K, they're either done or in their finishing phases, and I want them to be released in a timely manner! Part of my reason to go into retro homebrew is to finish stuff! It'll likely still be awhile before I even get even a demo version publicly playable, let alone released, but I want to show what I have so far since I'll certainly have questions moving forward. For instance, I'm seeing what's needed for POKEY compatible sound as well, along with what I need to consider when making this for a cartridge - I'm tentatively going with 128kRAM, $450 for POKEY address - any pitfalls or things I need to think about with that setup?

Politely requesting $12,$50 for "Harpy's Curse"

That's great to hear! Keep in mind that when you do lose a life, you're invincible for a second or two, but also you cannot fire for that window of time, so you need to use that time to get to a safer place (ideally lining up a good shot away from the bullets and enemies that just took you down!) The game does get harder (particularly the bosses) as, while I wanted an easy start, I didn't want folks to be able to get through the whole game on their first try. The game has unlimited continues, which start the player at the beginning of the stage they were on but resets their score. This also allows you to practice with, say, a boss that's causing you trouble, as you can take some time to learn its pattern and form a strategy. With that in mind, one should be able to muscle their way through the whole game with just a touch of patience in certain places, but a 1 Credit Complete run will be a challenge.

I hope the last post clarified a few things - people make assumptions on shooters, and I've been meaning to do something a little different with the way players power up. The way you play might take some getting used to, but assume autofire is on- the trick is to know when to *let go* of the button. In the video I posted, I'm *never* button mashing. Thanks for everyone who has played so far!

Autofire is in there, but your rate of fire is tied to how how accurate you are. Hitting enemies = go faster, missing enemies = go slower. If you watch the boss fight in the video around 5:25, with the player letting loose over a dozen shots into the boss at close range, that's me holding down the button, there's no way I can tap that fast (nor do I expect others to do so ) Your rate of fire is slow to start, and tapping the button faster doesn't make you shoot faster. Hitting enemies makes you move faster and increases your rate of fire. (I put that last part in bold because my aging thumbs require autofire as well - I can't ask folks to damage their fingers and controllers button mashing). This can make it easier to miss (and slow back down), but at full power at close range you can let loose a ton of shots *very* quickly. Really, the game is knowing when *not* to fire. I might make this instruction screen the first thing folks see when they boot up the game, it comes up in attract mode if you wait a few seconds on the main screen. I can't be too wordy with the space I have, but this at least tells the player "hitting stuff = good, missing stuff = bad": I'm one of those odd folks who demands autofire (my thumbs can only take so much), but also need a reason to *not* shoot. This is a game where you can't just put a piece of masking tape over the fire button. I'm also working on balancing colors - my primary display is dark in comparison to a typical NTSC range, so I'm working on recalibrating some of the palettes.

Posted another gameplay video (different from the rougher one in the programming thread): This playthrough gets to the second boss, but there are two more levels after that in the demo! I'm still welcoming any feedback from folks who've given the demo a try - this is the time to ask any questions, note any bugs, complain about any sound effects, etc. It'll be easier for me to respond to something involving the game now than when I'm burning it onto a cartridge!

I managed to get my hands on an Atari CX22 Trak-Ball, and I found playing the game with it was rather fun! I was only playing in joystick mode (since I hadn't added in code for the full trackball experience), and it took a little getting used to, but I think there's something there. When I figured out the control range, it worked nicely, and felt like it had more "resolution" than the joystick with the way I handle momentum. Spinning the ball *could* work, but moving the ball less than 180 degrees tended to work better and more accurately (plus I think the actual trackball is a little loose, so big spins can miss the contacts). It's been awhile since I had a good ol' fashioned centrally positioned trackball, for *any* platform, but if Dragon's Descent *had* been released as an arcade cabinet in 1982, I entertain the visual of it having a trackball controller. Which might further frustrate those who are still getting the hang of the dragon's momentum

Here's a really rough cut of some gameplay - I should add in title cards, cross dissolves, and star wipes, but this shows the first few levels and how to get through them. I demonstrate some strategies, particularly on the first boss, that folks might not know are possible.

I realize I have the same sound effect for both the enemy and player being hit-if nothing else I should make *some* distinction there. I have a little more space to add a new sound effect - that might help things a little bit, and I'm adding it to the list of adjustments I'm working on for the full version. The sound I'm designing now complements the "shield break" sound - my hope is that they should both be similar enough to tell you that you've been hit, but one ends with a "boom," the other a "you got a mulligan!" chime. This also reminded me to take another look at my sfx priorities, so minor sounds don't override more important ones (usually - it *is* still a 2 channel TIA chip, and I'm using one of those channels is for music )

New build showing score and lives at the same time: DragonsHavoc_2_20_2022_Demo.bas.a78 DragonsHavoc_2_20_2022_Demo.bas.bin Before, your lives counter only showed up when you were hit. 7800 graphics are largely limited by objects-per-screen and objects-per-line, and by the time I'm hitting the bottom of the screen and want to add a bunch of numbers, I'm running pretty low on both. I shuffled around some code, and now that I have a better idea of how I'm practically using my graphical limits, I *might* be able to get away with this Thanks to everyone who has played the game, and to those who have responded with feedback! As I mentioned before, this is basically an early user/beta test! Certain features will be much harder to change as I make final commitments to the ROM...

DragonsHavoc_2_20_2022_Demo.bas.a78 DragonsHavoc_2_20_2022_Demo.bas.bin New build - I *think* I can get away with showing both the score and lives at the same time. I played through the later levels, and I don't think the scenario of overloading the objects-per-line limit of MARIA will come up in typical (and even extreme) gameplay, and performance *seems* ok even with two players and their full status info onscreen, but that's exactly why I want folks to try playing this stuff!

Right now, you see your lives remaining whenever you get hit by something - I could lengthen the time the lives counter is shown, but I'm taking a crack at a possibly better fix - Drawing the both the scores and lives remain for both players was uncomfortably close to hitting the limits of the MARIA graphics chip - Now that I have some of the game finalized, I can optimize a little bit. I might be able to get away with showing both the lives counter and score for both players at the same time. In my testing, *if* both players are on the bottom row and *if* there were a full row of enemies and *and* a bunch of shots *then* the MARIA chip might glitch a bit - in practice, I don't think this can ever actually happen in the game as it current is (and if it did, in practice it would not be for more than a second, as *something* would get hit and be removed) given how I spaced out the levels. I needed to make a specific "stress test" level to create that circumstance. That said, I would be curious if anyone has the opportunity to play with someone else in 2 player mode - folks might be able to glitch by accident what I tried really hard to do on purpose

I have a "first full cut" that I'm testing by myself right now - the build I posted above is basically the first half of the game for folks to try out. No beta version of a game survives contact with the players, so consider this an early test screening I imagine I'll have a lot to fix and adjust in the game after some folks give it a proper road test...this is the time where folks can give me feedback about gameplay, sound effects, color choices, etc. and I might be able to make some changes accordingly. ? Oh, and here are some more screenshots: