Jump to content



1

Ature - An adventure game WIP


20 replies to this topic

#1 beoran OFFLINE  

beoran

    Star Raider

  • 77 posts

Posted Fri Jun 5, 2009 3:50 PM

I wanted to post this in the batari forum but it wouldn't let me. If it's OK, maybe theops can move it?
Anyway, this is Ature , a WIP of a somewhat Seiken Densetsu-like action/adventure/RPG.
I'm writing it just to see if I can finish such a project.

Story: Kill the evil queen who cursed your land and captured your beloved.
Controls: Joystick moves into direction. Button swings sword.

I didn't test it on real hardware, and I can't do so. I might need help with that
from someone who has the hardware. I know the collision detection isn't very good,
so I need ideas about that. >_< Any other comments would be nice. ^_^

Attached Thumbnails

  • ature.bas.bin_1.png
  • ature.bas.bin_4.png

Attached Files



#2 mika OFFLINE  

mika

    Star Raider

  • 69 posts

Posted Fri Jun 5, 2009 5:55 PM

nice.
as you say, definitely needs some rework on collisions, it's uncomfortable to go through the maze at the moment. But i like those kind of games, keep working!

Attached Thumbnails

  • ature.bas.bin.png


#3 SeaGtGruff OFFLINE  

SeaGtGruff

    River Patroller

  • 4,543 posts
  • Location:Georgia, USA

Posted Fri Jun 5, 2009 7:04 PM

That's neat, the two screenshots you posted bear a very slight resemblance to a game I started to tinker on last year. I never posted anything, or got much beyond a forest maze with a house in the middle of the maze. :) I'll look at your code later to see if I can offer any help with the collision detection.

Michael

#4 beoran OFFLINE  

beoran

    Star Raider

  • 77 posts

Posted Sat Jun 6, 2009 2:41 AM

Mika,
Yes, when testing, I also get stuck in the walls forest maze at times. You can try to press the reset button to teleport back to your house with all the game state intact, but even that isn't guaranteed to work always.

SeaGtGruff,
Thanks, any help would be appreciated.

#5 mika OFFLINE  

mika

    Star Raider

  • 69 posts

Posted Sat Jun 6, 2009 7:12 AM

There was the topic explaining how to deal with collisions in batari basic somewhere on the forum, unfortunately i cannot remember what was the name of that. Something like "PF pixels to sprite pixels conversion"?

This is actually quite a tough subject in bB, i was frustrated enough to stop working on my game long time ago because of difficulty in handling the collisions. It looks like you can quite often have it totally messed up, like getting the player stuck permanently, which happens in your game at this stage as well. Hopefully you will find a sollution.

And damn, that Black Knight is tough beast to beat, suppose you have to find some extra equipment before going into green maze ;)

#6 SeaGtGruff OFFLINE  

SeaGtGruff

    River Patroller

  • 4,543 posts
  • Location:Georgia, USA

Posted Sat Jun 6, 2009 1:40 PM

View Postmika, on Sat Jun 6, 2009 9:12 AM, said:

There was the topic explaining how to deal with collisions in batari basic somewhere on the forum, unfortunately i cannot remember what was the name of that. Something like "PF pixels to sprite pixels conversion"?
There's basically two different ways to handle collisions (as far as players moving around and being prevented from moving around-- not collisions that result in "death" or the loss of points, etc.).

One way is to go ahead and let the collision occur, then bounce the player back to where they were before the collision occurred. This approach is much easier, is usually pretty simple to handle if you do it right, and requires no conversions between playfield coordinates and player coordinates.

The other way is to try to keep the collision from happening in the first place. This approach is usually harder to handle correctly, because you have to "peek" at the location where the player is about to move to, and prevent them from moving there if anything is "in the way," so it does require conversions between playfield coordinates and player coordinates, and any errors or oversights can result in glitches.

The first approach tends to result in the player "sticking" to the walls, at least while the person is still pushing the joystick in a direction that causes a collision to occur, so that makes it more difficult for the player to move smoothly through a maze unless the person is careful to keep the player from ever touching the walls. The second approach allows the player to move smoothly through a maze, because it can never collide with the walls.

Michael

#7 beoran OFFLINE  

beoran

    Star Raider

  • 77 posts

Posted Sat Jun 6, 2009 1:44 PM

Mika,

Thanks for the tip on that pixel to playfield, I found the link, and I'll read it later.
http://www.atariage....s sprite pixels

Yes, collision detection is a bit difficult. IMO, the hardware collision detection is fine, but collision response is difficult because the depth of penetration is unknown, and also, there is a bit too few memory to keep track of trajectories well. Even for the similar game I'm implementing on normal PC hardware, it was a tough nut to crack, and I'm still not completely happy with it either. Seeing that even classic games like Adventure weren't able to solve the problem completely (even in that, you or items can get stuck, hence the 'reset functionality'). I think I'll have to settle with a less than perfect collision, and perhaps modify the playfield so it's more difficult to get stuck, and also keep the "reset teleport" in there so your game isn't completely ruined when you do get stuck. I'll try to see how "Cave In" handles it, too.

Black Knight? Perhaps I should make that sprite more feminine, that's the evil queen, the final boss. ^_^'
At the moment, the only way to win the game would be to level up by killing slimes and crabs until your health bar gets really long (you'd need to kill about a 1000 or so), and then try it. The key items needed to make the game more easy to win cannot be obtained yet, since I didn't implement the bosses that drop them yet.

#8 beoran OFFLINE  

beoran

    Star Raider

  • 77 posts

Posted Sat Jun 6, 2009 1:49 PM

SeaGtGruff,

Yes, for now I've always used "push back" collision resolution, even on PC game I'm programming. It seems simple, but it really can get complicated too, because there are situations in which the "push back" fails to push back correctly. Now, I try to solve this by having extra "push out" code that tries to resolve a stuck item or player, but it doesn't help much either.

Preventive collision detection as you describe would be nicer, I guess, so I'll try that. i hope I have enough resources to pull it off. ^_^

#9 SeaGtGruff OFFLINE  

SeaGtGruff

    River Patroller

  • 4,543 posts
  • Location:Georgia, USA

Posted Sat Jun 6, 2009 2:33 PM

View Postbeoran, on Sat Jun 6, 2009 3:49 PM, said:

SeaGtGruff,

Yes, for now I've always used "push back" collision resolution, even on PC game I'm programming. It seems simple, but it really can get complicated too, because there are situations in which the "push back" fails to push back correctly. Now, I try to solve this by having extra "push out" code that tries to resolve a stuck item or player, but it doesn't help much either.

Preventive collision detection as you describe would be nicer, I guess, so I'll try that. i hope I have enough resources to pull it off. ^_^
Personally, I think the "push back" approach is better (and maybe more realistic) for an adventure game, because it sort of simulates the idea of running into a wall (by accident) and getting "stunned" or slowed down momentarily. But for a maze game like Pac-Man you'd want to use the "preventative" approach, because it would be too frustrating for the player to get caught by the enemy because he or she didn't turn a corner "just right." Of course, that same argument could be extended to being chased through a tight maze in an adventure game.

Anyway, the "push back" approach is very easy if you do it correctly. Basically, you need to save the x and y movements before you apply them, so that if a collision occurs you can un-apply them to push the player back. You don't need to check for each direction separately-- and if you do, it can lead to glitches. Instead, just save both directional changes (x and y), then apply them at the same time, draw the new screen (new player position), then if a collision occurs, un-apply both x and y directional changes at the same time *before* you check for the new movement.

Here's a little demo program I did a few years ago, which moves a little stick figure around a maze of rooms. I've had to make some coordinate adjustments in it for the changes between batari Basic 0.35 and 1.0, so hopefully it doesn't have any glitches in it. But the relevant portion dealing with the collisions (with other irrelevant lines removed, and comments added) is shown below:

loop

   rem * get the new change in the x or horizontal direction
   p0_x = 0 : rem * initialize it to 0 (no left-right movement)
   if joy0left then p0_x = 255 : rem * adding 255 is same as subtracting 1, so move left
   if joy0right then p0_x = 1 : rem * move right
   player0x = player0x + p0_x : rem * now apply the x movement to original position

   rem * get the new change in the y or vertical direction
   p0_y = 0 : rem * initialize it to 0 (no up-down movement)
   if joy0up then p0_y = 255 : rem * adding 255 is same as subtracting 1, so move up
   if joy0down then p0_y = 1 : rem * move down
   player0y = player0y + p0_y : rem * now apply the y movement to original position

   drawscreen

   rem * now be sure to check collisions and take action *before* looping back to get new movements
   if collision(player0,playfield) then gosub knock_player_back

   goto loop

knock_player_back

   rem * un-apply the previous movements to move the player back to original position
   player0x = player0x - p0_x
   player0y = player0y - p0_y
   return
Of course, if you need to save cycles and/or bytes, you could consolidate some of this, like putting the initializations on the same line (which saves 2 bytes and 2 cycles), or putting the un-apply statements right inside the if...then instead of calling a subroutine (which saves 4 bytes and 12 cycles):

loop

   p0_x = 0 : p0_y = 0 : rem * saves 2 bytes and 2 cycles

   if joy0left then p0_x = 255
   if joy0right then p0_x = 1
   player0x = player0x + p0_x

   if joy0up then p0_y = 255
   if joy0down then p0_y = 1
   player0y = player0y + p0_y

   drawscreen

   if collision(player0,playfield) then player0x = player0x - p0_x : player0y = player0y - p0_y
   rem * saves 4 bytes and 12 cycles

   goto loop
Note that you do *not* need to redraw the screen immediately after pushing the player back; just loop back and get the new inputs. If the person keeps pushing the joystick in the same directions, the player will keep colliding with the wall but won't be able to go any further, and will be bounced back as soon as the person stops pushing on the joystick.

Michael

Attached Files



#10 beoran OFFLINE  

beoran

    Star Raider

  • 77 posts

Posted Sat Jun 6, 2009 5:22 PM

SeaGtGruff,

Thanks for the demo code. What I did was something much like this but still I had some problems, because the hardware collision does take into consideration the different frames of my animation, which might have changed on the moment the collision is detected. That way, the push back may not be sufficient and the sprite may get stuck.

Anyway, I gave preventive collision detection a try, and to me, it feels much more comfortable to me, and as a bonus, it allows for some overlap between the sprite and the field which I think to be somewhat aesthetically pleasing. Here is a version that uses this kind of collision detection for the player. I'm only worried a bit about if it will run on the real hardware, so this time cycle debugging is on (without mincycles), but I don't quite know how to interpret the figures. It'd be great if anyone could run it on real hardware and tell me if I'm still OK or not.

Attached Files


Edited by beoran, Sat Jun 6, 2009 5:24 PM.


#11 mika OFFLINE  

mika

    Star Raider

  • 69 posts

Posted Sat Jun 6, 2009 6:14 PM

Collisions are handled much better now, but you still get occasional weirdness, not that annoying anymore, but probably you will want to get rid of that in the final, polished binary.

And... Yay! She is kissing me! :)

#12 beoran OFFLINE  

beoran

    Star Raider

  • 77 posts

Posted Sat Jun 6, 2009 11:46 PM

Mika,

Which weirdness did you notice? You're able to overlap somewhat with the playfield now, so that's mostly intentional. For now, the only way you could stuck into the wall is from the kick-back after the enemy hits you, because that doesn't do any collision checking yet, but I'll add that ASAP.

Oh and kudos on beating the game just by leveling up. I never even tried it myself like that. ^_^

#13 mika OFFLINE  

mika

    Star Raider

  • 69 posts

Posted Sun Jun 7, 2009 6:55 AM

i have noticed two weird things. once i got stuck in the forest, gluing myself to the tree on the first screen on the right to the house. of course reset was needed. then in the green maze, when going down i overlapped the playfield area with a screen change by nearly half of the sprite. i was able to progress. so that's fine, but as i said, if you ever think about releasing the game in the future, that's probably something that needs polishing a bit, just for the fact how strange it looks. maybe not, maybe that is just me?

unfortunately i didn't take a screenshot :(

oh, and by the way - levelling up did take long, but not that long as you said, so maybe the reward for killing the jellybeans should be smaller?

#14 beoran OFFLINE  

beoran

    Star Raider

  • 77 posts

Posted Mon Jun 8, 2009 4:07 PM

Ok, a new version, still in progress, but I'm already adding and moving a lot of stuff The gae is currently unwinnable because the black curse blocks the entrance, and you can't find the items to defeat it yet.

Attached Files



#15 Robert M OFFLINE  

Robert M

    Stargunner

  • 1,481 posts
  • Rootbeer!
  • Location:Western NY state

Posted Tue Jun 9, 2009 4:46 AM

View Postbeoran, on Mon Jun 8, 2009 5:07 PM, said:

Ok, a new version, still in progress, but I'm already adding and moving a lot of stuff The gae is currently unwinnable because the black curse blocks the entrance, and you can't find the items to defeat it yet.

Good stuff! keep going. :)

#16 beoran OFFLINE  

beoran

    Star Raider

  • 77 posts

Posted Tue Jun 9, 2009 1:42 PM

Ok, this is it! This version is completely playable and winnable, and all content I wanted to put in is in. You can win in different ways, but can you find all items? How are the fights? Too hard or too easy? Just let me know. I also attached a text for the manual.

Attached Files



#17 beoran OFFLINE  

beoran

    Star Raider

  • 77 posts

Posted Tue Jun 9, 2009 3:35 PM

And this is an easier version with a few sound effects added. This one requires only 25% the experience. It's still challenging to beat certain bosses. Sorry to post two versions so soon one after the other.

Attached Files



#18 beoran OFFLINE  

beoran

    Star Raider

  • 77 posts

Posted Wed Jun 10, 2009 3:46 PM

And the next one! This one fixes a few bugs with the shooting. It's now also actually possible to obtain the shield in two different ways.

Attached Files


Edited by beoran, Wed Jun 10, 2009 3:47 PM.


#19 Legend OFFLINE  

Legend

    Moonsweeper

  • 331 posts
  • Location:Antioch, CA

Posted Thu Jun 11, 2009 3:25 AM

Pretty cool game. reminds me of Cave in a little. How do I get past the pitch black area by the cave? Is there a torch somewhere? The sword sprite might look better if it's possible to touch it up. maybe at least so it doesn't loook like it's floating.

#20 beoran OFFLINE  

beoran

    Star Raider

  • 77 posts

Posted Thu Jun 11, 2009 1:17 PM

Ok, yet another version. In this version the sword is attached to the sprite, and also thinner, which makes the game harder. To compensate, now, when you get a game over, you can press reset to return to Signe's house with most game state intact. You will lose some health, all your Numen and some exp, though. This type of game normally should have a save game anyway, so by allowing you to continue after a game over I get a comparable effect. I also moved some monsters around. Maybe this makes the game too easy though, but I know that combat isn't the strongest point of this game anyway. If you win the game, you can reset and you'l be leveled up to level 90, so you can look for any items you missed.

As for the dark cave... look for a switch close by. ^_^

Attached Files



#21 beoran OFFLINE  

beoran

    Star Raider

  • 77 posts

Posted Sun Jun 14, 2009 9:54 AM

Well, this game has reached the point where I'm fairly satisfied with it as it stands. I'dd try to do some bugfixes o smaller sugestions, but probably no more big changes. It was a fun project, but now I'll focus again on my ain project, Eruta. ^_^




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users