Jump to content
IGNORED

Dragon's Havoc - Side-Scrolling Shooter, Cartridge Available for Purchase and Demo available for download in thread!


Recommended Posts

46 minutes ago, Karl G said:

Now I totally want to make a diagonal shooter. :P

 

Like Desert Falcon 2?

 

Revenge of the Sphinx. 

 

Now as the Sphinx you will howl and claw your way to the Falcon Fortress to reclaim your treasure. 

 

This Supergame will feature 32 exciting levels with mind blowing power-ups. 

 

Are you ready to get Sphinxed? 

 

Coming spring 2021 at an Atari dealer near you!! 

 

 

 

 

 

 

 

  • Like 1
Link to comment
Share on other sites

  • 3 months later...

This looks good. I love side scrolling flying games. Most people are into R-Type but it is to slow for me. I'm more into Air Buster for Arcade or Sega Genesis myself. If this could be fast like that it would be amazing. If it is too slow you will probably get more people interested as most people can not deal with the speed. So whatever this turns into I hope it goes really fast but it is probably ideal it sadly is slow for the average player.

Link to comment
Share on other sites

  • 3 months later...

I'm still working on this game, don't worry!  I'm working on (what is called in the biz) a "vertical slice," a single level with most of the features in, to see if I can get away with what I want to do on the 7800.  The idea is if I can get one complete level working properly, I'll ideally have a structure to add more levels, enemies, etc. with a pretty good idea of what it will take to implement them.

 

Random developer diary observations/rants/statements as I ramp up work on this game again:

 

-I'm getting my old TV set up, and hopefully should be able to properly test on a physical 7800 soon, so it'll be interesting to see how my methods for scrolling and adding multiple sprites to the screen end up behaving.  MAME a7800 is supposedly a pretty accurate emulator, but it feels like I'm pushing hard enough that I want to see if I can actually get away with what I'm trying.


-*fast* framerate is not nearly as important as *consistent* framerate. 

 

-If I do go multibank, it'll probably be by me being dragged kicking and screaming into it.  I find that 48k all the time is much more convenient than 32k some of the time, even if you have 128+ k to access.  That's even before factoring in the technical and debugging challenges on top of the structural ones.  This is to take *nothing* away from those who take advantage of multibank layouts (I've done it on the 2600, it's tricky, you have to be careful, and it can totally be worth it!), it's largely me looking to the simplest chip structure and method of programming at the moment.  Plus, having the 48k constraint is keeping me honest and making sure each byte is pulling its own weight.  Speaking of...

 

-Man, managing text takes up a ton of ROM space :)  I've a newfound appreciation for why old 8-bit games were not known for verbosity.  Plotchars + full lines of text add up *fast*.  I've found one or three screens of laconic instructions or exposition can easily gobble up a kilobyte or two if you're not looking.  For comparison, I think I can fit a pretty lengthy level, complete with multiple stages and hundreds of enemies, inside of a kilobyte.  If I do decide to go multi-bank, one bank (or more) will probably be nothing but text. 

 

-I've learned a lot, especially from my previous games, but there's still a lot to learn!  I'm appreciating 7800Basic and its abilities-it makes the 7800 a fun platform to work with! 

Edited by Revontuli
  • Like 8
Link to comment
Share on other sites

6 hours ago, Revontuli said:

-Man, managing text takes up a ton of ROM space :)  I've a newfound appreciation for why old 8-bit games were not known for verbosity.  Plotchars + full lines of text add up *fast*.  I've found one or three screens of laconic instructions or exposition can easily gobble up a kilobyte or two if you're not looking.  For comparison, I think I can fit a pretty lengthy level, complete with multiple stages and hundreds of enemies, inside of a kilobyte.  If I do decide to go multi-bank, one bank (or more) will probably be nothing but text. 

Yeah ascii sneaks up on you. Even a single 40x24 screen of characters is most of 1k, let alone wrapping up strings with plotchars. Maybe some day I'll have a go at some kind of Huffword encoding, though even that's not going to be magical (~50% compression, depending on the number of words used) and then one would need to unpack the strings into memory before using them.

 

6 hours ago, Revontuli said:

-I've learned a lot, especially from my previous games, but there's still a lot to learn!  I'm appreciating 7800Basic and its abilities-it makes the 7800 a fun platform to work with! 

That means a lot to me, especially since I most often get feedback when someone hits a bug or is having a tough go with some functionality... there were some lean years during which the 7800basic developer landscape was a lot more barren, with just a few brave early adopters. It's very gratifying to now see all of the different 7800basic WIP and completed projects, yours included. ?

 

  • Like 7
Link to comment
Share on other sites

3 hours ago, RevEng said:

Yeah ascii sneaks up on you. Even a single 40x24 screen of characters is most of 1k, let alone wrapping up strings with plotchars. Maybe some day I'll have a go at some kind of Huffword encoding, though even that's not going to be magical

...and any encoding/compression has to take into account the space/memory/CPU required to implement it, like a rocket carrying its own fuel.  Huffword encoding could totally make sense for an RPG with a bank or few to devote to a library.  For a Shmup?  Probably not...text is always bulky, especially if you're used to coding more abstract things like motion and logic.  R-Type's opening exposition, in totality, was "BLAST OFF AND STRIKE THE EVIL BYDO EMPIRE!" and I very much see why.  If I do implement some textual cutscenes for Dragon's Havoc, they'll likely be terse and somewhat mysterious.  But then, that seems to make sense for a game about dragons...

 

3 hours ago, RevEng said:

there were some lean years during which the 7800basic developer landscape was a lot more barren, with just a few brave early adopters. It's very gratifying to now see all of the different 7800basic WIP and completed projects, yours included.

Your continued help, support, and persistence has allowed these projects to happen!  The 7800 is a fascinating platform, but having a good development pipeline is what really got me involved.  7800Basic exists in an amazing sweet spot between power and ease of use, and I know I'm not the only one who appreciates that!

Edited by Revontuli
  • Like 6
Link to comment
Share on other sites

Working away at the game.  I'm putting in a lot of dummy data to see what I can actually get away with in ROM (as well as MARIA and TIA).  No build posted yet, but I do have a picture and some developer notes, for those interested...be forewarned, here's a wall of text from a programmer working on a SHMUP for the 7800 during the holidays and lockdown...

 

DragonsHavoc_12_20_2020.thumb.png.0808f06240599906fc9c544ca3399b70.png

 

The screenshot is a bit garish, and uses graphics I have lying around.  Getting the colors properly indexed will be nice, but is always one of the last things I end up doing.  DMA holes give me 8K, which is roughly what I've budgeted for 7 levels worth of data, i.e. ~1 kilobyte per level plus various header data.  I've also started a developer diary based on ROM space left, as told by 7800bas.exe:

 

Date/ROM Size in kilobytes:

      12-9b-2020 - 23291 + 4096 Left (4096 is the DMA hole) no titles, no boss
    : 12-9b-2020 - 15099 + 8192 from DMA holes after additional graphics block defined
    : 12-9c-2020 - 14037 + 8192 from DMA holes after title screen + menu (1P/2P/Music off/on)
    : 12-9c-2020 - 12900 + 8192 from DMA holes after copypaste of enemy code to start on boss behaviors
    : 12-9c-2020 - 12785 + 8192 after putting in start of EnemyInit code
    : 12-10-2020 - 11852 + 8192 after adding in level titles (!)
    : 12-12_2020 - 11716 + 8192 color stuff, about to add explosion fx spawn
    : 12-13-2020 - 11431 + 8192 with some added enemy stuff, starting to integrate proper first draft of boss
    : 12-13-2020 - 11170 + 8192 added in another dummy "background" for parallax-based bg
    : 12-13-2020 - 10738 + 8192 when adding terse intro text
    : 12-13-2020 - 10429 + 8192 with hiscore.asm added
    : 12-19-2020 - 9414  + 8192 with stock sfx and old, stand-in music tracks added
    : 12-19-2020 - 7946  + 8192 with hiscore.asm *actually* added to ROM
    : 12-19-2020 - 7198  + 8192 with 5 enemy slots 
    : 12-19-2020 - 7131  + 8192 ...with a sixth... 
    : 12-19-2020 - 6997  + 8192 ...seventh and 8th...
    : 12-19-2020 - 6550  + 8192 playing with Text
    : 12-19-2020 - 5987  + 8192 temp ending text, credit text, and instructions, not implemented, just put in to check space taken 
    : 12-19-2020 - 5741  + 8192 another screenmap to allocate to a parallax background
    : 12-20-2020 - 5299  + 8192 system for 4 different tile "columns", plus allowance for different tiles on different levels

 

Of course, the idea is that once I've got the features in, complete with dummy data, actually managing the assets like graphics and levels won't really shrink the ROM size further, nor should it change the CPU/MARIA usage.  I also remember getting the game in, feeling great about ROM remaining, and then realizing the menus + bug fixes take up more space than you thought.  This will also be interesting if I *do* decide to go multi-bank - reorganizing the game loop could be a pain, and figuring out the best way to use the extra bank space is actually a tricky question. 

 

It's funny, having extra RAM/DLL memory sounds good initially, but with the type of game I have it'll be hard to take advantage of in practice.  I didn't use extra display ram to begin with since it took away from the RAM I needed to keep track of the things I'd presumably be drawing - a proper Catch 22.  Even if I used an extra chip for the RAM, I'm butting up against the CPU limits already, so I don't think I could really do more sprites if they had the behaviors I'd want.  At the end of the day, I think I'll have a scrolling background with 8 sprites I use for players + enemies, and 8 sprites for projectiles.  That's in many ways better than what I'd be getting if I were doing this on the NES, but I'm also picking my battles. 

 

As far as non-display RAM, I mean, you can *always* use more RAM, and since I have to do a lot of fullscreen stuff, I'm at the point where I have to be careful, but I'm budgeting variable names where I can.  Having another block to play with would make me fundamentally rethink a lot of things, i.e. create more problems (even if they're happy problems) more than it would solve a specific problem I currently have :D  I'll probably be eating these words with a few ROM chips eventually, but it's interesting to see how far one can get on 48K ROM/1.5K RAM, especially after the Atari 2600.  And if I decide to look at sound chip options (YM, PokeyONE, HOKEY, etc.) , then a lot of this goes out the window too  ?:music:  The TIA has been good for me because I'm a crap musician but an OK programmer, so it's been a surprisingly fun partnership (that and the 7800Basic Music Tracker is really handy!) - That said, I've heard what folks have done with even slightly more advanced sound chips, and goodness, I see why folks are waiting for a good, easy way to make the 7800 generate higher quality sound!

 

I'm still making myself implement 2 player simultaneous play.  It supports various thematic elements of the game, and I still haven't learned my lesson from previous projects :P  It's twice as much code (plus a little), you need to take into account how enemy AI will respond, a set of sprites and CPU cycles are now taken up by a possible player, etc. etc. etc.  There's a hundred things to keep track of, and if you anticipated 4 of them going in, you're a genius (I anticipated 2).  Having two players at once is fun, but I can see why so many 8-bit ports of arcade games did not have this feature ?  

 

CPU/MARIA *seem* to be doing ok with what I'm demanding from them, but I want to try on hardware to be sure.  I might be able to do that myself, soon :)  Atari Homebrew is about shifting your current worry between RAM, ROM, and CPU/GPU cycles.  I'm concerned but have ideas and possibilities for managing all three.  ROM was my focus this week, RAM is finite but I've been able to squeeze what I've needed so far, and CPU speed has been ok on emulation, but always feels like the next if...then statement will halve my framerate, so we'll see.

 

While I've space *allocated* for 8 enemies (so far), my current plan is to just implement 2 or three for now, plus a single level (or maybe 2, just to make sure the level progression system works) to get the "vertical slice" with most of the systems working.  Then I can focus on actually working on the sprites, enemy parameters, backgrounds, level layout, etc. *within* those systems.

 

So that's where I'm currently sitting.  I'm not quite at the stage where I have to make hard decisions on where to take the game yet, but I see that stage coming.  It's been a blast, though, and I'm surprised at what I've been able to get away with so far!

 

Edited by Revontuli
  • Like 7
Link to comment
Share on other sites

DragonsHavocDataCreator.thumb.png.49eb82f9130cb829ee2c6b839c83c2b3.png

 

I wrote an external Java script to turn a bitmap into binary data for 7800basic, so I can "paint" stages and enemy placement.  A lot of the enemy/level data is in nibbles, so this turns the bitmap/decimal data into a nice set of bytes.  There are a lot of ways to do this, of course, but I'm used to writing things quickly in Processing (a fun Java library), and it's just a copy/paste once the data is converted.  I like painting in a raster program more than typing commas and doing binary/hex math in my head.  I still must like doing the latter at least a little bit, though, otherwise I wouldn't be here.

 

Current ROM size progression (in bytes):

: 12-20b-2020 - 5360  + 3803 + 4096: Moving level data to DMAHoles, 
: 12-20b-2020 - 5277  + 3803 + 4096: starting Game Over sequence
: 12-20b-2020 - 5124  + 3803 + 4096: Players show explosion graphic animation when hit, reach Game Over screen if both are at 0 lives

 

The DMAHoles are a little reassuring - I'm only going to use them for level data, so I have a pretty good sense of my ROM budget for everything else that I might still need to do.  I'll see what 5 kilobytes and some creative math allows me...

Edited by Revontuli
  • Like 4
Link to comment
Share on other sites

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.

 

  • Like 4
Link to comment
Share on other sites

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

  • Like 5
Link to comment
Share on other sites

Developer diary update...ROM countdown: 2218 bytes remaining (+ 3475 + 3801 for DMA Holes)

 

DragonsHavoc_FullMoon_12_23_2020.thumb.png.d65e0278897c8f388f1689b01d69eacb.png


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 :)  

  • Like 5
Link to comment
Share on other sites

Fun with parallax landscapes:

DragonsHavoc2.gif.390acfd23e06dc51e647ae638ba8e604.gif

 

609 bytes + 3471 + 2859 bytes of DMA hole ROM remaining

 

ParallaxTest_12_27_2020.thumb.png.4d75c061b051421ff69cf448b353c3f0.png

 

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.

 

  • Like 16
Link to comment
Share on other sites

Finally got something in the mail this evening, a crucial step for developing a proper 7800 cartridge.  Here's a picture of the results:

 

ConcertoPic2.thumb.png.95e680296c0a077fbb00403bf4344424.png

 

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.

  • Like 9
Link to comment
Share on other sites

DragonsHavocStoryVariant.png.04f073dab81801a71aca39caa7ff7209.png

(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:

 

DragonsHavocAttractModeInstructions.thumb.png.729bd12bdce8236879e91e9e06a72976.png

 

I *do* mean to post something playable soon, depending on how my planned gauntlet of tests on the Concerto go.  

 

Edited by Revontuli
  • Like 8
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...