jrok

Using just one of the "canned kernels," you could program the inventory display as a separate screen from the map display, using the players to draw the inventory items. The simplest way to do it would be to position player0 and player1 side-by-side in the center of the screen (but not necessarily right next to each other-- they would look better separated), such that each player is a column running up and down the screen. Then you can define each player as a "stack" or column of items. In other words, you might have 16 objects on the screen at once, arranged in 2 columns, 8 items per column. You might even have several screens for the inventory-- one screen for the weapons, one screen for the armor, one screen for magic potions or wands, etc. I've never played "Rogue," but I've played "ADOM," and that's how the inventory is listed-- items are grouped together according to type-- so you could draw the inventory as a series of screens in the same manner. You could use the GAME SELECT console switch to call up the inventory and paginate through the different inventory screens, and use the joystick to select the items you want to use, with either the missiles, ball, or playfield pixels being used as cursors to highlight the items which are equipped. As for the map screen, you could use the score (with custom score graphics) to show stats, or maybe to show the equipped items. Michael That's sort of what I was thinking, too. No need to include the inventory on the same screen in a turn-based game. Also, probably no need to waste color clocks on "walls." You can use negative space to define rooms and hallways (rooms/hallways are black, everything outside is color) and thereby save eight px on each room both vertically and horizontally (at least, in the example PACMAN RED provided; depending on the screen res, it could be even more than that). It may not sound like much, but when you are fighting for every pixel, it adds up! It might make more visual sense, anyway, to have the movable areas all the same color. Also, I think 4px players would be fine, in order to maximize the movement grid. You can make a lot of letters/symbols in 4px, which is all a roguelike seems to require. I think the project is very doable, and that a keyboard probably isn't necessary to get the flavor of play.

Yes, great point. It's easier in some ways to think of the display kernel as something that is accessed and modified by the Basic script, but it's all "the kernel." And above, I meant to say "I think that a lot of folks understate what can be done with the language." I mean, I think that if you approach it as you would any other Basic-type language, it can offer lots of opportunities to make some really neat stuff. But I guess as with any other dev environment, having some prior programming experience (professional or otherwise) probably helps.

Have you played any of those games? If you play through the 'story,' it's the same old thing. If you fail a mission, you must do it all over again and again and again until you complete it or you won't be able to continue. Oh but you can do them in any order you want, though. That's the important part, right? Nobody "leading you through dance steps." But I thought you said there was NO right answer? You just shot yourself in the foot. HOW MANY BONUS POINTS DO I GET FOR THAT?! FOOT SHOT BONUS = 10,000 PTS, RIGHT??!! 1. You say that all the time. 2. One man's frustration is another man's challenge! You've also said that games shouldn't have scores, and other stuff I disagree with. It's no biggie. I just think YOU ARE HITLER AND SHOULD BE STOPPED AT ALL COSTS, UP TO AND INCLUDING TIME-TRAVELING CYBORGS. I guess it's not a big deal, but sometimes it seems like you're trying to give your own ideas the color of authority. Not saying you are wrong, just engaging in the marketplace of ideas EDIT: P.S. I agree that Dragon's Lair smoked the long pole down to the base. But, as Scumsoft seems to imply, the market disagreed with me. Novelty is a big part of game design, and not necessarily a "bad" part.

Yes, I did. And I agree with him. Read those again, and, yeah, still looks like your brought it up. Sounds like Sherlock Holmes... "The game's afoot, Watson." Neat! Sure they do. That game is called "Grand Theft Auto III." It's got a lot of organized randomness, a sandbox world, no score, low stress... and it mostly stinks! Oh, and it has about a million clones, including some starring Spiderman. They all stink, IMO. And while I agree with a few of your notions, "player-abuse" is one I disagree with to my core. Many people *thrive* on stress. Otherwise, there would be no O.R. surgeons, or astronauts. In fact... since the conversation now seems to be about making grandiose statements... I'll say that confronting a stressful (albeit simulated) situation and the joy you get from overcoming it is the soul of ALL games. Football is a war without bullets, and chess is a silent debate at the end of the world. In that spirit, here's a quote for you: "Without STRESS, there is no game." - jrok, 2011

I think there's a misconception out there that the batari kernel is somehow hobbled, but it's really not. There are three kernels in release now (standard, multiplayer and DPC+), lots of minikernel contributions, RevEng's titlescreen kernel, etc. Also, programmers can use assembly language inline with their BASIC scripts. I think that a lot of folks overstate what can be done with the language.

There are plenty of way to generate an inventory with bB, simple or otherwise. Not that it's the only way, but here's one that demonstrates an on-screen inventory using the score sprites. Of course, that's only if you need the inventory to be on the same screen as the map. With multiple game screen to toggle between, you have many more options of displaying an inventory. "Dungeon" springs to mind.

I think *this* is closer to the mark. No, the VCS is not ever making a hardware comeback, just like horse and buggies aren't making a comeback. But the "retro soul" can certainly make a comeback, from the software side. I can envision a game company that uses next-gen hardware to deliver games that "feel like" out-sized 8-bit games. To use an art analogy, this would be sort of like how Rembrandt was eventually supplanted by abstract expressionists like Rothko, or the way a filmmaker like Lars Von Trier restricted his work to the "Dogma 95" rule set. As long as the revolution is software-based, it has a chance of being "televised."

Alright let's get something straight. It doesn't matter how many quotes you throw at it, or how many times you criticize games by calling them "toilet paper" or whatever. There is NO right answer to the question of what constitutes a good game. And it does smack of 'proselytizing', since this thread has little to do with which game was the "best" from a design standpoint. Frankly, you could approach a game with the purest "philosophy of game design" and still produce a terrible game that nobody in their right mind would want to play. And there are other, perfectly valid approaches to designing a game. For instance, there is the Man vs. Machine school, which most of the arcade fanatics like myself here will probably identify with. That's the one where you test your focus, your memory, your reflexes and your nerve in a (usually hopeless) attempt to master first the controls, then the programmer and, finally, the hardware itself. Think John Henry vs. the Steam engine, or Garry Kasparov versus Deep Blue... or, heck, Sarah Connor versus the Terminator. Yeah, yeah... that's "all work and not play" and "if I wanted to take a test I'd go to school," etc. But Man vs. Machine also is genuinely absorbing, and often more rewarding. You (constantly) claim there is no enjoyment to be found in trying to get close to perfection in a video game by getting the higher score or the faster time, but trillions of quarters and nearly a half-century of history proves you wrong. Many of us find pleasure in solving puzzles, following "dance steps", and discovering tricks and exploits that the programmers overlooked (great programmers are, I think, somewhat like great jazz artists in that the imperfections sometimes make them shine). Regardless of the game logic, there is a unique satisfaction in finding ways to last one more second against a machine designed to stop us from winning. For many of us out here, there is a legit thrill in achieving the high score and then carving our digital initials in the leaderboard. In fact, the thrill of competition (between ourselves and each other, between ourselves and the machine's algorithm) is a big part of the fun in ANY game, whether the challenge is randomized or not.

Hahah, yeah I'm sure I won't. My wife, on the other hand, is going to kill me, which might slightly hamper my development process. Hmmm... Well, in that case, I'm guessing that I'll have to finish writing the game in bb1c. I'm pretty much sure that I don't have enough time to do my vblank stuff during vsync, and there's no ROM space to put that code in the kernel bank. I think that might be okay, though, so long as everything else is relatively stable. Sounds neat! Yeah, I'll be happy to help out once I'm all set up.

There's a lot more snark in this thread now than is probably warranted (sorry for contributing). I think the real point is pinning down the potential VCS market with some degree of accuracy. Here in 2011, it's just not a mass-market retail product. At best, it's a boutique market that will cater to a small buyer-base with a unique taste and the willingness to pay premium prices to satisfy it. That means traditional manufacturing and advertising models are impossible (too expensive), and distribution is completely digital. Even within that market, demand will likely be small and hard to gauge. It's not hardware that you're selling: it's nostalgia. Not that "nostalgia" is a bad thing, or unsaleable, but it's very delicate and fleeting. It's true that there's a lot of 80's retro nostalgia out there (go figure, with the state of global finance), and even retro-tech nostalgia, but how much of the total interest does a VCS represent? Also, it's important to remember that even though the tech savvy of the average person has gone up over the past couple of decades, for most people video games are things that come out of "magic boxes." They don't know how the stuff is getting on that screen, and largely don't care. They only care about the stuff that's coming out. Despite Apple's best efforts, Earth is a software world. Delivery systems don't matter; content does. If the idea is viable at all, maybe a "nostalgia" brand of products, with multiple offerings, would be the more appropriate biz model. You call the store "1984" and (attempt to) offset the costs of manufacturing the expensive hardware with relatively cheap merchandising (clothing, mugs, keychains, lunchboxes, cassettes, etc) and sell the "80's lifestyle" rather than a particular good or service. In that model, a profit might be possible... that is, until you run afoul of the biggest, baddest "Boss Monster" of modern human history: LICENSING Licensing agreements will stomp you into the dirt. Someone "owns" everything you could think of that might spark a nostalgic purchase. Not only do they own it, but they own the book, movie and game rights to it, and have several projects "in development." They will sue you even if you get within ten miles of their license.

Its frustrating when you don't have the real hardware to test on and have to rely on 3rd parties for bug reports . When I started out developing for the 7800, stuff would work in the emulator but not on a real machine. It wasn't until I got a CC2 that I could test my code on the machine myself. Maybe you should think about getting yourself a Harmony cart so that you can tinker around with the code at your leisure. It would definitely ease your frustration . Absolutely. In fact, just yesterday I put out some inquiries to try to get my hands on one (EDIT: Duh, just realized I could order one direct from Fred ). Right after I did, I realized I was finally getting serious about this hobby. I've been tinkering around with the software side for a few years now, but I'm finally starting to feel like I can make something fun to play that I'm proud of, and I think I'm ready to invest more than just my time. [EDIT] ORDER SENT! Soon, I won't have to bother you fine people about hardware testing (and hopefully I'll be more helpful on general bB bugtesting from now on ). Cheers, J

Maybe I could change the knights to cars, change the road to the L.A. Freeway, rename the game "Earthquake!" and call the bouncing "a feature, not a bug" . The Yellow would fit right in with the sunny California theme. Actually, it's not just yellow. As you advance through the game and new background tables are read in (for sunset, night, etc), the color of the score row changes as well, though I'm not where those values are coming from. They don't seem to correspond to anything in any of my color tables. I tried two experiments to see if I can pin down the bug. 1) In this test, I simply reverted to the most patched version bb11c for compilation, without making any code changes. VBLANK jumps to bank 5 to get its code: ChargeDPC_bank5.bas.bin 2} In this test, I kept the compiler at bb1c, but put my entire vblank routine back in the bank 1: ChargeDPC_bank1.bas.bin Not sure if this will fix anything, but it would be nice to rule it out. If not, my other thought is to define DF6FRAINC every frame, instead of just once on boot. -J

Technically, no it wasn't. But I believe it's a stretch to say it has no arcade lineage. Aw, come on. I know that it "started" as a Star Castle port, but it mutated into it's own thing long before it hit the shelves. Differences between Yars' Revenge and original SC include: Energy barrier. Zorlon cannon Does not cost $32,000

Gotta be Yars' Revenge. Classically cockamamie Atari-story about hyper-intelligent space flies versus aliens with names that sound like asthma medication, all to describe four game objects on a black screen. Also, the Yar sprite appears in other Atari games, has no arcade lineage, and could get as addictive as pure Colombian cocaine when you're on a roll. Either that or the Combat pack-in.

I was playing this again today, and thought it might be kind of interesting if the damage the player takes from a collision scales with the player's velocity at impact. In other words, the faster the player is moving when it hits a wall, the more damage it takes.

Can DF6FRAINC have a different value than DF4FRAINC? I wasn't clear about the from what I've read. For instance, could I have a playfield res of 11 and a background res of 44 (which is how I've got it set up now)? I just did a count, and I noticed that my tables do seem to be off by a byte (45 bytes instead of 44). I added the last byte to color the score area... I think I did it by accident at first about a month ago, noticed that it colored the score row in Stella and then thought "Oh, that must be an undocumented kernel feature." I deleted those extra bytes. Hopefully, that does the trick: ChargeDPC_bgfix_1.bin

Agree about retailers. Forget it. They'd rather stock shelves with Pokemon-themed Napkin Dispensers than VCS hardware and cartridges, and probably have a better chance of movin' them. If the distribution was purely electronic/catalog, with manufacturing handled by North Korean dungeon prisoners, then maybe there's a slightly better than 0% chance of creating a profitable business model. But then you are left with a depressed economy glutted with gear that could deliver every 2600 game ever made simultaneously during a loading screen for Mortal Kombat 27 or whatever. The VCS console is primed for the "Antiques Road Show", not mass distribution.

Could you describe the ruckus background-bounce, sir? I'm just curious if it looks similar to the score-bounce that RT described in this thread. I'm just looking for clues. I'm not sure how to hunt the bug down because, unlike the score bounce, this one doesn't turn up in emulation, and doesn't seem to be cycle-related since it sounds like all other display objects are stable. I believe that the only things I'm doing differently in the bouncing builds is 1) using bb11d and 2)doing a bankswitch to run my vblank code (actually, this is directly related to "1" because bb11d's kernel doesn't leave enough space to run the routine in bank 1.) Thanks for the help! - J

New Version: This is more of a debug build with nothing much new in it. I'm mainly hoping that this version fixes the bug Scumsoft mentioned that causes Harmony to crash when the knight enemy enters the screen. I don't expect that this binary will fix the "background bounce", though, since I don't know what is causing it yet. Fixed the missile0 flicker, so the arrow should be a stable black now, and show up more clearly on real hardware. Fixed a bug that occasionally prevented the player from charging during Repair Phases. Reduced some of the occasional instability that happens when a flying enemy and a castle are both on screen, but it's not totally squashed yet. Fixed a bug that let you "catch" the Princess even if you weren't positioned at the topmost part of the road. ChargeDPC_081611.bin

I wonder if the background-bounce issue is related to switching over to bb11d (those two builds were compiled in d, while previous ones were compiled in bb11c)? I think I know what the crash issue is, though. I was trying to do something a little tricky during vblank to save some time in this build, since I was running late again. I'm not quite sure I'm savvy to what you're saying. In my program, I only draw my screens in the second bank, after returning from subroutines in banks 3-6 with "return otherbank" commands. So if I have a subroutine in bank 4 with a bunch of returns in it, are you recommending replacing my returns with "goto RetBank4" and then put a single "return otherbank" there to get back to my main drawing loop? Seems like it might save space, but also cost additional time, no? Would you entertain the idea of using the stack function to gain more ram space? If your using a var which wont change often, say a var to know which wave your in, then push that to the stack, then pull when it's time to check it. Stack 200 push WaveNum rem WaveNum is now in stack 199 rem do some stuff rem retrieve WaveNum stack 199 pull WaveNum I've poured over my RAM looking for something that could be pushed to the stack, but there doesn't seem to be anything viable. For instance the RAM address tracking "wavenum" is used persistently in the program since it acts as a table pointer for enemy data (AI steering, speed, attack strength, color, etc) that is used in every frame. All of the temp variables are used every frame as well and to maximize the available RAM, there are a lot of variables pulling double-duty to handle both display states and object properties. I mean, I know everyone always claims that they've done their darndest with allocation, but I've really squeezed! I think I've come to the conclusion that pulling and pushing to the stack just doesn't seem like a natural fit for the pace of this gameplay, since even offscreen entities are constantly performing the same game tasks they perform on-screen and there is no genuine "break" in the action.

Thanks. So, only the background bounces on both of those builds? Or does the background bounce on 081411.bin and everything (including the players) bounces on 081011? Darn it, that's very discouraging. It seems like it's one step forward and three steps back with this program. Does it crash and reboot to the title screen?

Not sure why the background would bounce. Did it bounce for you in previous versions? Do you have the latest Harmony firmware update? He's right. Background always bounces. In this version only, or in the last version as well?

Not sure why the background would bounce. Did it bounce for you in previous versions? Do you have the latest Harmony firmware update?

Now that the Princess is in, and while I've still got this on my mind, I thought I'd throw out a few ideas I had on what to replace the Bat with. The RAM I have left over is the virtual player6x, player6y and the last 5 bits of NUSIZ6. The x and y vars are limited to keep the display stable (for instance, player6y pretty much has a max value of "6", to avoid overlapping with other sprites and triggering the auto-flicker routine). With that in mind, here's some ideas I had, each of which would probably use up my remaining RAM: Soldier Armies: Use player6x to create a virtual position for the Soldier. With that in place, I could make up to three close copies of the soldier sprite, each of which could be targeted independently by arrows. With a virtual x that changes depending upon which side of the screen its on, the Soldier group could more or less disappear smoothly at the screen edge, and would only flicker when one of them is killed (temporarily swapping in the player6 sprite for the death animations). I could then use the remaining bits of NUSIZ4 to give some Soldier types unique properties, like faster movement, greater strength, defensive/offensive manuevers, etc. Respawn Timer: Use player6x to create a timer object that counts down after a Soldier is killed, giving the player a bit of a reward for killing a Soldier. Basically, this timer would function as a breather during which the player doesn't have to worry about the Soldier attacking one of his Castles, and could focus his attention on hunting the dragons and navigating the road. As play progress, the breather between soldiers gets shorter. With this option, I could still probably use NUSIZ4 bits to vary the Soldier's abilities a bit. Road Hazards: Use player6 sprite and one of the enemy Knight's sprites to create obstacles on the road (for some levels) that the Paladin needs to dodge and weave around as he patrols. Powerup/Bonus: Occasionally, a sprite will float across the screen that you can shoot for bonus points, health powerups or castle repairs (functions a little bit like the saucer in Space Invaders.) Not sure what the sprite will "be", but I suppose it could be a bird, Willow'o'wisp, fairy or anything else that might reasonably fly, with different sprite shapes representing different kinds of powerups/bonuses. Cheers, J

New Version: 1. Took out the bats for now, and added in the Princess. Here's how she works: Each time you protect a Castle enough to raise its hit points to the 40 HP maximum during the Repair Phase, the Castle gains a Princess (her image replaces the colored Flag at the top of the Castle). If a Princess is captured, the Dragon will attempt to escape to the top of the screen with her. Follow the sound of her screams to track down the dragon before it reaches the top and eats her. If you can kill the dragon before it reaches the top, the Princess will begin falling down the screen towards the road. Try to position your horse beneath the Princess to catch her, earning big bonus points. Giant Dragons and Wizards don't capture Princesses (Ultimately, I think they will just kill them while they are still in the Castles) 2. Now, when you've defeated all the flying enemies in the current wave you will hear a little trumpet tune, indicating that it's time to hunt down and kill the last road enemy. 3. Fixed a minor glitch with Castle damage taking place off-screen. 4. Added a second possible extra man at 1000 pts. To help see the Princesses sooner, I've temporarily raised each Castle's starting HP in this version to 32, so you should probably at least see one Princess by the second level if you have an undamaged Castle. The Princesses will be a key part of the game's bonus structure (including some secret bonuses for saving them in particular ways), but for now they simply earn you 90 points for each time you save one. I was able to implement the Princess routine without using any of the Bat's player display bits, so theoretically I might be able to bring the Bat back in as well if I can locate another free byte of persistent RAM. Failing that, I might use the extra player (or its RAM) for something else. Ideas are welcome, as usual. Cheers, J ChargeDPC_081411.bin