Howdy BBS community!
As usual I'm indebted to the expertise of the users on here! This is my first complete game and I suspect it's barely held together code-wise. I'm super happy to get any feedback if you see something in the code that could be improved or makes your toes curl.
This is Coffin Dance! Why are you dancing? Play to find out!
Credits:
"Coffin Dance" by AJJ
Originally written by Ben Gallaty and Sean Bonnette
Screen FX using routines by ZerkDev
Art, arrangement, and dirty code by me, aka dreams.EGA, who you can find on Twitter and Instagram!
1 comment
I'm at a loss trying to decipher some code to better my understanding of core principles. Using the fantastic Advanced Micro Platformer by @mhughson as a subject of study I was reading into how the engine detects horizontal collision for the player. It does this through a collide_side function
function collide_side(self)
local offset=self.w/3
for i=-(self.w/3),(self.w/3),2 do
--if self.dx>0 then
if fget(mget((self.x+(offset))/8,(self.y+i)/8),0) then
self.dx=0
self.x=(flr(((self.x+(offset))/8))*8)-(offset)
return true
end
--elseif self.dx<0 then
if fget(mget((self.x-(offset))/8,(self.y+i)/8),0) then
self.dx=0
self.x=(flr((self.x-(offset))/8)*8)+8+(offset)
return true
end
-- end
end
--didn't hit a solid tile.
return false
end |
So I'm trying to make sense of this, and I can't seem to parse it in a way that makes sense. Breaking it down it assigns a local value offset to 2.66 roughly, because self.w is 8. And then it runs a for loop beginning at -2.66 through 2.66, with a "stride" of 2? So it counts up from -2.66 to 2.66 in increments of 2, and adds the current i to the y value? I assume this is checking for collision along the y axis of the sprite from top to bottom, but I cannot figure why it seems to check the y coord + -2.66, -.66, etc. So I assume I am misunderstanding something big.
And then it sets dx to 0, and then sets the player x to what I assume is the start of the wall tile. But I can't see where it accounts for player acceleration to adjust the end value, or how it compensates to avoid a "clip" into the wall.
I'm at my wits end trying to decipher this and further my understanding of how this math works. I've resorted to pen and paper drawing out different runs through this function, and it just seems like magic.
I'm wondering if anyone can help me, or otherwise direct me towards something to help me with these fundamentals. Happy Holidays!
Edit: Figured I'd link to the cart itself as well:
Hi everyone! First time posting on the BBS, long time fan but relatively new coder!
I've been going through the various tutorials found in fanzines, youtube, etc. and decided I'd start the foundations of a barebones strategy game using a fixed map grid of 8x8.
My logic was like this:
Draw the map using the map editor, then use a for loop to iterate through each cell and add it to a set of nested tables for x and y, getting its sprite value as a foundation for what can be done. Plains, mountains, water, etc.
The code in this cart is very rough but I wanted to print the contents of the tile the cursor was currently on. There's probably other issues but every time I try to call maptable via the this code:
function gamedraw()
local xs = curs.x
local ys = curs.y
cls()
map_draw()
cursor_draw()
location = maptable[xs][ys]
print(location)
end |
the maptable returns a "?" value and crashes the cart.
For reference here is where maptable gets filled:
function build_map_table()
maptable={}
for x=1,8 do
maptable[x]={}
for y=1,8 do
maptable[x][y]=mget((x-1),y-1)
end
end
end |
I've attached the cart for reference as well. Really I figure its an issue with mget values being printed but I also wanted to see if this entire concept is ill-conceived or if there is an easier way to accomplish the same task.
Thanks y'all!
