Game Idea: Dice Warrior

[neotokeo2001]

I know there have been a few make this game threads, well here is mine.

 

First, I would really like this game to be made in some form for the Atari 2600. I would be willing to make arrangements with someone who can program the game. Either monetary or trades.

 

Here is my pitch.

 

DICE WARRIOR TITLE SCREEN

 

Dice Warrior is a RPG Board Game.

 

It consist of three(3) different screens.

 

1. Title Screen (see pic above)

2. Board Game Screen

3. Battle Screen

 

BOARD GAME SCREEN

 

The Board Game Screen is basically the map for the level. You have a starting position and move with a dice throw. The dice would only allow a roll of 1-3 so you don't need a huge board. The board has several different types of squares. The dice roll is displayed at the bottom of the screen.

 

A.Starting Square

Starting location.

 

B.Safe Square

Basically an open spot where nothing happens.

 

C.Enemy Square(skull)

When you land on an Enemy Square you are taken to the Battle Screen where you fight a turn based battle.

 

D.Event Square(green)

The Event Square will either have a healing item or some other helpfull event(Hints).

 

E.Boss Square(scorpion)

The end level Boss for the board will also take you to the Battle Screen for a fight with the Boss.

 

BATTLE SCREEN

 

The Battle Screen is where the enemy encounters are fought out with a turn based dice battle. It displays the Dice Warrior as well as the Enemy. Directly below each character is displayed their hit points. Directly above the characters is displayed the dice roll. If you roll a higher number then your opponent then you get a hit on them and hit points are deducted. The battle continues until there is a winner.

 

The player would have an advantage over the enemies. The player could roll a 1-6 while the enemy, depending on the type, could only roll 1-2, 1-3, 1-4, etc...

 

GENERAL INFO

Levels (Maps) could have set boards with randomly located enemies.

Scrolling boards.

Main character level up could be accomplished with allowing higher number rolls.

 

Robert M looked at it and came up with the following graphic for the game board:

 

This is just a rough draft of the overview of the game. There is no set direction at this time. If someone wants to give it a shot, just let me know and we can work out more specific info.

[trigun]

this actually looks prety good, how did you make those atari graphics renderings? is i were you, id try my shot at Basic, get the book "basic Programming For Teens" and it will tell you almost everything you need to know how to make this into a game, then to make it into a ROM so you can pot it to a chip, deppending on how big a file the Rom is, you should port it to a chip,(perhaps, just in case, make the game, convert it to a rom, check the file size, and choose the right Chip from the AA store.), and then you can either put it in a Cartridge by getting it manufactured through AtariAge, or just tear apart any old double copy of an atari game you have and put it in there. that should all work out, but as for me, i have no idea on programming.

[Robert M]

I am rather busy at the moment moving from Illinois to New York. Once I am settled I would be able to help some more on this project.

 

I would be willing to write the display kernel(s) and a "fill in the blanks" program/state-machine shell. Are there any (possibly newbie?) programmers who would be interested in taking a working kernel and putting the game code in? It could be a great learning experience

 

Cheers!

[neotokeo2001]

I am rather busy at the moment moving from Illinois to New York.  Once I am settled I would be able to help some more on this project.

 

I would be willing to write the display kernel(s)  and a "fill in the blanks" program/state-machine shell.  Are there any (possibly newbie?) programmers who would be interested in taking a working kernel and putting the game code in?  It could be a great learning experience 

 

Cheers!

853521[/snapback]

 

Thanks Robert.

 

I can't help on the actual programming, but I will help in any other way that is possible.

I will continue to try to flesh out the game and come up with some more designs. It does'nt matter if they are used in the end, Just giving an idea some form.

Hopefully someone (or someones ) will take up the flag and run with it.

[Robert M]

Hey Neo,

 

You should post the NES rom you got the core idea for this game from. Playing that ROM clarified alot for me about the flow of the gameplay and showed me how fun it could be. It might help to drum up more programmer talent.

 

Cheers!

[neotokeo2001]

Hey Neo,

 

You should post the NES rom you got the core idea for this game from.  Playing that ROM clarified alot for me about the flow of the gameplay and showed me how fun it could be.  It might help to drum up more programmer talent.

 

Cheers!

854516[/snapback]

 

Sugoro Quest

Download ROM:

Sugoro_Quest_NES.zip

 

This is a japanese only release that was translated.

[yuppicide]

How can you get a book on Basic for programming this on the 2600.. doesn't the 2600 require ASM programming?!

 

this actually looks prety good, how did you make those atari graphics renderings? is i were you, id try my shot at Basic, get the book "basic Programming For Teens" and it will tell you almost everything you need to know how to make this into a game, then to make it into a ROM so you can pot it to a chip, deppending on how big a file the Rom is, you should port it to a chip,(perhaps, just in case, make the game, convert it to a rom, check the file size, and choose the right Chip from the AA store.), and then you can either put it in a Cartridge by getting it manufactured through AtariAge, or just tear apart any old double copy of an atari game you have and put it in there. that should all work out, but as for me, i have no idea on programming.

847253[/snapback]

[danwinslow]

Trigun is an almost perfectly clue-free source of information about programming the 2600. You do indeed need assembler, and *hard* assembler at that, plus a detailed and in depth knowledge of the hardware in order to even begin programming the 2600.

You could, however, learn to program on a more modern computer in Basic, and then move on to assembler, and then onto the 2600.

[Thomas Jentzsch]

Remove "almost".

[cd-w]

The kernel for this game is going to be quite difficult. There are a couple of problems with the design at present:

1) There are 40 PF pixels across the screen (the design assumes 20 pixels).

2) There are too many colours per scanline if you are using PF graphics. You can change the foreground or background, but not both, between squares.

The code below is a sketch of a kernel which would draw the board using PF squares that are 6 pixels wide. The timings are not entirely correct, but you should get the basic idea. This kernel could probably be made to work by reducing the size of the squares and ignoring PF0, or using self-modifying code. However, I think it is going to be better to use sprites instead ...

 

Chris

 

Kernel
lda SCREEN,X	; [1] + 4
sta PF0  ; [5] + 3	< 22
lda SCREEN+1,X	; [8] + 4	
sta PF1  ; [12] + 3	< 28
lda SCREEN+2,X	; [15] + 4
sta PF2  ; [19] + 3	< 38
ldy COL+1	; [22] + 3
lda SCREEN+4,X	; [25] + 4
sty COLUPF	; [29] + 3	> 32 < 35
ldy COL+2	; [32] + 3
sta PF1  ; [35] + 3	> 38 < 60
lda SCREEN+3,X	; [38] + 4
sty COLUPF	; [42] + 3	> 42 < 46
sta PF2  ; [45] + 3	= 48
lda COL+3	; [48] + 3
sta COLUPF	; [51] + 3	> 53 < 56
ldy SCREEN+5,X	; [54] + 4
lda COL+4	; [58] + 3	
sta COLUPF	; [61] + 3	> 64 < 67
sty PF0  ; [64] + 3	> 28 < 70	
lda COL  ; [67] + 3
sta COLUPF	; [70] + 3	< 24
dex  ; [73] + 2
bne Kernel	; [75] + 3	!!

[Robert M]

The kernel for this game is going to be quite difficult.  There are a couple of problems with the design at present:

Hello, glad to see some interest in this baby. Not problems! Challenges! That's what makes this hobby fun.

 

1) There are 40 PF pixels across the screen (the design assumes 20 pixels). 

 

The design shows 20 PF pixels being used because that is the minimum number needed to get 5 game board spaces across. You can just leave 10 pixels unused on each side, which frees up CPU time. Or if you can make a kernel that displays more than 5 spaces then that is even better.

 

2) There are too many colours per scanline if you are using PF graphics.  You can change the foreground or background, but not both, between squares. 

The code below is a sketch of a kernel which would draw the board using PF squares that are 6 pixels wide.  The timings are not entirely correct, but you should get the basic idea.  This kernel could probably be made to work by reducing the size of the squares and ignoring PF0, or  using self-modifying code.  However, I think it is going to be better to use sprites instead ...

 

You are on the right track here. I think self modifying code is your best bet. You can change the PF color for each space in a row using a self modifying routine in RAM. That leaves the sprites free to draw icons and the player. Note that the spaces are 4 PF pixels wide for the reason that the spaces are then 16 color clocks on center which allows us to use the hardware sprite replication to get 3 identical icons per row. So making them 6 PF pixels wide will block that feature.

 

The timing is a bit touchy with 16 color clocks per space since 16 does not divide evenly by 3 to stay in sync with the CPU. That's the fun part!

 

Consider though that you do not need to change the PF registers at all during the display, only the COLUPF register.

 

Cheers!

[vdub_bobby]

The kernel for this game is going to be quite difficult.  There are a couple of problems with the design at present:

Hello, glad to see some interest in this baby. Not problems! Challenges! That's what makes this hobby fun.

 

[snip]

 

Consider though that you do not need to change the PF registers at all during the display, only the COLUPF register.

 

Cheers!

859069[/snapback]

I've found, when planning kernels, that the best place to start is to start adding up cycles for what you want to do. If you exceed 76, then you know for sure it won't fit

 

At least it helps me think things through.

 

So here's my wee contribution:

 

5 playfield color changes (each: lda ZP, sta COLUPF) = 30 cycles

1 player + color = 21 cycles using SwitchDraw or 25 using SkipDraw

1 player + color = 21/25 cycles

Loop maintenance (dey bne) = 5 cycles

 

Total=77/85 cycles. Too many.

 

So to get everything we'll have to use SwitchDraw definitely and restrict one of the players to two-line resolution, which gives us this:

 

5 playfield color changes @ 30 cycles per line for two lines = 60 cycles

1 player + color @ 21 cycles x two lines = 42 cycles

1 player + color @ 21 cycles every other line = 21 cycles

Loop maintenance = 5 cycles

 

Total = 128 cycles. Two scanlines have 152 cycles, so there is plenty of time.

 

Another solution would be to make one of the players monochrome:

PF color changes = 30 cycles

Player + color = 21 cycles

Player w/o color = 15 cycles

Loop maint = 5 cycles

 

Total = 71 cycles. Which is probably doable, though working around the tight timing of the PF color changes might make things tricky with only 5 cycles to spare.

 

Another solution would be to make one of the players have single line resolution but have his color be two-line resolution:

PF color changes = 30 x 2 = 60

Player + color = 21 x 2 = 42 cycles

Player + color every other line = 21 + 15 = 36 cycles

Loop maintenance = 5 cycles

 

Total = 143 cycles. Plenty of time; again it is a matter of working around the tight timing. Probably could be done.

 

Ok, I'm spent.

[Cybergoth]

Hi there!

 

Been there - done that...

 

[stella]

[Cybergoth]

Hi there!

 

Ok, I'm spent.

859088[/snapback]

 

The main flaw in all your considerations is that you don't need any switchdraw/skipdraw code for this display. (And I seriously hope you don't do it in Go Fish! either...)

 

It's just a set of horizontal stripes, so displaying a sprite comes down to:

 

LDA (spritePointer), StripeHeightCounter

STA GRPX

 

In the board I posted it actually comes down to:

 

LDA spriteDataAbsolute, StripeHeightCounter

STA GRPX

 

because with the code residing in RAM I can tweak "spriteDataAbsolute" to just wherever the sprite is located.

 

So when downgrading the board I posted from 7*7 to 6*7, you easily have the required 4*7=28 free cycles to draw two sprites complete with individual colorization.

 

Only thing I'm not sure about right now is wether double/tripple copies of sprites will align properly to the tiles.

 

Greetings,

Manuel

[cd-w]

Hi there!

Been there - done that...

[stella]

859316[/snapback]

 

Darn, you beat me to it, by about a year . I have attached my latest attempt at a dicewar kernel. It roughly follows the design spec given at the beginning. It displays five independently coloured squares, and two sprites per scanline (without the need for skipdraw). One of the sprites is monochrome, but there are 10 free cycles, so it should be possible to fix this later.

 

 

Anyway, let me know what you think. Perhaps I should code this up as my next minigame ...

 

Chris

dicewar.zip

[neotokeo2001]

Hi there!

Been there - done that...

[stella]

859316[/snapback]

 

Darn, you beat me to it, by about a year . I have attached my latest attempt at a dicewar kernel. It roughly follows the design spec given at the beginning. It displays five independently coloured squares, and two sprites per scanline (without the need for skipdraw). One of the sprites is monochrome, but there are 10 free cycles, so it should be possible to fix this later.

 

 

Anyway, let me know what you think. Perhaps I should code this up as my next minigame ...

 

Chris

859487[/snapback]

 

If you want to give it a try then go ahead. I'm just glad that someone has showed an interest in the game. Other make this game threads were not taken as well so I was a little worried.

[vdub_bobby]

The main flaw in all your considerations is that you don't need any switchdraw/skipdraw code for this display. (And I seriously hope you don't do it in Go Fish! either...)

859333[/snapback]

Here's me -->

 

In my defense, I was just thinking out loud, er, or something. And in Go Fish! I do indeed use a version of SkipDraw

 

Only for the hero, though.

[Cybergoth]

Hi there!

 

In my defense, I was just thinking out loud, er, or something.

860080[/snapback]

 

Well, that's actually a very good thing then. Just imagine you spend a day or two trying to program it the other way...

 

Greetings,

Manuel

[cd-w]

I have attached my latest attempt at a dicewar board kernel. There are still a lot of glitches in the code, and it is very ugly, but it demonstrates the main features in action:

 

• The board is 5 squares by 16 squares, and each square can be a different colour.
  
• The player can be displayed in any position on the screen.
  
• Each row of the board can display one, two, or three monsters.
  
• The board square graphics can be changed every second line (PF is reflected).
  
• The board can be scrolled up/down.
  

You can use joystick 1 to move the player and joystick 2 to scroll the board. There is still a lot to do, but I though I would post it now just to check that everyone is happy with the board layout, and to see if anyone has any suggestions for improvements.

 

Chris

dicewar02.zip

[vdub_bobby]

I have attached my latest attempt at a dicewar board kernel.  There are still a lot of glitches in the code, and it is very ugly, but it demonstrates the main features in action:

Those sprites look familiar...

 

Seriously, that is sweet! Nice job. Would it be possible to make the board 6 squares wide? Or more? I think the wider the better.

[Cybergoth]

Hi there!

 

Seriously, that is sweet!  Nice job.  Would it be possible to make the board 6 squares wide?  Or more?  I think the wider the better.

867453[/snapback]

 

As is, the playfield nicely aligns with triple copies. If the board was too small now, it could just scroll vertically once you reach the bottom.

 

Greetings,

Manuel

[cd-w]

Those sprites look familiar...

Seriously, that is sweet!  Nice job.  Would it be possible to make the board 6 squares wide?  Or more?  I think the wider the better.

867453[/snapback]

 

Yes, the sprites are taken from my Hunchy game just to demonstrate the concepts (and the guard sprite was designed by you!).

 

The 5 squares width is the only size that I could find which worked well with two and three sprite copies. Also, to get more squares is going to require some nasty self modifying code tricks. I was hoping that the length of the board would make up for the lack of width ...

 

Chris

[cd-w]

As is, the playfield nicely aligns with triple copies. If the board was too small now, it could just scroll vertically once you reach the bottom.

867456[/snapback]

 

Yes, that is the idea - you can currently scroll the board using the second joystick, and eventually it will scroll as the player moves around.

 

Unfortunately, horizontal scrolling is not possible without jumping a whole quare at a time due to timing constraints.

 

The next version that I post will constrain the player to the board squares, so we can get a better idea of how it plays.

 

Thanks,

Chris

Edited June 3, 2005 by cd-w

[neotokeo2001]

As is, the playfield nicely aligns with triple copies. If the board was too small now, it could just scroll vertically once you reach the bottom.

867456[/snapback]

 

Yes, that is the idea - you can currently scroll the board using the second joystick, and eventually it will scroll as the player moves around.

 

Unfortunately, horizontal scrolling is not possible without jumping a whole quare at a time due to timing constraints.

 

The next version that I post will constrain the player to the board squares, so we can get a better idea of how it plays.

 

Thanks,

Chris

867458[/snapback]

 

The graphic size and layout looks really good. The multiple paths and the scrolling really add a lot of depth.

[Legend]

any progress ever made on this one? Anyone still working on it?

 

-Legend