20 replies to this topic

[theloon]

Well, I decided I should finish this project before starting another one. Right now I've got the maze done and a placeholder "ring" object in, er, place.

No title screen so one must press FIRE before starting the game. Right now the score is set to display the current floor of the dungeon. How big is the dungeon? Here's a quote from my blog:

Quote

16 basic room types (not including rare rooms)
8 room structure styles
16 x 8 = 128 Unique Rooms
256 level dungeon consisting of 256 x 256 screens per level.
All in all, my Adventure/Roguelike should have 1,677,7216 screens per gaming session. Each time the game is powered on a game seed is used so really 256 1,677,7216 screen dungeons are possible. You do the math: I'm tired

Like I said this is very much WIP and not a complete game yet. Check it out anyway If you get stuck in a dead end don't worry: there's a random chance each time you enter a room it'll change into its rare form with new exits.

Initially all the room combinations were taking up too much space so I developed a technique to divide one screen into 3 slices that get "printed" and then scrolled to allow the next section to be placed on-screen. I haven't seen this done yet so I hope it'll interest fellow Batari game developers.

Placement of the rings stays basically static no matter how far in the dungeon you go. However, if one picks up an item ALL other items get a new random location.

Attached Thumbnails

• 
• 

Attached Files

•  destiny0001.bas   21.46K   77 downloads
•  destiny0001.bin   16K   107 downloads

Edited by theloon, Fri Nov 19, 2010 5:36 PM.

[Brian O]

theloon, on Fri Nov 19, 2010 5:17 PM, said:

Well, I decided I should finish this project before starting another one. Right now I've got the maze done and a placeholder "ring" object in, er, place.

No title screen so one must press FIRE before starting the game. Right now the score is set to display the current floor of the dungeon. How big is the dungeon? Here's a quote from my blog:

Quote

16 basic room types (not including rare rooms)
8 room structure styles
16 x 8 = 128 Unique Rooms
256 level dungeon consisting of 256 x 256 screens per level.
All in all, my Adventure/Roguelike should have 1,677,7216 screens per gaming session. Each time the game is powered on a game seed is used so really 256 1,677,7216 screen dungeons are possible. You do the math: I'm tired

Like I said this is very much WIP and not a complete game yet. Check it out anyway If you get stuck in a dead end don't worry: there's a random chance each time you enter a room it'll change into its rare form with new exits.

Initially all the room combinations were taking up too much space so I developed a technique to divide one screen into 3 slices that get "printed" and then scrolled to allow the next section to be placed on screen. I haven't seen this done yet so I hope it'll interest fellow Batari game developers.

Placement of the rings stays basically static no matter how far in the dungeon you go. However, if one picks up an items ALL other items get a new random location.

Liking it so far. It feels very expansive. Not exactly sure what the objective is or how points are scored, however. I noticed I get a point for colliding with one of the white, stair-like objects, lose a point for going down the black staircase, and get no points for the rings. I know it's unfinished, but was just curious how you plan on setting up the game play.

Can't wait to see more!

-B

[Gateway]

Brian O, on Fri Nov 19, 2010 5:41 PM, said:

Liking it so far. It feels very expansive. Not exactly sure what the objective is or how points are scored, however. I noticed I get a point for colliding with one of the white, stair-like objects, lose a point for going down the black staircase, and get no points for the rings. I know it's unfinished, but was just curious how you plan on setting up the game play.

Can't wait to see more!

-B

@Brian: I believe theloon is currently using the score to track what dungeon you are in, so, naturally, the number will go up if you climb the stairs and down if you go downstairs.

@theloon: I agree, nice work! Very clever dividing the screen into 3 sections.

Only potential problem I see at this point, is not much frame of reference from where you were and where you end up. Unless you will be including more "rare" screens such as the castle screen? This will help keep a fixed point in mind as the player explores the dungeon to find other "rare" locations.

If the game is based on earning the most points, then I suppose you can put items anywhere and keep finding them until you earn a certain number of them to win ( or get killed by a monster ). If you are looking for a specific object however (such as Adventure does with the Chalice), will the player be able to find his way back to the starting castle?

[theloon]

This started out with Rogue-like aspirations so the ring was gonna be your classic variety of magical rings. I've since decided on "collect the rare carts and bring them back to your castle" style gameplay. The goal and ending parts of the game haven't been implemented yet.

I was wondering if the dungeon was still too generic. Maybe it will help if the normal difficulty is a static dungeon? The other thing I'm going to try is further customizing each room. Will show a new build soon.

Thanks Gateway and Brian O!

[Piggles]

I thought my Nethack habit was bad enough. Soon there will be this.

I love your use of pfscroll to build the rooms. I dub thee "The ROM Saver."

What do you have planned next? Will there be enemies to battle?

[Brian O]

theloon, on Sat Nov 20, 2010 11:39 PM, said:

This started out with Rogue-like aspirations so the ring was gonna be your classic variety of magical rings. I've since decided on "collect the rare carts and bring them back to your castle" style gameplay. The goal and ending parts of the game haven't been implemented yet.

I was wondering if the dungeon was still too generic. Maybe it will help if the normal difficulty is a static dungeon? The other thing I'm going to try is further customizing each room. Will show a new build soon.

Thanks Gateway and Brian O!

Anytime!

I think you have a really good idea to build on. The only thing that is missing is some tension. Having monsters in certain rooms, or having a Pitfall-style timer counting down, would definitely help to create a sense of urgency. Since the rooms are randomized, there's no real way create a map to help you see which rooms you've been in, right? In terms of room customization, it would definitely help from an aesthetic perspective, but may not serve a true practical purpose unless players could use the rooms as landmarks, IMO.

Can't wait to see the next iteration.

-B

[Random Terrain]

theloon, on Fri Nov 19, 2010 5:17 PM, said:

Initially all the room combinations were taking up too much space so I developed a technique to divide one screen into 3 slices that get "printed" and then scrolled to allow the next section to be placed on-screen. I haven't seen this done yet so I hope it'll interest fellow Batari game developers.

I didn't look at your code yet, so I don't know what you mean by printed and scrolled, but the part about dividing the screen into sections kind of reminds me of these threads:

http://www.atariage....bout-no-action/

http://www.atariage....ndom-maze-demo/

[RevEng]

Definitely a solid start! I agree that more distinct room features could help. I'd also like to see matching up-stairs and down-stairs.

I don't know if you noticed, but your room drawing routine is using too many cycles.

Since you're after rings, why not call it "rings of the lord", and add some shadow riders.

[theloon]

Well, I couldn't get the castle to stop appearing on floors other than the first. I made a "castle ruins" that appears if the dungeon floor isn't 1.

Right now I'm trying to see if I can hack in matching staircases. As the code is the resulting staircase would only be temporary and would disappear when returning to the room.

@RevEng: Going over the CPU cycles seems to be a serious no-no but I don't understand why. Can it blitzkrieg the entire game or just make funny noise on the screen when it happens? Bataris kernel isn't going over the CPU cycles right? Just my amateur game logic code (I think, dunno).

I want enemies. I want further detail put into the rooms. We'll see how far I get! The minimum gameplay should be collect the items and dash back to the castle on the first floor.

I'm having trouble coming up with a cartridge sprite to replace the ring. Nothing I draw comes out convincing. Maybe I'll bug PAC-MAN RED

Edited by theloon, Sun Nov 21, 2010 5:01 PM.

[RevEng]

theloon, on Sun Nov 21, 2010 4:59 PM, said:

@RevEng: Going over the CPU cycles seems to be a serious no-no but I don't understand why. Can it blitzkrieg the entire game or just make funny noise on the screen when it happens? Bataris kernel isn't going over the CPU cycles right? Just my amateur game logic code (I think, dunno).

Right, it's not the kernel, it's the bB code. The reason using too many cycles is undesirable is because it causes the overscan part of the TV frame to have too many lines, which is quite likely to cause screen jittering or rolling.

The "ideal" TV frame generated from a 2600 game is made up of these parts and these line counts:

[VSYNC.............3 lines]
[VBLANK...........37 lines]
[VISIBLE SCREEN..192 lines]
[OVERSCAN.........30 lines]

The main part of your basic program runs in the overscan part of the TV frame until it hits a drawscreen command, at which point the rest of the frame parts are drawn. When overscan time beings again, control is returned to your basic code, just after the drawscreen command.

One way to avoid using too many cycles is to have multiple drawscreens strategically placed in CPU-heavy parts of your code. This approach won't work in the main loop of the game, as each drawscreen in your main loop will reduce the overall framerate, but it works well enough for screen setup code.

If you take this approach, you may want to set the colors of all screen elements to black until the screen is completely drawn, to avoid showing the screen as it's being built-up.

It's also worth mentioning that your basic program can also run partially in vblank with the vblank keyword, and similarly you don't want to use too many cycles there either, or else there will be too many vblank lines, which will cause jittering or rolling.

[Random Terrain]

Are you still working on this? I found this thread again while searching for bB adventure games. I wonder if the mix of 'collision prevention' and collision detection in this example program would be helpful:

http://www.randomter...ss_coll_example

[theloon]

Random Terrain, on Wed Aug 17, 2011 7:23 PM, said:

Are you still working on this? I found this thread again while searching for bB adventure games. I wonder if the mix of 'collision prevention' and collision detection in this example program would be helpful:

http://www.randomter...ss_coll_example

I appreciate the mention RT. I don't think I had a problem with collision. RevEng may have said I'm going over the cycle count but my last build plays okay on a real 2600. I've been itching to flog my source code to the fellas in the Atari Roguelikes topic but, nah

The point I got "stuck" on was adding more items and monsters. Either I ran into a bug or just lost steam at that point. Saying I quit would imply a deadline. This is just on hold until the urge takes me again.

Right now I'm working on a Sega Genesis title but NOTHING compares to bB and AtariAge (this includes YOU, whoever is reading this!). Hopefully by the time I'm done bB will be non-beta with DPC+ support. Can't wait!

Edited by theloon, Thu Aug 18, 2011 9:38 PM.

[PAC-MAN-RED]

theloon, on Sun Nov 21, 2010 4:59 PM, said:

I'm having trouble coming up with a cartridge sprite to replace the ring. Nothing I draw comes out convincing. Maybe I'll bug PAC-MAN RED

You mean like 2600 Carts? The top 3 are just color variations of the same sprite(sorry, sometimes I state the obvious ):


 2600 Cartridges.zip   984bytes   39 downloads


And yes, we can hear you from the Atari Roguelikes thread.

Illya

[Random Terrain]

theloon, on Thu Aug 18, 2011 8:56 PM, said:

I appreciate the mention RT. I don't think I had a problem with collision.

I mentioned it because I noticed how your little guy was sticking on the walls and I thought you might be able to use part of the code from the example program to make it seem like the walls are coated in butter.

theloon, on Thu Aug 18, 2011 8:56 PM, said:

Hopefully by the time I'm done bB will be non-beta with DPC+ support. Can't wait!

When that day comes, I'll get a DPC+ tattoo on my forehead.

I can't wait to start using those 10 multicolored Imagic/Activision quality sprites.

[RevEng]

theloon, on Thu Aug 18, 2011 8:56 PM, said:

RevEng may have said I'm going over the cycle count but my last build plays okay on a real 2600.

...on your TV. Scanline issues are highly variable depending on what TV is used to view.

When you leave a room the scanline count goes from a regular 262 to 396. You may not notice glitching because it's a room transition and it's dark the next frame, but I'd expect to some TVs will roll and take another frame or two to stabilize.

[ScumSoft]

Random Terrain, on Thu Aug 18, 2011 11:26 PM, said:

I can't wait to start using those 10 multicolored Imagic/Activision quality sprites.

Why wait? The dev kit is pretty much fully functional right now with a few quirks, but none of those are show stoppers
I'm finding the DPC+ support to be well implemented right now. Most of the issues can be accounted for and worked around.

[Random Terrain]

ScumSoft, on Fri Aug 19, 2011 4:54 AM, said:

Why wait? The dev kit is pretty much fully functional right now with a few quirks, but none of those are show stoppers

I'm finding the DPC+ support to be well implemented right now. Most of the issues can be accounted for and worked around.

There is a style of teaching where the class has to try to solve a problem without knowing what they are doing, then when they are shown the correct way, the kids are supposed to remember it better. That doesn't work on me. I'll remember the wrong way to do it because it was first.

If I learn a bunch of workarounds, my brain will be cluttered with useless crap that won't work anymore after the DPC+ stuff is working perfectly. I'd rather stay a DPC+ virgin until everything is working the way it's supposed to.

Edited by Random Terrain, Fri Aug 19, 2011 5:32 AM.

[theloon]

@PAC-MAN-RED: Thanks! Was having major trouble visualizing an atari cart with so few pixels and colors. This gives me much more to go on!

@RevEng: Crud. I might have to rewrite the whole darn thing. That's OKAY since the code is so old it's pretty alien to me now

@Random Terrain: Thanks for the feedback. I didn't personally consider the collision style to be an issue. I'll try to be truer to the Adventure style.

@ScumSoft: Ya, workarounds suck. I've been spoiled working with bB 1.0 and its stability. Working with other compilers has given me a much greater appreciation of Freds dedication to bB.

[RevEng]

theloon, on Fri Aug 19, 2011 7:31 AM, said:

@RevEng: Crud. I might have to rewrite the whole darn thing. That's OKAY since the code is so old it's pretty alien to me now

I think you could probably solve the issue with a well placed extra drawscreen or two in your room loading routine.

But I understand if it's time for a do-over. After a prototype you generally understand the problem-space a lot better, and can make better coding choices the second time around.

[ScumSoft]

Random Terrain, on Fri Aug 19, 2011 5:31 AM, said:

There is a style of teaching where the class has to try to solve a problem without knowing what they are doing, then when they are shown the correct way, the kids are supposed to remember it better. That doesn't work on me. I'll remember the wrong way to do it because it was first.

If I learn a bunch of workarounds, my brain will be cluttered with useless crap that won't work anymore after the DPC+ stuff is working perfectly. I'd rather stay a DPC+ virgin until everything is working the way it's supposed to.

Fair enough I suppose, however there are only I think 2 major workarounds that you need for things to work proper.

1)Add temp1 = temp1 right after a bank declaration to fix the stack bug. This can remain forever and not impair your game or future compilers.
2)Set kernel_options collision(playfield,player1) is required or else the code won't compile and adds the new collision detection routines.

Current other issue/bugs that I can recall offhand are:
* Colliding with virtual objects 2-9 from the top or bottom have a 5 pixel leeway in them and will only trigger a P0/P1 collision upon impact. Check with Y position to know which Virtual Px you hit.
* Taking a virtual player to Y = 0 will cause all other virtual players on the screen to temporarily adopt the X position of the Y = 0 player object.
* A few bB commands are missing and will cause you to deal with things differently for now (This is major for you I know)
* Stella and Harmony work completely different with ARM code, so things that look perfect on Stella during design may in fact not work at all on the Harmony.

I think that's almost all of the current bugs and inefficiencies of it. The other workarounds are subject to the game being designed at hand. You could try porting over your maze collision demo and see how it works out, and that might reveal some more issues yet undiscovered.

The following should be all you need for a DPC+ template.

Spoiler

 
 ; *****************************************************
 ; * BANK 1
 ; *****************************************************
 bank 1
 temp1 = temp1
 
 set tv ntsc
 set kernel DPC+
 set smartbranching on
 set optimization inlinerand
 set kernel_options collision(playfield,player1) 

 rem DEFINE VARS HERE

 goto MAIN bank2

 ; *****************************************************
 ; * BANK 2
 ; ***************************************************** 
 bank 2
 temp1 = temp1

MAIN
  rem INSERT GAMEPLAY LOGIC
  goto MAIN

 ; *****************************************************
 ; * BANK 3
 ; ***************************************************** 
 bank 3
 temp1 = temp1

 ; *****************************************************
 ; * BANK 4
 ; ***************************************************** 
 bank 4
 temp1 = temp1

 ; *****************************************************
 ; * BANK 5
 ; ***************************************************** 
 bank 5
 temp1 = temp1

 ; *****************************************************
 ; * BANK 6
 ; ***************************************************** 
 bank 6
 rem temp1 = temp1 not required here as this bank is for graphics only
 rem However I have placed my TitleScreen here with no apparent consequences 

Edited by ScumSoft, Fri Aug 19, 2011 6:17 PM.

[Random Terrain]

ScumSoft, on Fri Aug 19, 2011 4:29 PM, said:

Fair enough I suppose, however there are only I think 2 major workarounds that you need for things to work proper.

Thanks for the list and code.