Ascurrete

[devwebcl]

Hi,

 

I am trying to do a small puzzle game, based on orbox-b and excit.

Well, I am going to create new puzzles, for now I am only using the first one from orbox-b

 

However I don't know why when the joystick is moved to the left the screens starts to flick.

 

Devwebcl

ascurrete.bas.bin

Edited March 28, 2010 by devwebcl

[devwebcl]

A screenshot is attached.

Edited March 27, 2010 by devwebcl

[yuppicide]

If nobody takes a look I'll do it tomorrow. I'm heading to a party tonight.

[+Random Terrain]

You posted a playable .bin, not the .bas file, so we can't see the code.

[yuppicide]

I thought I mistakenly downloaded the wrong file, since I had the .bin also.

 

Looks like it would be a fun puzzle game with lots of levels. Good work so far.

[devwebcl]

Well,

 

I have problem when the joystick is move to the left and also the collision detection when is going down (if you keep moving down the joystick the player get into the playfield).

 

Well, my code is still under development so it is not that clear.

ascurrete.bas

[devwebcl]

Ok. I've solved the flickering, but still I have problem with the collision detection when it is going down... any tips ?

 

Thanks anyway for watching the game. I will update any news.

 

Devwebcl

Edited March 30, 2010 by devwebcl

[+Random Terrain]

Ok. I've solved the flickering, but still I have problem with the collision detection when it is going down... any tips ?

 

Thanks anyway for watching the game. I will update any news.

Can you post your latest .bas file?

[devwebcl]

I only assigned another alias for p0_x and p0_y variables.

ascurrete2.bas

Edited March 30, 2010 by devwebcl

[+Random Terrain]

It looks like you're animating by one frame sometimes after collision. If you keep the sprite at the same height in each frame, the problem might go away.

[yuppicide]

Some comments on your game.

 

I tried Orbox-B last night. Downloaded a flash version and played. It had 30 levels.

 

If you do nothing but "walls" it will be very simple to make the game. I could be wrong here, but I see you're defining your levels using the playfield command. I could be wrong, but since you're not defining that complex of a playfield, maybe this will help:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#pfpixel

 

You can just draw a few pixels. Maybe someone else can chime in on which uses less space or processor cycles. It was just an idea I had.

 

I think with 4k or 8k you'll be able to squeeze in a bunch of levels. I currently have a puzzle game that has 50 levels built in.

 

I think if you plan on adding the bombs and warps might you might need to learn how to update the screen differently. Since you can only display two sprites in the standard kernel (player0 and player1) you might need to use player1 to define multiple bombs. You might need to display 1 bomb on frame1, the other bomb on frame2, etc. I'm not well versed in this as I've never done it myself. Just seen others do it.

[devwebcl]

thanks for the feedback.

 

I am using already that command, I guess 30 levels is a good number, now I need my imagination to fly

Edited April 1, 2010 by devwebcl

[yuppicide]

The game I am making is 16k size I believe. I have PLENTY of room to add another 50 levels in! I was planning on adding in a secret puzzle game that uses the same playfield and had 50 levels, but I had trouble getting it to work.

[devwebcl]

An update, please let me know if you can finish all the levels... although there is a repeated level

ascurrete.bas.bin

Edited May 2, 2010 by devwebcl

[Animan]

Maybe you could make generate random levels? I dunno, it is possible, but could be a bit hard. Definitely would give the game more replay value...

 

The game, though, is fun. And kinda hard, too.

Edited May 26, 2010 by Animan

[yuppicide]

I think it would be really hard to make random levels because the program would need to calculate all possibilities to determine if a solution is possible.

[Animan]

I think it would be really hard to make random levels because the program would need to calculate all possibilities to determine if a solution is possible.

 

Never thought about that... Still would be fun. Maybe you could make it figure out every solvable solution, and modify the whole thing to let only one exist...

 

Yeah, that'd be hard too. Even when it is fully programmed, it'd take to 2600 awhile to get an actual puzzle.

Edited May 27, 2010 by Animan