Jump to content

Revontuli

Members
  • Content Count

    107
  • Joined

  • Last visited

Community Reputation

158 Excellent

1 Follower

About Revontuli

  • Rank
    Chopper Commander

Recent Profile Visitors

1,567 profile views
  1. Not yet - among other things I still need to test the 7800 version more thoroughly on the original 7800 hardware. I currently lack the equipment to do it myself. A 7800 SD-cart or equivalent is hard to find at the moment, although I've heard rumors of some stuff on the horizon. That said, now that the 2600 version is "shipped," I hope to have more attention to give to the 7800 version - there's even a feature or two I'm considering adding, depending on things. I'll post as things develop!
  2. We've got carts! Thanks to Al, I've got a couple I showed at IndieCade last weekend, and they should be for sale at Portland for the Portland Retro Gaming Expo this coming weekend (October 18-20) and available online some time after that! Box and instruction manual included!
  3. There! I built a script that can output Dragon's Descent levels - I prototyped it in Processing/Java, but it shouldn't be hard to port to C/C++/C#, especially now that I have a better idea of how the two bytes are interacting. Here are maps of the first 3 levels.
  4. Something like that combined with the playfield might work - although the way I'm using the graphics in this a particular game complicates things. Since there's no bottom row of pixels closing the keyhole, it might make the shape ambiguous if it's in the middle of the screen without supporting graphics (a common problem with most other shapes as well). I ended up settling on the door graphics I posted about earlier, and managed to squeeze another sprite into the ROM, animating the sprite. Animation helps considerably, and I feel a little bad ruling it out as a possibility when I posed this problem. Thanks for the input and suggestions - I'll be posting some more info on the game soon!
  5. I've done a lot of different experiments with Procedural Content Generation (PCG) for different games. One caveat is that PCG means something a little different to different people, but I'll give my 2 cents on my experiences in using it for the Atari. Dragon's Descent leverages PCG to a large extent, my rough estimate is that there are around a half million mazes that can be explored on a 16k cartridge, starting from around 65,000 initial first levels. While I use PCG for maze generation, it's combined with some other elements so it's not just a simple Maze Craze clone - it's a Roguelike, or a Zelda-lite, where I can fit a key, treasure room, and other elements that allows complete, navigable levels that the user can play through or even revisit. The two Atari difficulty switches give the player a "Random" mode and an "Infinite" mode - the player can start in a wholly unfamiliar maze while still knowing the rules for surviving it. Alternatively, that can play the "default" maze and become very familiar with its layout. I go into the process in a fair amount of detail here: In batari Basic a good tool to use for PCG is rand and rand16. While rand16 is a 16bit process, I got a lot of mileage out of changing each byte separately. In Dragon's Descent you can pick a level at random, or choose the "seed" you want and revisit any of the initial mazes yourself. Playing through multiple levels just means I increment one or the other byte, and that "next level" can be randomly controlled, so to speak. I combine rand16 with other processes, like a "noise" array of bytes to introduce further variety, as well as some other types of data that allow me to control trends like enemy encounters, mazes becoming more difficult as you progress further, boss appearances, etc. The small size of Atari ROMs certainly encourages clever uses of PCG - Pitfall is a classic example, using something very similar to batari Basic's rand to create a 255 screen jungle. Given the 8-bit architecture of the Atari, you are very aware of how pseudorandom numbers work. 256 values in a byte don't seem like much for, say, building a galaxy, but clever applications and layered techniques can help make a variety of experiences. You become sensitive to quirks and trends in randomly generated values (Pitfall is very careful about what number seed it uses and where it starts the player, so that the beginning of the game has a nice difficulty curve). Dragon's Descent had a few "bugs" in how I generated the mazes, but since I got a nice difficulty curve in the initial few levels, and the mazes are still able to be completed, I kept in these quirks instead of "fixing" them. To be honest, my original outlined technique probably would have had the mazes feel a little too big. The lesson here is that you craft the algorithms to fit what you want, the same way you mix colors or light a photograph - there's an art to the process, as much (if not more) than logic and defined steps. I'll also say that PCG is a large, open-ended discipline, more of a partial design philosophy or possible set of techniques than a specific, solid thing. For instance. Most Roguelikes are almost defined by the use of PCG, but not all PCG is Roguelike. It could be as simple as a basic pattern, or could be a simulated universe. It's also a tool, or set of tools, mattering most in how they're used. When used poorly, PCG can make a game bland and boring, but when used well it can give a game vitality that would be impossible in any other way.
  6. Excellent - thank you both! I still have a ton of work to do, but it looks like I have rand() ported with the values I'm expecting. A function like this is easy enough to port from C to Java, so the code was understandable (with a function like this it's basically like converting from American English to British English). Ah! Returning a separate value that's different from the updated rand makes sense. I have the rand and rand16 seeds initialized elsewhere, and constantly use seeding for things like level generation, so they're separated from the rand() function itself. With the 16-bit version I often end up seeding them separately, or lock one while changing the other, which has proven handy a few times. -That- is good to know, and makes sense now that you pointed it out. I still have a lot to do, but being confident about the accuracy of rand/rand16 means I can focus on other stuff without worrying about the initial algorithms. I am indeed doing some porting (or at least testing how feasible it is), and keeping rand() intact is a crucial part of that process. This is also helping me get my feet wet with assembly code.
  7. I'm trying to port the Rand/Rand16 process used in batari Basic to Java, mainly so I can try some tests and visualization in some different systems like Processing (a Java scripting system at processing.org), and if I can get it to Java, I can probably get it to C/C++/C# etc. etc. The thing is that assembly is still a very large blind spot for me, so I would appreciate some help. I think I have the basic gist of what's going on, but I do have a few questions. I'm pretty sure this is the rand16 code used in batari Basic currently (found in std_routines.asm): randomize lda rand lsr ifconst rand16 rol rand16 endif bcc noeor eor #$B4 noeor sta rand ifconst rand16 eor rand16 endif RETURN Between adapting 8bit operations to a 32/64bit system and my own ignorance of assembly, there's enough places where I could be doing something wrong (to say nothing of being off by 1, or missing a digit somewhere) that I would appreciate some other eyes looking at what I'm coding Debugging random output is, by definition, tricky! I have a few questions about what's going on with the accumulator/bcc branching, etc. but I hope I can show my thought process with my current code here, attempting to do what "randomize" does. Some more context/things I'm dealing with in current Java: -A complicating factor is that integers are 32bit, so I lot of what I'm doing is "converting" rand from a 32bit integer to an 8 bit one. -In Processing, there's a function called binary(), which changes an interger to a string of 0's and 1's. I'm using this to get the "carry bits." I'm sure there are other ways, but I want a "paper trail" while I'm figuring this out. It's sloppy, but I want to get the code working before I get it elegant. //rand and rand16 are 32bit integers, and global int Rand() { char carryBit; char carryBit16; String carryString; String carryString16; int tempRand = rand; int tempRand16 = rand16; //shorten to 8 bits from 32, effectively convert to "byte" tempRand = tempRand & 255; tempRand16 = tempRand16 & 255; //grab the carry bits ahead of time, there's probably more graceful ways to do this but //I'm trying to make sure I have the bits before operating on them. 32bit value means //I need to grab the binary values at slots 31 and 24. I think this is right, they might //need to be swapped or offset by 1... carryString= binary(tempRand); carryBit = carryString.charAt(31); carryString16 = binary(tempRand16); carryBit16 = carryString16.charAt(24); //lda rand //lsr tempRand = tempRand >> 1; tempRand = tempRand & 255; //rol rand16 tempRand16 = tempRand16 << 1; tempRand16 = tempRand16 & 255; if (carryBit16 == '1') tempRand16 += 1; //bcc noeor //I -think- this what bcc is doing? Checking a carry bit and branching accoringly? if (carryBit16 == '0') { //eor $B4 tempRand = tempRand ^ 180; } //eor rand16 tempRand = tempRand ^ tempRand16; tempRand16 = tempRand16 & 255; rand16 = tempRand16; tempRand = tempRand & 255; rand = tempRand; return rand; } One thing I'm a particularly hazy about is the final "eor rand16" operates on, if we've already stored rand back in memory? If it's in the accumulator, is it still "saved"? Many thanks in advance from myself, a total novice at assembly code!
  8. Awesome - I'm looking forward to it! The 2600 version is very near a final version, so it won't be a "Work in Progress" much longer! I'll admit most of the updates are subtle, or "quality-of-life" features, like the game telling you your maze number when in random mode, or keeping track of the high score for each mode. I've been spending a fair amount of time porting the game to the 7800 (and experimenting with a few other platforms as well...) The default maze layout should be the same, so with a bit of practice and memory you might be able to defeat the midboss on level 3 and get to the final boss on level 7...
  9. The 7800 version does accelerate a little faster, one of the quirks of porting the game. A lot of it has to do with the different resolution on the 7800, meaning the screen/sprite/pixel proportions are different (the sprites are larger on screen in the 7800, which makes everything feel a little faster as well). I actually have to make the horizontal and vertical speeds different from one another on the 7800 to account for the more rectangular pixels.
  10. Latest build: DragonsDescent_2019_8_15_2019.bin I did a little bit of re-organizing instructions, and decided to animate the door (blinking with a key icon) to see how that works. The design is based on the fourth door, but my hope is that the blinking key symbol on top of the door communicates the "get key to unlock door" dynamic. It should also be within cycle count, although I'm paranoid since a few circumstances in the game get -very close- to hitting the cycle limit. I'll be testing on hardware over the next few days. That's strangely reassuring. Thanks for your response!
  11. I had some chess pawns mixed in with my tombstones and bread as well Warning, a minor design digression incoming, I've had some feedback/criticism from a few different places, and this has strangely been one of my few graphical stumbling blocks in the project. Since this involves how the game communicates a core mechanic, and since I love low-res pixel art, I'll go through my thought process in more detail than you might think a door/key dynamic would need at this level... The sprite can't even really be just a keyhole. It's even harder since it really needs to be a door PLUS a keyhole-probably a 4x4-6x6 keyhole with a box around it. It needs be be iconic, in the sense that it's 1) recognizable as a lock/door and 2) can't be easily mistaken for something else. 7x7 pixels might actually be easier in terms of design, since you have a proper central pixel and axes, but that also makes the whole thing a little off center and thin-looking compared to most of the other graphics. Really, here are the priorities, in order: 1. Needs to read as "door/exit/thing to grab with the right conditions" 2. Communicate "I'm locked/I need a key" vs. "You have a key, I'm open now" 3. Maybe look nice? At this graphical resolution being understood often better than being admired. I'm mean, it's best to be both, but...the more detailed/unique it gets, the more likely it looks like something else. This also needs to take into account that it has to be a monochromatic 8x8 sprite. Due to reasons of sprite layering/missile colors, the door also needs to be the same color as the player. Here are a few other variants I'm trying, including a change on the original "inverted key door" ( )which -might- be interpreted as a missing slot for the existing key sprite . The reason I wanted to change the graphic in the first place was to avoid confusion, but I want people to "read" the sprites as doorways/exits, or at least something to grab. The "bread" door is a little dull, but is least likely to be misinterpreted. One reason I didn't go with it originally is that it's missing a "key goes here!" communication in the design, and I'm only considering it now because I made room for an "open door" sprite. I'd welcome feedback in terms of how people read the graphics above. Do the other sprites read as doorways with stairs or passages behind them? Any preferences?
  12. A new version with different "Exit" graphics (including "locked" and "unlocked", depending on if you have the key or not). On a possibly related topic, it's really hard to make a keyhole that doesn't look like a tombstone in 8x8 pixels. I'm hoping to be finalizing the game itself: DragonsDescent_2019_8_12.bin
  13. I've been working on a lot of game-related stuff besides/around the code - cover art, instruction manual, things like that. I just posted this in my 2600 thread, and it's tentatively for my 2600 version, but this is a potential cartridge art design that might be shared between the 2600 and 7800: The above image is basically what happens when I listen to too much power metal while looking through archives of early 80's arcade marquee art. I'm not a good enough illustrator to properly mimic the classic Atari oil/airbrush/montage style the company used for a lot of their titles, although I might try making an "Activision rainbow contrail" style cover version for fun and see how it turns out. As far as my aesthetics and inspiration for the game go, I imagine "Dragon's Descent" as a the type of game that would have been released and forgotten about in the arcades during the Great Videogame Crash of '83, one of the last of the "Second Generation" games, an instant before scrolling graphics and the genres that used them came to dominate. While there were a lot of bad games, hardware, and decisions at the time, there were also a lot of unique games and ideas that were floating about. The 7800 seems placed in that same spot (even if it's technically a 3rd gen console, in design and paradigm it's in an odd transition between the NES, SMS, and the earlier Atari/Coleco/Intellivision systems), a strange place of possibility, forgotten potential, and roads not taken. While I might be making a few adjustments, most likely on the music, feature-wise I feel like I'm in a beta/bug testing phase at the moment. I still don't have a good way to play the game itself on an authentic 7800 myself - the closest thing I'm doing currently is testing with a genuine controller, 9-pin adapter, and MAME running a7800 on my dev machine or a RetroPie. I'll hopefully be having a few friends test the game in similar circumstances soon.
  14. I've been working on all the stuff peripheral to the actual game code. For instance, after looking at a lot of early 80's arcade marquee art, while listening to way too much power metal music, I ended up with something like this for potential cartridge art:
  15. Revontuli

    Dragon's Descent

    Screenshots from Roguelite/action game
×
×
  • Create New...