Jump to content

Revontuli

Members
  • Content Count

    279
  • Joined

  • Last visited

Everything posted by Revontuli

  1. So much of it is structuring the game's code, and the fact you go from having 48K ROM *all* the time to 32K of ROM *some* of the time. If you plan ahead to use multiple banks, it's generally not a big deal, but adjusting your game to go from 48K to 49K can be a major headache. Accessing graphical blocks, as Muddyfunster pointed out, can play a lot into this as you have to deal with extra space taken by DMA holes and the like, and being able to access any graphic you want at any time will probably be the first thing you'll miss going multi-bank. ...and this. A hundred times this. One of the reasons I'm doing the series of games the way I am is to finish them - I've learned a lot about how to *start* a game, but I need a lot more practice on the trickier aspects of *finishing* them. Polishing, testing, printing, publishing all take time, effort, and a learning curve, and getting a game to that point is something I've been able to do and have a lot of fun with on the 7800 (and 2600). As for my current project and going multi-bank, Dragon's Havoc is riding that knife edge - I feel like I've gotten 90% of the features I wanted with about a kilobyte of ROM remaining, and while I kinda wish I had another 5k or so to play with, doubling/tripling/quadrupling the ROM space would tempt me with features and a change of scope, that, while potentially cool, could very well mean I'd just never finish it. I do have some ideas on how I'd structure and take advantage of a larger ROM structure, especially with what I've learned from my previous games (I'm already sketching out a project to follow Dragon's Havoc) but 48K is keeping me honest right now
  2. Another update before I have to shift focus (as the working week starts) - I made the rage mechanic a little more forgiving- I halved the "cool down" rate when you miss, which allows a *little* more recklessness, but still rewards someone being cautious with increased speed and rate-of-fire. I'm also playing with a few new music tracks - swapping out some of my older ones I used from previous games. DragonsHavoc_2_16_2021_Demo.bas.a78 DragonsHavoc_2_16_2021_Demo.bas.bin
  3. I've been tied up on a few other things (like finalizing the details of 'Cache and 'Descent), but for 'Havoc I've been in "graphics mode" and playing with sprite design. I'm trying an outline for player and enemy sprites - it can potentially reduce detail but I think it increases readability when in motion - which is important for a Shmup with complicated backgrounds. I also am slowly swapping out my placeholder sprites with newer ones - currently, Harpies and Perytons. Although for the moment I'm just seeing how well they animate - the actual AI for both will likely be slightly different, and appear in elsewhere in the game outside the demo. DragonsHavoc_2_14_2021_Demo.bas.a78 DragonsHavoc_2_14_2021_Demo.bas.bin
  4. With a Concerto, I can finally test the game with an AtariVox. To be honest, the reason I originally supported an AtariVox was that it came as a package deal with the high score code packaged with 7800 Basic. Saving scores without any extra code...why not? I still feel a little bad about that "support" being kind of a technicality for my games so far, but having grown up in the 8-bit NES/SMS era with no easy way to save high scores, I felt this game in particular deserved a chance to have a player's scores saved for posterity... ...but... ...now that I *have* an AtariVox, and I have roughly 1-2 kilobytes left on my ROM, realize I can potentially add a number of spoken phrases pretty easily...it feels weird fitting a speech phrase into a few dozen bytes by typing out a phoenetic phrase! It's too late to add such chattiness to Dragon's Cache, and I probably won't have space on Dragon's Havoc, but having a gravely synth voice taunting you seems especially appropriate for *this* game. The Dragon Molobros might try his best Evil Otto impersonation as you travel through the passages. He's an imprisoned elder wyrm, it feels right he should heckle you as you descend the Labyrinth...🐲 I'm still playing with the functionality, and have a few questions (I took a quick look on the forums, but didn't find many specifics...) Currently I'm on a Windows 10 machine with no good serial adapter, so I have to build a ROM ->run on Concerto to see how certain phrases sound, unless there's a better way to test, I'll likely be doing that: -"set avoxvoice on" - The game seems to work fine on the Concerto even when the AtariVox isn't plugged in - do I need to add any code to "opt out" for when the user *doesn't* have an AtariVox? -The ranges for pitch and speed are 0-255, correct? I'm been trying a number of values to get the voice resembling "belligerent gravel-y voice from the deep" instead of the classic "snooty speak n' spell," and I think I might have something... -so many ways to say "dragon," especially with that last vowel. Just about any will work (with "o" weirdly being the most "off" for the 'Vox) - Dragen? Dragin? Dragun? Dragan? -any advice is welcome, especially as this seems especially niche, and it sounds like just about everyone is still experimenting with this fun little peripheral...
  5. Awesome - thank you for testing on short notice!!! One can never be too careful, even with small fixes!
  6. The Homebrew Award Show was awesome! It felt incredible to be nominated with that crowd!! And now some last second fixes, after watching some of the previous streams... Now that I'm able to play on hardware, some things become obvious that weren't on an emulator - This build should honor the console "reset" button: DragonsCache_2_7_2021.bas.a78 DragonsCache_2_7_2021.bas.bin If anyone can check to make sure the score saving still works on the SaveKey/AtariVox/etc. I would be grateful. It *should* be fine, but I've made some silly mistakes with small fixes in the past. The carts are being assembled, and I *hope* this ROM image (or one in the next day or two) will be the final build to "print."
  7. Yes - not with the Concerto itself, but hardware like the AtariVox and the SaveKey can save your scores and will load them back into the game when you power on the 7800 later.
  8. Whew - sorry about the late posting - a busy two weeks for me as the year starts in earnest! Just reiterating how I "fixed" the game for the BupSystem (because I can't remember if I posted the specifics here) - For the BupSystem fix I set hsdevice = 0 (i.e. assume there's no save device attached), and that seems to keep BupSystem from crashing. Of course, it also keeps you from saving your high scores - not a huge deal if you're using BupSystem for a quick game on your desktop, but might be an issue is someone wants an AtariVox playing nice with a Concerto. In short, if it's the same bug, it looks like an issue of an emulator detecting hardware (and the BupSystem crash was intermittent as well - it worked fine on my machine much of the time, until it didn't ). I'd also allow that it could be something I did as I was tweaking the high score code - this situation is an odd overlap of emulation and hardware. I'll try to pay more attention to this thread again, as the BupSystem debugging uncovered a few other glitches that I thankfully (hopefully) fixed. Many thanks to you all for testing - I managed to pick up a Concerto, and ordered an AtariVox, so I might be able to do some more specific tests on my end. If nothing else this can help me moving forward (as I've a few other games in the pipeline ). I'm glad folks enjoy the game, even if there's the odd freeze now and then!
  9. Thank you for the nomination! I'll add that this game is in amazing company and competition for the award... You can vote for the awards (and see all the other amazing games) here:
  10. Fixed an annoying bug involving post-respawn invincibility and collision detection (very obvious in 2-player mode), plus trying out some other music. I was trying out a few other things as well, hopefully it didn't mess up the demo build *too* much... DragonsHavoc_1_18_2021_Demo.bas.a78 DragonsHavoc_1_18_2021_Demo.bas.bin
  11. Finally testing on hardware with the Concerto. Found and fixed a graphical glitch on the high score menu (which I think I introduced in the last update ) DragonsDescent_1_7_2021.bas.a78 DragonsDescent_1_7_2021.bas.bin Still cool to see it play on a bona fide 7800!
  12. This build will pause on the "Game Over" screen for about two seconds, and should have better menu tempo: DragonsHavoc_1_3_2021_Demo.bas.a78 DragonsHavoc_1_3_2021_Demo.bas.bin
  13. New build. Currently I'm just fixing menu and palette shifting bugs, as well as tweaking some of the sound fx, nothing big, but probably stuff I'll forget about if I don't fix now: DragonsHavoc_1_2_2021_Demo.bas.a78 DragonsHavoc_1_2_2021_Demo.bas.bin
  14. This was a neat little trick I found - plotchars has a parameter where you can tell it how long to print the string, but the string itself can be longer. Just define a string that's the maximum length of the meter, which character graphics you want to use, and draw only the number of characters you need: alphadata rage_meter scoredigits_8_wide '>>>>>>>>' end if rage <> 0 then plotchars rage_meter meter_color x y rage
  15. OK, here's the start of a proper rage/fury meter: DragonsHavoc_12_31_2020b_Demo.bas.a78 DragonsHavoc_12_31_2020b_Demo.bas.bin The technical basics are working, but I'll likely want to change around the graphics a bit.
  16. I think I have something in the works - I just did a "stress test" on my 7800 to make sure the display could handle it. I'll probably post an update with a meter tomorrow (getting this initial demo uploaded was an accidental all-nighter for me ). On the uploaded demo build, the score/dragon color pulsing (as well as the sound pitch) is tied to the rage level, so you can get some idea of how enraged you are, but I'll admit it's subtle and not quite what you need if you're in the middle of a ton of enemies...
  17. I was stumbling on this a while as well - What I ended up doing was having my continue variable *skip* code when I do my game over/reset variables. Instead of setting the level back to 0, I just keep it where it is, for instance. The more complicated part for me was adding the extra menu option on the game over screen.
  18. Oof - I'll have to sleep on that. I'm in an odd situation where going multi-bank will actually result in me having *less* space for some stuff, at least in terms of graphics blocks. I'm using 3 graphics blocks right now, which all fit snugly with the code in 48K, but would be a headache to restructure if I had to segment everything as it stands into separate banks. I might take another look depending on how the other levels go. It's certainly something I'm considering for future projects (especially with things like the Concerto for testing, and a lot of sound chip options on the horizon), but multi-bank also something that's much easier to deal with if you commit to it early on. Glad you like it! I'm curious to see how folks respond to it - the actual numbers might take some tuning, but I think the idea is sound. As for a rage meter, I was about to say I'm out of graphics, but I *might* be able to try something... Thank you for playing (and wow, that was a quick response!)
  19. Here's demo for folks to try! The game ends after stage 1-3. High Score entries are turned off for now. DragonsHavoc_12_31_2020_Demo.bas.a78 DragonsHavoc_12_31_2020_Demo.bas.bin Rules are simple - The more you hit with your fire breath, the faster you and your shots move. If you miss (or lose a life), you slow back down. If you are at maximum speed, any points gained are doubled. There's still plenty for me to do, even in terms of the demo. A lot of the graphics, music, and sounds are still stand-in (folks may recognize sprites from my previous games) but I wanted to post something before New Year's. This is a little like a quiet opening before the Oscar deadline...
  20. (opening text...) In Dragon's Havoc, play as a dragon with a berserker rage - the more damage you do with your shots, the faster both you and your shots move, which makes it that much harder to be accurate...and missing with your fire breath reduces your rage, slowing you back down. You need to balance aggression with finesse if you want to face what's ahead! Developer Diary: A lot of clean up and bug fixing, as well trying to clean up various odd game states that could happen. I also need to do more stress testing on physical hardware (that's for tomorrow). I added in some cheat codes - as much for my own debugging as anything, but I figured they'd be good to have (even though they're eating up precious ROM space ) Adding the Stage Select cheat was 366 bytes or so, and I'm sure I missed a few places it could screw up the game logic... Still, I added in dummy level data (basically duplicating my test level to stand in for the planned 7 stages), so that my level data is "filled," and I shifted the audio data to a DMA hole area. Current ROM space countdown: 950 Bytes + 475 bytes (DMA Hole 0) + 576 Bytes (DMA Hole 1) I have a suspicion I'll need all of those bytes (and a little more) for bug fixing, but with the cheat codes added, I have all the "menu" features I currently want. It's going to be hard to add any big new feature, though, but I think I managed to get in all the major features I wanted, and a lot of the minor ones. We'll see if they can all survive bug fixing and beta testing. If I need to, I can make more room in ROM by making levels shorter, or not having as many enemies in a level, or by creatively composing the music (I just threw in the songs I had from previous games as stand-ins) so we'll see how things go as I start editing the stages. I've tried to make things easy to *change* even if *adding* new stuff is getting trickier by the hour. The attract mode has the main menu, a story screen outline above, the high score leaderboard, and a quick instruction screen if you wait a few seconds: I *do* mean to post something playable soon, depending on how my planned gauntlet of tests on the Concerto go.
  21. Finally got something in the mail this evening, a crucial step for developing a proper 7800 cartridge. Here's a picture of the results: With the Concerto I can run on physical 7800 hardware! Thanks to Batari for getting an SD Cart solution available - this has been a major hole in my development pipeline (although I am very grateful to everyone who has helped test these games on their own setups - these projects would not have come as far without your aid!) First glance, things seem to be working more or less as planned. Oddly, BupSystem found a bug MAME A7800 didn't (involving a shortcut I'm doing to draw the score/lives). I also need to turn on the performance testing stuff again, but now I can do it with a much better feeling that I believe what I'm seeing on a physical 7800! Also good to get a proper handle on CRT coloration. This last day has been a lot of cleaning up the menus and attract mode screens. I'm internally debating how much space I have left to devote to title screen graphics, and miscellaneous things like that. With the Concerto I need to go back and test a few "upper limits" to see how the game performs, and hopefully move forward with a bit more confidence.
  22. Fun with parallax landscapes: 609 bytes + 3471 + 2859 bytes of DMA hole ROM remaining Continuing to fix bugs and file off the rough edges of various systems. I also inadvertently "won" the game playing through several stages - I just meant to test a boss, but the next level loaded, then the next, and I forgot I had a set of maps queued up. They were all using shortened dummy data, but the initial run, while rocky, worked! I'm trying to focus on making sure the internal core systems of the game (loading levels, going back and forth from title screen, scoring, enemy behaviors, etc.) all work. I'm still feeling ROM-bound, (although I'm still wary about performance) as each bug I fix tends to chip away at ROM space. The game is largely "feature complete," and by "feature complete" I mean I'm (naively) hoping to get the most of the rest of the game in mainly by data and assets, as opposed to new code. I personally find code creation and asset creation are two different parts of my brain, and I like to switch between one and the other if I can, instead of tackling both at once. In practice that's never the case, but I hope for at least a 70/30 split at any given time.
  23. Developer diary update...ROM countdown: 2218 bytes remaining (+ 3475 + 3801 for DMA Holes) While this screenshot looks like a simple palette shift, and it is, it's all data driven and designed to be easily changeable. I have 6 "layers" (that is, a tile-height row) that I can move at a data-driven speed, with the rest of the tilemap static as a "far" background - and I can shuffle these 6 rows + background vertically to where I want them per level. So I can have a wide variety of different types of backgrounds without changing a line of code (beyond the values stored in data). About a kilobyte to parameterize my parallax system, plus carving out the data I'm earmarking - the parallax system has limits but the variables can make it pretty versatile. Between being able to change colors, row speed, and what heights the layers are, I should get a good amount of flexibility without using *quite* as much raw data to full screen buffers. I'm starting to move level header data to DMA Holes, in part to see how much "header" data I'm actually using (i.e. data that isn't simply tiles or enemy info). The "tile" part of the tilemapped levels are up to 256 bytes, and the enemy data is up to 256 bytes as well. Each level is meant to have a parallax section and a tiled section. 256 bytes for the tiled info, and 512 bytes for the two sets of enemy data, times 7 levels total = 5,376 bytes before accounting for any header info (or character/tile data for the screens used in the parallax map). I should really check on the enemy behaviors to see if I have all the dynamics I want there as well - I have a pattern system that is similarly data-driven, and potentially fun to play with. I fear it might get the squeeze once I start running out of space, but I'll see. The menus are largely working, I just need to go through the process of centering text, remapping the color palettes, etc. I'm running out of things to do before I actually have to sit down and *design* a level or two
  24. OK, I lied. I got a relatively good facsimile of an ending sequence in, with some text and even a little animation, and still have 3016 bytes (plus DMAHole stuff earmarked for level data) left! Not too bad for ~300 bytes. It will be a little more space once I incorporate it into the rest of the game loop, but I was able to leverage a lot of the systems I either already had or had already allocated. Still plenty to do, of course, we'll see how much I can squeeze out of the remaining space. AI and possibly some generalization of the parallax background mode - there's a lot of hardcoded numbers that could potentially be variables, making the system more versatile (but also require more space to really take advantage of).
  25. The ROM countdown continues... : 12-21-2020 - 4901 + 3803 + 4096: Basic high score leaderboard (attract, single, 1P and 2P entry screens) : 12-21-2020 - 4811 + 3803 + 4096: Initialized blank chars to ?'s, save<->to HSRAM, might be able to trim : 12-21-2020 - 4706 + 3803 + 4096: 14 sets of memory pointer locations and if/then branching to them : 12-21-2020 - 4496 + 3475 + 4096: 7 memory bookmarks of hypothetical tilemaps with branching : 12-22-2020 - 3672 + 3475 + 4096: Attract mode text in and rotating, most of the input for handling that is in but needs testing. I've a story screen, an instruction screen, the leaderboard, and the main menu, which can lead to a selection screen if you're in single player mode. : 12-22-2020 - 3491 + 3475 + 4096: Static images added to the instruction screen. : 12-22-2020 - 3399 + 3475 + 4096: Various joystick input checks for menus and screens added Roughly a kilobyte and change to most of the various "screens" working, plus another kilobyte soaked up by various fixes and adjustments. The text was already added to the ROM, so the whole system takes up a bit more space than that. A lot of these screens are on a rotating "attract mode" - we have a story screen, an instruction screen, and the leaderboard cycling if you are idle on the main menu. The other screens are a "game over" screen that leads to the high score input, and a character select screen. Those of you who played Dragon's Cache know that you can choose between the Dragon of Storms and the Dragon of Embers, and I added that same option here - it's mainly cosmetic, but fits into some larger plot elements. How much *plot* I'll be able to fit into the game is another story. These static screens are in and largely functional (if somewhat spartan), so I'm going to go back to making sure I can get some decent gameplay working before I devote more bytes to things like text and menus. I do want a cool ending(who doesn't?) but it all depends on how much space the rest of these features will take up. I have a good deal of empathy for those who only have space for a "CONGRATULATION" at the end of their game once they put in everything else the game needed... I've decided on making 2 test levels for this initial tech test. If I can get 2 levels (plus menus, gameplay flow, etc.) working, then adding a third should be pretty straightforward. Most of the graphics will still be stand-ins, but once I can demonstrate 2 full levels with different enemies, etc. I can focus more on level design and sprite graphics, and not worry so much about fitting stuff into ROM.
×
×
  • Create New...