-
Content Count
1,599 -
Joined
-
Last visited
Posts posted by Fort Apocalypse
-
-
Woohoo! I figured out how to handle two different items. There are now a shovel and a gun in two separate rooms. You can hold them, switch them around by grabbing the one you aren't holding. Did this by checking proximity to player1 among other things. Man that was fun!
-
And yet another version that has the ball as the second player for now. The crappy AI is there just to show you how the second player could interact. Unfortunately you can't resize the ball's height in multisprite kernel, and I can't use one of the other player sprites without losing easy collision detection. It might be fun playing the dot though. Could fit through tight spaces but you just move slower (to give it a handicap).
2padv0.1.2.bas2padv0.1.2.bas.bin
-
I wouldn't bother with the AI, I'd just not have the second sprite in a 1 player game.Here is a one player version that shows how I'm thinking an object can be carried simply. It doesn't work as smoothly as Adventure does it though.
-
2 player adventure game in bB.
Now playable by 2 players, and you can win!
Return the cross to the dark blue castle, but don't get trapped or killed by a dragon or flying eye!
Find the wand to teleport or the wand to shoot dragons and eyes.
Suggestions are all welcome! (Especially those that can help me reduce the code size- trying to keep under 4k).
-
You don't need to remove the pfscrolls, just do something like:if s = 0 then pfscroll upup : pfscroll upup : s = 1
So that it's only done once.
The other two issues I'd need more time than I have to fix.
EDIT:
This is called a "flag", and the more efficient way of doing it is to use the bits of a variable, since each bit can be either Off (zero), or On (one). If you set aside a variable for this use, it can be used as six different flags by setting each bit. So it would be:
if s[0] = 0 then pfscroll upup : pfscroll upup : s[0] = 1
The way the score bounces around when vertical scrolling is used is a bug introduced in bB 1.0, no fix yet as far as I know...
Good idea! I think I'll do that. I was thinking at first maybe pfscroll upup had to do with the other playfield collision detection bugs but it didn't.
-
You might also want to add a title screen and sounds/music. Also you could use Curtis's minikernel for multiple scores and allow a two player game. And some dice transitions might be nice (maybe you could use pfscroll, pfvline, pfhline, and/or pfpixel to do transitions like having the dice scraped from the table or having them evaporate.
-
Curtis,
Can you look at the following code and tell me why playercolors can be set in the racetrack screen but not the main title screen?
Thanks!
-
Still having problems with scorecolors and collision detection though.
-
(double posted)
-
That would be your use of:pfscroll upup : pfscroll up up
That is correct. When I remove that code the problem doesn't happen anymore, but since it is a hack to reduce the vertical resolution of the playfield, I also can't use as much of the playfield as I could before. I reduced the playfield by one block after removing that pfscroll business and it works. Thanks!
-
Ok this is really wierd. If you move a car over the finish line enough to win (it is not that hard to do after you get the hang of it) you will win, and if you hit reset, the screen (including player scores) moves up by almost one playfield row.
If you do it again, it resets back to the way it was. Wierd!
Also playerscores for some reason can't have color set on them in the title loop as it doesn't appear to take for some reason. Not sure why.
And of course there is the issue I said before about one player always thinking it is colliding with the playfield when it isn't and another player never recognizing it hit the playfield, even though the other two players detect collisions with playfield fine and there is really no difference in the code. It must be some strange timing issue I guess?
At least I have an "interesting" title screen now...
-
Can anyone tell me why collision detection between player and playfield is not working correctly? For 2 of the players it works. The other 2 one never detects it and the other seems like it always thinks it is colliding even if it isn't.
-
0.3a has commented, clearer code (thanks for the suggestion, Mike!)
playfield collision not working correctly for 2 of the players. let me know if you can figure out why
-
Hilooks really nice.
greetings Walter
Thanks, Walter! I know there is a lot left to do. Please let me know if you have any ideas.
-
Good !! why the screen named 0.9 ?That was built off of my latest "snapshot" build version locally. I haven't released it because there weren't any significant changes from 0.8 (yet).
If you have idea for how this could be a better game, let me know. I might even try to go down the road of player sprites, but is just going to be a pain since I can't use collision detection easily if I'm reusing player0 and player1 sprites.
-
Yes, that's it! Thank you. That solves one of the problems. That's what I get for copying large amounts of code and then forgetting to change parts of it. Unfortunately, it still draws a blank on some die.That's because of this
if b>=84 && b<126 then b=3 : pfpixel 5 0 on : pfpixel 6 1 on : pfpixel 7 2 on
if b>=128 && b<168
{/quote]
Note is <126 and then b>=128. so if is 127 then is blank.
-
I'm still having trouble driving the car, but at least I can actually influence its direction now!
Thanks,
Mike
Mike,
Thanks for the suggestions! I'll definitely make sure I go back and add in some more dims and comments like you said.
Let me know how you'd like the driving action to change (if you think it should react faster, etc.) and it would be totally awesome if you could try it out with real paddles and let me know (unless you just did- in that case I want to know every detail!).
-
Boulder Dash has already been done for the 2600, but unfortunately, it can't be released.
Michael
That sucks. I'm assuming it is tied up in some legal issue.
Edit: I just now found the thread where the Boulder Dash stuff is discussed here: Boulder Dash for the 2600. This is totally ridiculous, but at the same time I think it is super cool that this game has lived on.
-
Occasionally, it misses a few triples, or not count either a one or a five. Also, it counts three ones as 1,300 even though it should be 1,000. I also have a similar problem with three fives (I know the problem to the last one, but I don't know the solution.)Here's your problem
number_threec=rand
if c<42 then c=1 : pfpixel 11 1 on
if c>=42 && c<84 then a=2 : pfpixel 10 0 on : pfpixel 12 2 on
if c>=84 && c<126 then a=3 : pfpixel 10 0 on : pfpixel 11 1 on : pfpixel 12 2 on
if c>=128 && c<168 then a=4 : pfpixel 10 0 on : pfpixel 10 2 on : pfpixel 12 0 on : pfpixel 12 2 on
if c>=168 && c<210 then a=5 : pfpixel 10 0 on : pfpixel 10 2 on : pfpixel 11 1 on : pfpixel 12 0 on : pfpixel 12 2 on
if c>=210 then c=6 : pfvline 10 0 2 on : pfvline 12 0 2 on
Did you mean to set a there the 4 statements? From looking at the code I think you mean to set c.
-
Nothing beats a real analog device (Stelladaptor with paddles) or even a joystick with an analog axis. But it's certainly easy enough to disable the mouse entirely.It would be nice. I'm getting more careful now about the mouse so it isn't as bad. I wish I had 2 stella adaptors and 2 sets of paddles. I know what to ask my kids to get me for Christmas.
Or should I just ask for a real 2600 with set of games and 2 sets of paddles, and a croc cart/etc.? -
I've read through the code and all I got from it was a headache. I can sort of follow it, but it seems to me that there would be a much, much easier way to go about it. Sorry I can't be any help, but honestly I never would have gotten as far as you have.I fixed the problem. I was doing some messed up stuff in player definition.
I was afraid that my code sucked. Now I know.

I had started to add comments in the code, but then the code got so long, and it was easier for me to read it when it was short. If I didn't have to use temp variables for everything (if I had more vars) it might be easier to read. I should also just use dim to alias the temps to make it more straightforward, but I'd be afraid I or someone else might think that those vars actually store something that isn't temporary.
Please let me know how I can better write it to make more sense.
-
0.3 released
Fixed the problem with the player sprites. It looks much better now (you can tell where you are going).
Lap counting still needs work as does gameplay. If anyone wants to suggest different player sprites please do. I was just trying something different than the normal indy 500 car sprite, but am not against using it if you think that would be better. All suggestions welcome. If I could use 8.8 fixed decimals, the action would be smoother, but I don't have enough free vars to do that as far as I have tried.
Note: there was a problem with two of the sprite with playfield collision detection so I had to turn that off.
-
Neat!
It misses a few things, and I want someone to take a look at the code and tell me why.Could you explain what about the scoring that it misses?
-
Also note that Michael was working on a wiki and potentially could keep a copy of it there that everyone could edit. In a different thread we were talking with the AtariAge webmaster about having AtariAge host a wiki, but their concern is that they would want it to integrate with the existing forum, and unfortunately there are many mainstream wikis out there that can do it the way that they want it I think. So for now we have the forum and Michael's wiki.

2 Player Adventure
in batari Basic
Posted
Ok, here are the ideas I've had so far that I'm going to try to implement. Let me know what you think or if you have other ideas:
Items:
* Shovel - can dig away playfield in some (brown dirt) rooms
* Gun - shoot enemies in the direction you are moving
* Magic item - not sure they purpose of this yet but will involve sound and flashing background maybe. Maybe it opens up portal to void?
Inventory control:
* Press button quickly to use item
* Hold button to drop item
* Can exchange item with another item just by touching other item
* Second player can take your item
Rooms:
* Open rooms
* Mazes
* Dirt room you have to dig through
* Void - completely empty rooms where there may be lots of monsters and scary background sound
Non-inventory items:
* Transporter/entry point to void (both players must touch in 2 player game)
* Doors that aren't always open
* Painful flashing walls
Monsters:
* Regular Adventure dragon
* Room filled with baby dragons
* Floating eye
* Big dragon
* Big floating eye
Goal:
* Retrieve something besides a chalice?
* Return home?
That's all I've thought of so far. No idea yet how much will be doable.