Mr. Flanksteak - new game

[+atari2600land]

You'd think I'd get discouraged & quit, but nope. I'm making a platform game now. I'd really like attendo to release the .bas file for his Twird game so I could learn by example how to jump & add enemies & stuff. Here's what I have so far.

 

Are lines 950-990 really neccessary cuz I'm hoping there's a better way to do this.

flanksteak.bin.bin

flanksteak.bas

[+atari2600land]

I worked a little more on this. I'd really like to replace just skipping over to the place you land with an actual jump. So, attendo, if you're reading this, please put the .bas file for Twird in a reply in this topic.

flanksteak2.bas

flanksteak2.bas.bin

[SeaGtGruff]

You'd think I'd get discouraged & quit, but nope.

That's good to hear! We don't want you to get discouraged and quit, we want you to have fun making new games!

 

I'm making a platform game now. I'd really like attendo to release the .bas file for his Twird game so I could learn by example how to jump & add enemies & stuff.

I don't think I've seen any new posts from attendo in several months; I hope everything is okay with him.

 

Here's what I have so far.

 

Are lines 950-990 really neccessary cuz I'm hoping there's a better way to do this.

I was going to mention this last night in the thread about Ants!, but I got wrapped up in the problem with score. Yes, there are easier, better ways to draw and erase playfield displays. The method you're using looks like it was generated with the playfield editor in the 2600IDE program, which outputs a series of pfpixel statements based on which playfield blocks you click on, and in what order, including whether you turned a particular block on or off. That playfield editor tool is handy to use, and there can be benefits to using a series of pfpixel commands to turn specific playfield pixels on or off, but it isn't time-efficient or memory-efficient to draw an entire playfield that way.

 

One alternative is to use the pfhline and pfvline commands to draw and/or erase horizontal and vertical lines of playfield pixels. For example,

250 pfpixel 21 1 on
252 pfpixel 22 1 on
254 pfpixel 23 1 on
256 pfpixel 24 1 on
257 pfpixel 25 1 on
258 pfpixel 26 1 on
259 pfpixel 27 1 on
260 pfpixel 28 1 on
262 pfpixel 29 1 on
264 pfpixel 21 2 on
266 pfpixel 21 3 on
267 pfpixel 20 4 on
268 pfpixel 19 4 on
269 pfpixel 18 4 on
270 pfpixel 17 4 on
271 pfpixel 16 4 on
272 pfpixel 15 4 on
273 pfpixel 14 4 on
274 pfpixel 13 4 on
275 pfpixel 12 4 on
276 pfpixel 11 4 on
277 pfpixel 11 5 on
280 pfpixel 11 6 on
281 pfpixel 10 7 on
282 pfpixel 9 7 on
283 pfpixel 8 7 on
284 pfpixel 7 7 on
285 pfpixel 6 7 on
286 pfpixel 5 7 on
287 pfpixel 4 7 on
288 pfpixel 3 7 on
289 pfpixel 2 7 on
290 pfpixel 1 7 on

can be replaced with the following:

250 pfhline 22 1 29 on : rem horizontal line from (22,1) to (29,1)
260 pfvline 21 1 3 on : rem vertical line from (21,1) to (21,3)
270 pfhline 12 4 20 on : rem horizontal line from (12,4) to (20,4)
280 pfvline 11 4 6 on : rem vertical line from (11,4) to (11,6)
290 pfhline 1 7 10 on : rem horizontal line from (1,7) to (10,7)

This is more memory-efficient than turning on the individual playfield pixels. For example, compiling the original program shows 1876 bytes free, but replacing lines 250 through 290 with the five lines above shows 2108 bytes free-- a savings of 232 bytes. And we haven't even replaced the other pfpixel statements yet, so you could save even more bytes.

 

However, this still isn't nearly as time-efficient as it could be, since the pfhline and pfvline commands have to go through loops to turn a row of pixels on or off between a starting position and an ending position, and it's more time-efficient to control 8 pixels at a time by "poking" the playfield bytes. bB doesn't have a "poke" command, but you can set an entire playfield byte to a specific value. Last year I posted a few examples of how to draw an entire playfield using data statements to define the playfield's appearance, and a couple of routines to "poke" those values into the playfield bytes. I can post an example later of how you can use this to draw your Ants! title screen, or your platform game screen, but batari added a feature to bB version 0.99 which does the same thing-- only better-- if you're using the multisprite kernel, so you might want to use that method instead.

 

Anyway, using the pfhline and pfvline commands is often the most memory-efficient way of drawing an entire screen, so I suggest you work with that method first. And if you need to clear the entire playfield, you can do it by turning off all of the playfield pixels using pfhline in a loop, as follows:

950 for a=0 to 10 : pfhline 0 a 31 off : next : rem clear rows 0 through 10, from (0,a) to (31,a)

I'm attaching an updated version of your code, which replaces the pfpixel commands with pfhline and pfvline commands. When it's compiled, there are 2628 bytes free, so the savings is 752 bytes.

 

Michael Rideout

flanksteak1a.bas

[+atari2600land]

Cool! Thanks, Mike, I was hoping there was a way to turn off all the pixels in one foul swoop. And the pfhline and pfvline stuff is groovy.

[+atari2600land]

Since attendo doesn't appear to be here anymore, I'm sticking with the "teleportation" device. Press fire when you want to jump and Mr. Flanksteak will magically appear wherever you're supposed to jump to. I'm up to 5 screens now cuz I've been working on it for the past 2 hours. Let me know what you think.

flanksteak2a.bas

flanksteak2a.bas.bin

[jbanes]

What you need is gravity. Very simply, you have logic that constantly applies force to a character in the downward direction. He is only stopped by reaching some point or colliding with something. When the character jumps, you simply give him an upward velocity in excess of gravity. The gravity will slowly wear away his vertical motion, and eventually bring him back to the ground.

 

The easiest way to implement this is with playfield collisions. Let's say your character's feet will always stick just inside the playfield. That allows the following pseudo-code to work. (Note that comments are denoted with a single quote. This is standard BASIC practice, but I don't think it works in bBASIC.)

 

let GRAVITY = 0.02

dim velocity = a.b  'This is a 16 bit fixed point number!
dim yposition = c.d  'This is a 16 bit fixed point number!

velocity = 0.0
yposition = 0.0  'He's up in the air! Don't worry, he'll fall to the ground.

start:
velocity = velocity + GRAVITY 'The force of gravity!

if collision(playfield, player1) then velocity = 0.0 'We're standing on something, so no velocity!
temp1 = 0.0 - 4.0 'We need to precalculate this because bBASIC doesn't allow for the calc inside an IF statement
if joy0fire then velocity = temp1 'Make our character jump with the force of 4 full units!

yposition = yposition + velocity 'This changes the position of the character. i.e. Falling
player0y = c 'We're setting the pixel position of the player here. Note that we only use the whole number part of the yposition.

drawscreen
goto start

 

That should be a pretty good overview. There's one bug in it, in that it doesn't check if the character is on the ground when he jumps. This means that he'll take off like a rocket rather than springing once. You'll want to change the "if colliision" part to gosub to a special area. In that area of code, you should set the velocity to 0, THEN check joy0fire. That will prevent the character from jumping in midair. The subroutine would look something like the following. (Prepare for more psuedocode!)

 

[...previous code...]

if collision(playfield, player1) then gosub onCollision
rem if joy0fire then velocity = 0.0 - 10.0 'We removed this here so that it doesn't do anything!

[... lots more code...]

onCollision:
velocity = 0.0 'The character is standing, don't make him fall through the floor!
temp1 = 0.0 - 4.0
if joy0fire then velocity = temp1 'Make our character jump with the force of 4 full units!
return 'Return to the previous code

Edited June 19, 2006 by jbanes

[+atari2600land]

It's finally finished, and it's one of the biggest Batari Basic games I know of.

flanksteak4a.bin

flanksteak4a.bas

Edited June 23, 2006 by atari2600land

[Gregory DG]

Mmmm... Flanksteak...

[+Atarius Maximus]

It's finally finished, and it's one of the biggest Batari Basic games I know of.

 

It's a good start, but in my opinion you need to give it a little more polish before you call it complete. There's some really good example code in this forum that you could examine and apply to your game. To make your player jump up in the air, check out the "matario" demo game, the first code example posted in that thread is short and very easy to understand, it's a very good example of how to implement gravity & jumping. It also demonstrates how to animate sprites. Take some time to browse through all the code that has already been posted and read all of the threads in this forum -- there's lots of great stuff that's been posted that you can learn from.

 

I'd also look into fixing the following issues I've noticed in your game, listed below. I'm just trying to give you some constructive criticism here -- I'm not trying to discourage you. I'm glad you're making new games -- I love seeing new games developed!

 

Issues:

 

Your player can walk off some platforms and hang in midair on some screens.

You can't move your player to the right on some screens.

There's no way to "die", you can keep trying over and over again until you reach the end of the game.

It seems that falling down in the hole on the 2nd screen puts you back to the first level, falling on other levels doesn't take you back to the beginning? I'm not sure how you've got that set up, but it would be better if it was more consistent.

It's difficult to know exactly where you're supposed to go on the screens, maybe add some vertical walls to block off areas you don't want the player to walk off of. You could then use collision detection with the playfield, along with the player's X position, to fix the problem of the player hanging in the air.

 

Suggestions/Ideas for improvement:

 

Add some obstacles in the game to make navigating the various screens more interesting. Maybe have missiles firing at you, or use the other sprite to have an enemy you have to avoid or jump over. Or, have an object that has to be collected on each screen before you move on.

Make moving between screens more consistent - if I travel to the right I can go back to the screen I was previously on.

Add real gravity and jumping to the game, as mentioned before. In addition to the matario demo, you can also check out my jumper demo for an example of how to implement gravity and jumping.

You could add a sprite animation, change the sprite when he's jumping or running, etc.

Add a score - maybe you could have the score increase every frame, and your score could be based on finishing the game in the shortest amount of time (e.g. lowest score)?

 

I hope this feedback helps a little bit. Keep at it, it's lookin' good!

 

Steve

[+atari2600land]

Your player can walk off some platforms and hang in midair on some screens.

It seems that falling down in the hole on the 2nd screen puts you back to the first level, falling on other levels doesn't take you back to the beginning? I'm not sure how you've got that set up, but it would be better if it was more consistent.

Add some obstacles in the game to make navigating the various screens more interesting. Maybe have missiles firing at you, or use the other sprite to have an enemy you have to avoid or jump over. Or, have an object that has to be collected on each screen before you move on.

Make moving between screens more consistent - if I travel to the right I can go back to the screen I was previously on.

Add real gravity and jumping to the game, as mentioned before. In addition to the matario demo, you can also check out my jumper demo for an example of how to implement gravity and jumping.

I can't do much more, I only have a little over 400 bytes left! But, I'll remove a screen and look at the Matario demo.

#1 - Yeah, I know, I need to fix that. When I said 'finished' I meant all the screens and all of the rough work is done.

#2 - There's no other holes to fall in.

#3 - If I can get him to jump, I'll add some enemies. I have the ball sprite left. As for firing missiles, I've been trying to get someone to show me code to make sprites fire missiles, but nobody seems to want to.

#4 - Intentional. You need to use the fire button if you hit a dead end in this version. I could rearrange the levels not to have weird stuff to teleport to if I can get him jumping.

#5 - I'll see what I can do.

[MausBoy]

Here is some quick and dirty jump code with comments. I say it's dirty cuz it can't tell if it's the sprites head or feet touching the background. For that you more or less have to stick a one-pixel missile inside your sprite and shift it around from head to feet, checking for collisions with the background each time. Anyway, here goes:

 

player0x = x : player0y = y - sets up your sprite, sub whatever vars you used

if !collision(player0, playfield) then y = y + 1 else a(1) = 1 - if your player is NOT (!) touching the playfield, drop him one pixel, otherwise set bit 1 of a to 1

if a(1) && collision(player0, playfield) && joy0fire then a(1) = 0 : a(2) = 1 - if the player is touching the playfield, and a(1) is on, and the player pushes fire, turn off a(1), turn on a(2)

if !a(1) && a(2) && b < 8 then y = y - 3 : b = b + 1 else b = 0 : a(2) = 0 - if a(1) is turned off, a(2) is on, and variable b is less than 8, subtract 3 from player0's y, and add one to variable b. If it is 8, reset b, turn a(2) off

Edited June 23, 2006 by MausBoy