jrok

Yeah. It always struck me as a sort of "eh, good enough" effort. They came up with a special effect and one mindlessly simple game mechanic and then kicked it out the door. Not sure if it was lazy programming or a ridiculous delivery schedule or both, but the difficulty curve in Laser Blast is so flat it makes Mary Tyler Moore look like Dolly Parton. You could just play and play until you starve to death or go insane.

Yep, I noticed that one to. It's on my list. Thanks for the ideas. Color palettes are far from final at the moment, and I'm sure they'll change a lot before I have a stable release candidate. I think low lum for night is pretty much a given, and it may even revert to black. But I, uh... I've kinda got bigger fish to fry at the moment. Yep, that's right.

Interesting. Maybe I will keep straight-shot in as a variant. It does contain a tick. If you look closely, you'll see that waves 11-20 have a line drawn under the number. Waves 21-30 will have two lines. This method of numbering is probably not going to change, since this is one of many ways I'm trying to conserve memory. I'll bet it was near the top of the screen when you shot it There were times I could've sworn I killed the dragon before he ate her, but he most certainly did. Maybe I can put in a "Princess eaten" sound effect to avoid confusion. No, definitely not. Even if I could find the resources left to do it, there's no CPU time left to do it without sacrificing more gameplay. I know it sounds simple to implement since I did it before without the chip, and I agree that it might be useful (especially the part about knowing castle health states at all times.) But, again, I would have to sacrifice something to do it. Part of what I didn't like about the original version of the game was that it felt like it was "all-hat-and-no-cowboy." The player had all this GPS, radar and satellite data showing them how to hunt down and kill... two enemies. Now, at least there are three simultaneous foes, plus a princess to rescue. If I reduce the number of enemies to two again, I feel like I'll have defeated the purpose of trying to use the DPC+ chip to bolster gameplay in the first place. I think I found that version (or something close to it), but I won't have time to bugtest it until I'm finished with this one. Cheers, J

I think I've just been playing it too much, so my perception of the difficulty ramp is skewed. Although, I wonder if I'm communicating certain things well enough in my instruction docs. One really crucial point is that "pressing" the fire button does not shoot the arrow; it just draws the bow. Releasing the button shoots the arrow. Holding the button down also engages your lance when you reach top speed (by holding left or right for about a second), so I notice I spend far more time holding the fire button down while playing then mashing or pressing it. Don't know if that helps or not. I think I can squeeze it back in. My main problem is making sure it doesn't override other mission-critical sounds (like, for instance, the sound of the dragonfire that is used to gauge the dragon's proximity). I'll experiment and see if I can bring it back in the next build. Not sure. I really don't think so. P1 wraps at screen edge in the display kernel I'm using, so if the didn't disappear before the edge they would instead appear at the opposite side of the screen and then disappear. I understand that Batari incorporated some form of sprite masking into his latest display routine, but unfortunately I don't think I can use it with this program (and even if I could, the sprite is resized, which I gather would present other problems) Actually, that's not true. No levels end the instant you kill all dragons. This was a revision in place since my 8/10 build: "New play mechanic: After destroying all air enemies (Dragons, Wizards), player must defeat a road enemy (Knights, Grendels) to advance to next wave." It's not just Grendels; after you clear the sky of enemies, a short tune plays indicating that you need to clear the road to advance to the next stage. I put this mechanic in place to avoid having "cowards" play the entire game while avoiding the road enemies After you hear the tune, kill whatever creature (Knight/Grendel/Other) remains on the road and you'll reach the next wave. Thanks! I sort of wanted to expand on it, but I have precious little space left for graphics, and I want to reserve it for a few more bosses and color changes. Just a placeholder right now. Eventually it will cycle through game options. Thanks for the ideas. As far as the "shoot forward/ shoot up" powerup, I need to investigate this further. My problem is that I'm currently trying to play the game with "shoot directly up" in place, and so far I don't really think of that as a powerup. In fact, It actually seems to be hindering my game performance so far, causing me to get hit with far more dragonfire than usual. Maybe this is just a result of me playing the game exclusively with the forward-angle shot up to this point, so I'll play a few more games tonight with the straight shot and see what happens. Meanwhile, I've attached a version of the latest build with straight-shot turned on, so maybe you can do some playtesting of your own and let me know how it affects your own performance, whether positively or negatively. ChargeDPC_straightshot.bin [EDIT] Okay, I just completed my first game with "eagle eye" on and I have to say that I SUCK at eagle-eye . Seriously. Usually, by the time I face the first Wizard boss, I'm usually flying with four reserve lives and fully stocked castles, and I usually more or less cruise through him like a hot knife through butter. This time, I faced him with one life, he massacred one of my castles, and every time he was on the screen I felt like a kamikaze pilot on a suicide mission. And, really, I was, because he finished me off. It was the first time in a very long time that this sucker killed me. BUT... that might just be due to my personal play-style. Now I'm really curious if you are going to cruise through the levels with this experimental build, maybe by playing the game in a very different way. Post scores, levels and pics. I'll keep playing this version for awhile too, to see if you're seeing some unique angle of gameplay that I missed while designing it. Cheers, J

I have a question for any programmers here with experience modifying the batari DPC+ display kernel. I'm curious how feasible you think it would be to modify the canned display to draw two restricted GRP0s instead of one unrestricted GRP0 (by feasible, I mean both from a timing standpoint and also from the standpoint of modding the existing kernel as opposed to writing a new one from scratch). I'm basically trying to find a way to reduce flicker in my program as well as create a bit more flexibility for the player-controlled sprites' max vertical range of movement. I drew up a couple of quick diagrams to illustrate what I had in mind (forgive me if I'm over-explaining, but I wanted to get it all out there in case someone could think of a simpler way of accomplishing the same goal): Current sprite display: P0 (yellow) draws the front half of the Paladin. P1 (white) draws the Soldier, the Castle and the Dragon/Falling Princess. All "restrictions" I cite in the list below are just indicating that I've manually restricted the sprites in my own bB script, and I included the max height of the sprite in their vertical display limits. The Paladin is restricted between y136 and y152 (visually, the top and bottom of the gray "road" area), and is manually flickered with enemies on the road who are similarly restricted. The soldier is restricted between y112 and y128. The Castle is restricted between y60 and y92. The Dragon is restricted between y8 and y76. Currently the Dragon's registration point can move vertically between y8 and y42 without triggering the auto-flicker routine, but in order to capture the Princess, it must overlap a castle and therefore flicker. The same virtual sprite is used to draw the Falling Princess after the Dragon is killed, which is restricted between y8 and y114 and must overlap two other GRP1 sprites during its fall. Proposed sprite display: P0 draws the front half of the Paladin and the Castle, with a minimum separation of 16 scanlines between the top of one instance and the bottom of the other. P1 (white) draws the Soldier and the Dragon/Falling Princess. The y restrictions for the sprites could be loosened a bit in the center of the screen, allowing for a taller "road" area within which the Paladin can dodge and joust. The Castle's virtual GRP1 sprite (P1_1) is exchanged for a second P0 sprite. I multiplexing flicker routine for this sprite is not necessary, since the closest the top of P0_0 and the bottom of the new P0_1 will ever get is 16 scanlines. The Dragon could capture the Princess flicker-free, and the Falling Princess would only have to trigger one, much smaller duration of flicker during her descent. Thanks in advance for any guidance, Jarod.

*Update* Now that I've survived Irene's wrath and am allowed back in my apartment, I've been putting the ROM through the paces on my Harmony cart, and getting lots of interesting insights as a result. Colors: Many of my higher lum colors are translating as white (at least, to my eye) on my CRT, so I've darkened some of them considerably in this build. For some reason, my landscape sprites (trees, castles) are glitching a bit on brighter backgrounds. The only background they seem to render normally over are my nightscape (solid $50), whereas other backgrounds seem to reproduce colors from the previous line on blank lines in the sprite. Controls: I think I'm playing the game fairly well with my joystick, averaging in the 2200-2600 score range and reaching around wave 16. However, I'm designing the game towards 30 static waves (+ endless "special" waves), so I think maybe I need to peel off an extra bit or two to allow for more bonus men at 2000 and 3000 pts. Either that or I need to find ways to ramp up the difficulty more slowly. Added a reset function to the reset switch that boots to the title screen. Graphics: For the most part I think the graphics are translating okay, and even the manual flicker for the road objects doesn't seem bad to me (though I'm considering messing around with the color of the Paladin's horse). One thing I'm curious about is whether people think that the flicker is decent enough to make it continuous (Paladin flickers whether or not a road enemy is on the screen). It might allow me some interesting options. One particular game element where I'd like to reduce the flicker is the Princess capture/fall routine. There is a lot of virtual sprite overlap involved, particularly when the Princess is falling past the landscape and soldier sprites. There seems to be a bit of delay in drawing the pfscore playfield bits, (not a big deal, but I'll try to explain it in more detail later in case it's an unreported bug). ChargeDPC_090211.bas.bin

Me too, surprisingly. I've been playing the heck out of it on my new Harmony lately, and I've been regularly making it to level 16. Yep, that is supposed to be their main function (a bonus opportunity given for keeping your castles healthy). I've been experimenting with colors quite a bit ever since I got my Harmony and have been able to see them rendered with genuine TIA-to-CRT. There may be many color changes coming, as certain color shifts seem to be causing a few graphics glitches.

Yes, it should, but there appears to be a bug in the "pull #-#" code. I'll submit it to the bug thread shortly. In the meantime, you can substitute "push a b c" and "pull c b a" instead, and it will work as expected. Yes, that's what I've been doing as a substitute. I guess it's really not a bug in that sense, more like an incomplete feature You were doing it right for a single value. 2 things to keep in mind: (1) the stack grows toward 0. (2) the stack pointer always points to the topmost element in the stack. So when you push a single value onto the stack at position 100, the new element goes on top of the element 100, at position 99. When you want to pull it, it needs to be from position 99. (after the pulling, the stack pointer will point to the next lower slot, at 100.) If the stack pointer was at 100 and you push 3 values on the stack, when the operation is complete the stack pointer is 3 elements closer to 0, at 97. When you pull 3 elements from 97, they are "removed" and the stack pointer winds up pointing to the 100th element. Clear, or no? Yep, perfectly clear. Thanks!

FYI, this doesn't seem to work quite as I expected (and maybe I'm just not thinking about it the right way). The stackpointer seems to work fine, but I thought "pull a-c" was intended to pull the range of a,b, and c starting at stack 197. If that's the case, shouldn't the following altered version display "040208"? set kernel DPC+ set kernel_options collision(playfield,player1) set optimization inlinerand dim sc0=score dim sc1=score + 1 dim sc2=score + 2 temp1= temp1 goto Start bank2 bank 2 temp1= temp1 Start scorecolors: 12 12 12 12 12 12 12 12 end a=4 b=2 c=8 rem ** save "abc" on the stack temp1=100:gosub setstackpointer push a-c rem overwrite "a" a=0 b=0 c=0 rem retrieve "abc" from the stack temp1=97 : gosub setstackpointer pull a-c rem the score displayed should be 080000 sc0=a sc1=b sc2=c main drawscreen goto main setstackpointer asm lda #<(STACKbegin) clc adc temp1 STA DF7LOW lda #(>(STACKbegin)) adc #0 and #$0F STA DF7HI end return thisbank stack-variable_multi.bas EDIT: Actually, I'm a bit confused about how defining a range works with stack access. The only way I was able to get the stack to work in my RPG program was by reading the stack value directly after the location I wrote it to (for instance, I would push to stack 100, but pull from stack 99.)

Thanks! Let me try to see if I can incorporate it into a program and hopefully it will demonstrate the why. Basically, it is actually a bit like popping from an array. In the turn-based RPG game I've been trying to write, each player (or monster) needs to retrieve 8 bytes of RAM from the stack for use during it's "turn." Instead of a static round-robin, I wanted to try to create a sort function to determine the order of turns, so that characters and monsters are ranked in order of initiative at the beginning of a new "round", and then move in that order. The rankings would change based on conditionals (like, for instance, the relative speed properties of the monsters, whether Grog the Barbarian got bonked with an "Super Slow-Mo" Spell, etc).

No, I understand that. What I was trying to ask is whether the location in the stack at which that range begins to read/write can be assigned to RAM. For instance. dim stackpointer = d rem ** save a,b,c stack stackpointer push a-c rem ** save a,b stack stackpointer push a b

I suppose something like that could be added eventually, as a bit of spit polish. Or maybe a button press can be required at the end of each character's turn. Yeah, I think the trickier part will be tracking the status and locations of off-screen monsters throughout the dungeon, and determining how many total objects (monsters/items/treasure) can inhabit a room simultaneously. This shouldn't be a problem for treasure/items, or for "guard"-type monsters who don't leave their origin rooms, but "wandering"-types will require a bit of memory juggling. Also, keeping track of inventory will require some thought, especially if it's going to be accessible on the main game screen, rather than switching to some sort of "inventory" screen to select items.

This is sort of a two part question. I was curious whether or not it would be possible to create a variable stack pointer? In other words, something like: dim myVar = a x = 187 stack 188 : push myVar (...) stack x : pull myVar I know that the above statement won't work (I mean, it will compile, but it won't retrieve the value at 187), but I was curious if there was a method that would do something similar? The second part of my question is that, if a variable pointer can be used, can we then write a function that points to a location on the stack, and then pulls/pushes a block of contiguous stack data (perhaps with a for-next loop)? Would it help to give a specific example of what I'm trying to do?

Here's a new version with the following changes: You control three adventurers instead of two: A warrior, a wizard and a rogue. Very simple "combat" added as proof of concept: Enemy stats are loaded to and from the stack, but for now only the hit points and armor are actually tested. To attack an enemy, just move into it. Each attack costs one action point If the attack is successful, you hear a high pitched "chop" sound, and the enemy loses a hit point. If you miss, you hear a low-pitched whump. Once the enemy's hit points are fully drained, it is cleared from play. The combat mechanic right now is a very basic "8-sided dice roll vs. armor rating" test, but eventually it will be modified by stuff like weapon ratings, attack skill and other conditions. I think I'll try to get basic enemy AI and turn structure done first, though. After that, I suppose I'll have to address map creation and movement. I'm thinking about going with static placement first, and once it's running solid to go back and build in randomized map/door/monster generation. The graphics are all placeholders for now... even though I'm a bona fide "sprite nerd", this is one project where I simply don't care about them, and probably won't until the very end Cheers, J DungeonRaid_demo_082211b.bin In other news, got my Harmony Cart today! :thumbsup:

I don't think I've made it past level 9 yet. The difficulty is why I liked your idea of adding in health bonuses for the player or castle. I think I'll experiment with some sort of health bonus that presents itself during a wave (i.e. not the auto-bonus you get between waves). I also get the feeling a respawn timer would also help make the difficulty ramp-up a little smoother. This is actually a "night" level, not sunset... maybe the color looks different on your TV? But yeah, I cycled through. Each 10 levels equals a "day". So if I had managed to kill this last Grendel, the next wave would have shown a sunrise. I think that the final game will consist of three days (30 levels), plus some kind of "nightmare mode" for levels after 30.

I suppose this could be played with one joystick, too. Maybe clicking the right joystick fire button could just switch between the map display and the items? Why not just jump in and start programming? Then, you could help out with beta testing while programming your game.

Question to people playing the latest demo: Out of curiosity, and to help gauge difficulty and the scoring mechanic... how are you doing? I just had what I thought was one of my best games so far, getting up to level 17 with a (comically ironic) score of 2084. This represents a very good game for me (I think I average around level 14 with 1500 pts). I'd bet that if I really concentrated on the game itself instead of half-hunting for bugs, I might be able to do even better, but I feel like it starts getting pretty rock-hard in waves 12-20. But maybe I'm living in a dreamworld? For people playtesting the latest ROM I've posted, what's your average level/score? Cheers, J

I've shelved work on "Charge!" until my Harmony cart ships, and in the meantime I've been playing around with the idea of an RPG. I've never been much of an RPG player, but this thread got me thinking that there might be some opportunities to make a simple-but-fun one for the VCS. I also thought it would be a good opportunity to try to develop a DPC game that was more reliant on the stack, and maybe even something we could work on as a community project. Here's what I've come up with so far: Controls: Right Joystick - Move the active player in four directions. Each move diminishes the "Action Bar" beside the Inventory. Once all moves are complete, the focus shifts to the next character in the player's adventuring party. Left Joystick - Move the selection cursor (yellow line) to highlight an item from the inventory to use, or change/use the current character's armor and weapon. When an item is selected (by pressing left fire button), use the joystick to move the targeting cursor to the desired target. Left Fire Button - Equip/use the item the selection cursor is currently highlighting. First press readies the item and brings up the targeting cursor (blinking blue square). Second press activates the item. Right Fire Button - Cancel item equip/use (eliminates blinking blue targeting cursor) Dev Notes I'm thinking gameplay would consist of selecting three characters of any class (using mostly generic fantasy archetypes like "Warrior", "Rogue", "Wizard", etc) to embark on a quest for treasure and kill-points. Currently, the program stores to and retrieves from the stack the following properties: Character Class, Brawn, Agility, Knowledge, Hit Points, Weapon, Armor, Inventory1 & Inventory2. Most of these are not doing anything useful right now, but when the character focus shifts between your two party members you will see that character's weapon, armor, current hitpoints and inventory loaded from the stack into the bottom part of the display. The idea of switching out the inactive player characters graphics with playfield pixels is to reduce flicker (either manual or via batari's built-in multiplexing). Ultimately, it would be great to switch in GRP0 graphics on the fly, so that whichever character (whether a player-character or enemy) had the focus would be able to move unrestricted and flicker-free. It might also be a good idea to develop an AI that would avoid placing more than two enemies/items in a row at any given time... but that's neither here nor there at this point. To demonstrate the stack feature is working, you can try walking into any of the enemies. In the full game, this would trigger a combat test, but for now it just depletes the current character's hitpoints. I'm hoping to use the stack in a similar way to load the stats and inventories of on-screen enemies during their turns, and carefully pull up the relevant stats of targets whenever necessary. The Equip/Use does nothing right now, except to demo the interface itself. The idea is that the left joystick/fire-button is used for equipping and using items and missile weapons, while the left joystick/fire-button is used for moving the characters around the map. The source is still lame and uncommented, so I'll have to clean it up a bit before posting. One thing that I've been trying - and, so far, failing - to do is to adapt SeaGTGruff's inventory strip for the DPC. The inventory I cobbled together for this demo is clunky and extremely limited, but a more flexible one would probably enhance gameplay quite a bit. Frankly, there's enough gray-matter flowing around these parts for lots of nice features (Savekey, Vox, etc). For now, this is more of a mockup and food-for-thought than a true demo, I guess. But part of me feels like together we come come up with a fairly badass VCS RPG. DungeonRaid_demo_082211.bin "What do you think, sirs?"

Thanks! It's been a dream project of mine for a few years now, and I think it's finally starting to look and play a little like it did in my mind, thanks to batari, Spiceware and everyone else who worked on the DPC+ schema.

Actually, this version is a little better example of what I was trying to show. Basically, the top 80% of the screen would be reserved for the tactical room display, with the bottom twenty showing things like inventory, current weapon, armor, hit points, etc. In this version, I swapped the movement counter from M1 to the bottom rung playfield row (the bar shortens by one pixel with each move). DungeonRaiders_rev.bas.bin I guess this stuff isn't very roguelike, though. This would play more like an old RPG game.

It's really very helpful, but I've been thinking lately that I shouldn't be leaning on people just to test hardware state. I'd rather but something up that I knew for sure was stable, so people who downloaded could just playtest and have fun! Cheers, J

*Double-post, sorry*

Actually, this version is a little better example of what I was trying to show. Basically, the top 80% of the screen would be reserved for the tactical room display, with the bottom twenty showing things like inventory, current weapon, armor, hit points, etc. In this version, I swapped the movement counter from M1 to the bottom rung playfield row (the bar shortens by one pixel with each move). I guess this stuff isn't very roguelike, though. More like an old RPG-style game.

Well, the topic was "roguelikes" so I figured we were going for a "Rogue" feel. Hence, trying to get all the play data on one screen. If the object is to go full-on dungeon crawler with multi-party characters and such, yeah I agree. A fullscreen tactical view of each room (perhaps with an automap on a secondary screen) would be the way to go. If I were apporaching the project, I think one of my big goals would be to get as much unrestricted loot and enemies in each room using minimal flicker. I've thought about this a bit and mocked up a ROM with sample movement. In the attached binary, you alternately control a Warrior and a Wizard. When one is active, you will see a "Move Meter" at the bottom of the screen that gradually fills up as you make moves. Once the Warrior's meter is filled, it's location is marked by a playfield brick, and it becomes the Wizard's turn (and vice-versa). For expanding it to a game, I'm thinking that the GRP0 would always display the active player character (or active enemy character, during their own turns), with everything else represented by GRP1 or a pf brick. The flickering square in the top left corner could function as a cursor for spells, ranged attacks and other target-area actions. The bottom areas where the movement meter and the score are positioned could variably show different kinds of relevant game information (for instance, the score could probably function as an inventory that changes to show what the active character is carrying.) DungeonRaiders.bas.bin

Another way to approach the game as a single screen might be to go with 2-6px tiles, and use two-wide game objects instead of four. From the looks of it, the Rogue display is 64 characters wide, so each of bB's 32 4-wide pixels would represent two horizontal positions. With that setup, we could get the full map on screen, and have plenty of vertical space left at the bottom for stats, reporting and inventory: Here's a ROM with basic 2x6 grid movement. Rogue_sample.bas.bin