[Prototypical Game Idea Thread]

Red, Blue, Green

Red+Green=yellow

It is complimentary? I'll add a demo to the original post. I can't attach it to this.

[A-Maze-Ing]

Thanks for the suggestions. I've only been doing Batari Basic since June and it just amazes me how people know precisely how many bytes such and such action does. I'm not really all that good at math. In fact, I'm pretty amazed at what I've done so far in GoSub.

I understand. Do what you can with what you've got. Thanks for the reply.

 

How about this for a multiplayer thing? Have both subs go at once and have them race to the finish, maybe try to ram them in the walls or something? Of course the walls shouldn't be deadly, so how about them being sticky or something? I think having just one go is kinda harsh, given the difficulty of some of the later levels.

That sounds cool. The reason I suggested alternating multiplayer is there could be about eight people playing. I'm not sure if you meant one go was harsh for my first multiplayer idea or my second.

 

In the first suggestion for alternating multiplayer, even if a player didn't finish a maze, they'd still be playing in the next round. Each player would get one go at each maze. Then the scores would be shown for each player. That doesn't seem to harsh, so I think you were talking about the idea of a "race" mode.

 

If you have eight people playing to elimination, I don't think it would really be that bad. It would go pretty quick, but it's like when you play basketball in the summer and you set the score low, because it's so hot. If it did go by too fast, you move it up to two or three lives for just a byt or two of RAM.

 

The enemy thing is a good idea too, but the sub would have to be brown because I'm using missile1 for the treasure chest, and its ping would have to be black because I'd be using missile0 for an actual missile. I'll do some fiddling around with the program this week and see what I can do.

Hmm . . .

 

Brown enemies sound fine. I'm sort of confused about why its ping would have to be black. I was under the impression that your were using

Player0: sub

Player1: unused

Missile0: unused (noblanklines takes away the option of missile0 right?)

Missile1: Treasure

Ball: unused

 

I thought that meant you would have to use the ball for a ping. I didn't think that you would be able to have missiles and an enemy ping on screen at once. (because they would both need the ball) When I made the suggestion, I was thinking that the enemy sub would take you out the same way the walls do whenever you come into contact with it. You wouldn't have anyway to kill it, but since it's "vision" is so limited the player could outsmart or even trick the enemy sub to get around it.

 

That's also why I said not to time it. A timer and an unkillable enemy would just be frustrating.

 

Good luck,

Robert Jones

 

EDIT: nevermind

[A-Maze-Ing]

double post

[A-Maze-Ing]

Hello Again,

 

I like the music.

 

I got bB and I've been playing around with it. I have a much better idea of what can be done with it now. So, now I have more detailed suggestions. I know there's only a little bit of RAM in bB, so included an estimate for the RAM cost of the suggestions.

 

You can have several modes. They would be chosen with the select switch at the title screen. You could number them with the score sprites.

 

 

 

1. Easy Mode

This would be timed. At the start of the maze, some sort of prize would pop out of the end point. The object would simply bounce around the maze. This should only take three bytes of RAM. Two for the x and y positions and use four bits for the four directions. If the prize hits a wall check to see which two bits are on. Then reverse one direction. If the prize is still hitting a wall. Reverse the other direction. (If you like this idea, but don't know what I mean, I could explain it better, or even make a demo program.)

 

At the end of every maze, the current score (time left on the clock) could be added to a location in the RAM for the final score. Whenever the player collects a prize, it will add time to the clock rather than directly add points. This would give the player more incentive to go after them, than simply giving them points. Points would be taken away from the final score for dying, but you couldn't completely lose.

 

The prizes can be colored and the finish point made out of the ball. To differentiate the ball from the maze, flicker it at 30 hz which shouldn't look very bad at all on a real television with how dark Gosub's background is. (To keep track of whether the ball is on or off, you could use another bit of that third prize RAM byte.)

 

Check the RAM that holds your current level and have proggressively nicer prizes. For example:

 

 

Total RAM cost: 4 bytes

Rom Cost: at least one maze

 

 

 

2. Hard Mode

In this mode the timer will progressively go up. And the time will be subtracted from some predetermined number, to get the player's final score. If a player dies too many times they'll lose in this mode.

 

Have a solid color sub pop out of the maze's finish point. The sub can move in the four cardinal directions and shoot a harmless "sonar" ping. The ball would be his ping. This should make AI easier to program. The ping will shoot off of the sub in whatever direction he's traveling. Whenever it hits something it will reverse directions and return to the enemy sub. Set up a byte of RAM with a timer. If the ping take too long to come back the sub knows that way is open. If the ping comes back quick the sub knows there is a wall there.

 

You can keep a byte of Ram with above, below, left, and right mapped to four bits for the enemy sub. You can also four more bytes of Ram open with the xpos and ypos the sub was at when the ping returned on each side. Put something in your kernel that says something along the lines of:

If Currentypos - yposwhenleftwallwasdetected > 10 set Thereisawallontheleftbit back to false.

 

That way if the sub detects a wall on the left. The goes up about fifty lines, he isn't still trying to go right.

 

This would take up a lot of RAM, though.

Total RAM cost: at least 9 bytes

 

 

 

Alternating Players

This is something I suggested before. On the title screen you could have 1-8 in one color for easy and then 1-8 in another color for hard (there's a byte of RAM)

 

Each player would get a single go at each maze. When they die a different colored sub we appear at the starting point, and they'd passe the joystick. At the end of the game every player's score would be shown. This is something I suggested before. I don't think it would work though. You need an extra byte of RAM for the title screen. A byte for each player's score. A byte to keep track of whose turn it is. If you don't add anything but multiplayer with individual scores to the game, you're already adding 10 bytes.

 

You'll need to write a routine for cycling through each player's score and displaying different colored subs (this would also probably take a byte of RAM, now that I think about it.)

 

This would be really cool to have, but I'm not sure if there would be room for it. (Ramwise)

 

Cost: at least 11 bytes of RAM

 

 

 

Race Mode

This might be a better solution for multiplayer. Have a time limit on the mazes. No enemies or anything. But if a player dies once they're gone. This would only take two bytes. One to keep track of whose turn it was, and one to keep track of who's alive.

[GoSub at the end of 12/3/06]

I just got a chance to play this all the way through. Anyway here are my thoughts:

 

- I liked the easter egg screen.

 

- A lot of the mazes were really similar. Get crazy with it. Also, you might want to consider taking the best half of your mazes and having a contest similar to Comat Redux to get the other half. (I worded that really bad, but I think the message was conveyed.)

Contest page.

 

- I liked the actual engine of the game. I remember when you were working on "Ants" before, and people (inlcuding myself) were saying that they liked the premise and look, but the actual engine was too simple. I think you've gotten better at giving the player control of his character without just giving him control of his sprite (if that makes sense).

 

- I like how the game begins each level from a paused state. I had to leave the game for a few minutes to heat up some spaghetti, and was able to come right back.

 

- This is the kind of game where you could have a lot of people playing turn-based multiplayer. (This is kind of my solution to everything.) I think it would be worth cutting out music to include this. You could have it be up to eight players. You could have it be elimination based: start each player with a set number of lives. If they use all of them they're out. Last one left wins. Use the other sprite for lives.

 

Or you could have it be score based. Each player could have up to three chances at a level. With more points for beating on an earlier try and more points for beating levels (Something like 10 points for beating a level+the number of the level+9-(number of tries*3) Use the other sprite for some bonus items.

 

Or you could have some stuff set up to select from different options.

 

- In the one player mode, you could have an enemy that spawns from your spawn point a few seconds after you leave and chases you. The fire button could be used to lay mines.

 

- You asked about the speed. I'd prefer it faster. Maybe you cna use the difficulty switches to choose?

 

And a few questions I had:

 

- What are you planning on using the other sprite for?

 

- Are you planning any Atarivox support for saving games?

 

 

I think I remember you posted about losing a lot your code because of computer problems. I'm glad to see that didn't stop you from coding. I look forward to seeing what you do with this.

 

Good luck,

R. Jones