Here is what I am working on at the moment
I am re-using some of the scripts from Bell of Chaos for this. I wanted to work on a platformer with more traditional combat, since after re-playing Bell of Chaos, I remembered how frustrating it is to try and kill enemies.
This is still very much a work in progress.
Also, I am reminded of how much i hate doing maptiles. :P
Awesomenesssssssssssssssss
dOn'T MiNd mE! i'M jUsT CoNtAgIoUs!!!
Play Orbs CCG: http://orbsccg.com/r/4r6x
dOn'T MiNd mE! i'M jUsT CoNtAgIoUs!!!
Play Orbs CCG: http://orbsccg.com/r/4r6x
Bob the Hamster wrote:
Here is what I am working on at the moment
That's so awesome! How did you do the parallax? Is it just a background slice that moves along with the screen focus as the maptiles slide by?
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
⍠ C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
Thanks!
I designated map layer 0 and 1 to be parallax layers on every map.
When the map first loads, I loop through the maptiles and find the bottom-most right-most non-zero tile. I use that to calculate how big the parallax layer will be.
Then in my script that runs every tick to update the camera, I get the slice handles for those two map layers and adjust their x and y position based on the camera position.
Here is the script that I use to detect the size of a parallax layer
I store the size in the width and height of an invisible slice container.
here is the camera updating script:
Note that if you wanted to do this just for one map, and didn't mind hard-coding the size of the parallax layers, you could eliminate the first script entirely, and make the second script noticeably simpler.
I designated map layer 0 and 1 to be parallax layers on every map.
When the map first loads, I loop through the maptiles and find the bottom-most right-most non-zero tile. I use that to calculate how big the parallax layer will be.
Then in my script that runs every tick to update the camera, I get the slice handles for those two map layers and adjust their x and y position based on the camera position.
Here is the script that I use to detect the size of a parallax layer
Code:
script, get parallax size, para, layer, begin
variable(x, y, tile, found, fy)
found := false
for(y, map height -- 1, 0, -1) do(
for(x, 0, map width -- 1) do(
tile := read map block(x, y, layer)
if(tile <> 0) then(
fy := y
set slice height(para, (y + 1) * 20)
found := true
break
)
)
if(found) then(break)
)
found := false
for(x, map width -- 1, 0, -1) do(
for(y, 0, fy) do(
tile := read map block(x, y, layer)
if(tile <> 0) then(
set slice width(para, (x + 1) * 20)
found := true
break
)
)
if(found) then(break)
)
end
script, get parallax size, para, layer, begin
variable(x, y, tile, found, fy)
found := false
for(y, map height -- 1, 0, -1) do(
for(x, 0, map width -- 1) do(
tile := read map block(x, y, layer)
if(tile <> 0) then(
fy := y
set slice height(para, (y + 1) * 20)
found := true
break
)
)
if(found) then(break)
)
found := false
for(x, map width -- 1, 0, -1) do(
for(y, 0, fy) do(
tile := read map block(x, y, layer)
if(tile <> 0) then(
set slice width(para, (x + 1) * 20)
found := true
break
)
)
if(found) then(break)
)
end
I store the size in the width and height of an invisible slice container.
here is the camera updating script:
Code:
script, update camera, sl, begin
variable(x, y)
x := slice edge x(sl, edge:center)
y := slice edge y(sl, edge:bottom) -- 20
put camera(x -- 160, y -- 100)
# Update parallax layers
variable(i, layer, para, layer sl, mapw, maph, screenw, screenh)
screenw := slice width(sprite layer)
screenh := slice height(sprite layer)
for(i, 0, 1) do(
para := slice child(parallaxen, i)
if(i == 0) then(layer sl := lookup slice(sl:map layer 0))
else if(i == 1) then(layer sl := lookup slice(sl:map layer 1))
mapw := map width * 20
maph := map height * 20
set slice x(layer sl, (camera pixel x * (mapw -- slice width(para)) / large(1, mapw -- screenw)))
set slice y(layer sl, (camera pixel y * (maph -- slice height(para)) / large(1, maph -- screenh)))
)
end
script, update camera, sl, begin
variable(x, y)
x := slice edge x(sl, edge:center)
y := slice edge y(sl, edge:bottom) -- 20
put camera(x -- 160, y -- 100)
# Update parallax layers
variable(i, layer, para, layer sl, mapw, maph, screenw, screenh)
screenw := slice width(sprite layer)
screenh := slice height(sprite layer)
for(i, 0, 1) do(
para := slice child(parallaxen, i)
if(i == 0) then(layer sl := lookup slice(sl:map layer 0))
else if(i == 1) then(layer sl := lookup slice(sl:map layer 1))
mapw := map width * 20
maph := map height * 20
set slice x(layer sl, (camera pixel x * (mapw -- slice width(para)) / large(1, mapw -- screenw)))
set slice y(layer sl, (camera pixel y * (maph -- slice height(para)) / large(1, maph -- screenh)))
)
end
Note that if you wanted to do this just for one map, and didn't mind hard-coding the size of the parallax layers, you could eliminate the first script entirely, and make the second script noticeably simpler.
sheamkennedy wrote:
After watching some inspiring videos I decided to go for a much more minimal graphical style. It's taking me way less time to draw maptiles now and I think it's surprisingly better looking than what I was doing prior to this. Thoughts?
While I like these new graphics, I did prefer the previous ones, because I really liked the details. However, if you can draw these much faster than the previous ones and that leads to greater variety, then I suppose that for me personally the net effect will be better.
Bob the Hamster wrote:
Here is what I am working on at the moment
Cool; I know that I can look forward to this.
The high walking speed and animation is the most noticeable thing for me. At least I thought it reminded me of Super Metroid, but I see its mechanics are a bit different. Actually, the walking animation doesn't match the walking speed (which I'm sure is actually very common), and that's why it stuck out at me.
Bob the Hamster wrote:
Here is the script that I use to detect the size of a parallax layer
You can use "break(2)" to jump out of two nested loops. "continue(x)" also works. (Previously I even allowed jumping out of a variable number of loops, but since realised what a terrible idea that was). Also, I'm amused to see that your script is resolution independent.
TMC wrote:
You can use "break(2)" to jump out of two nested loops. "continue(x)" also works. (Previously I even allowed jumping out of a variable number of loops, but since realised what a terrible idea that was). Also, I'm amused to see that your script is resolution independent.
Bob the Hamster wrote:
Here is the script that I use to detect the size of a parallax layer
You can use "break(2)" to jump out of two nested loops. "continue(x)" also works. (Previously I even allowed jumping out of a variable number of loops, but since realised what a terrible idea that was). Also, I'm amused to see that your script is resolution independent.
Oh, awesome! This feature is undocumented. I remember wondering if that feature existed, but after examining the entries in the plotscripting dictionary, decided it didn't.
The walking speed is probably a little too high right now, but it is nice for getting around while I am debugging things but have not implemented save/load yet.
I'll probably lower the default walking speed a bit, but add some kind of Boots of Speed equipable item for faster movement. I might even draw separate running animation sprites
Don't hold out any hope for getting the walking animation to synch with actual movement speed. If that happens it will just be luck :)
Opps.
I think that acceleration in platformers work well when you don't notice it, because there is a separate "starting to run" "animation" (which might just be differing frame times). Which implies that accelerating to full speed takes only the length of the animation, usually a few ticks. Sonic is the only commercial platformer I can think of where your character looks like its sliding around.
I think that acceleration in platformers work well when you don't notice it, because there is a separate "starting to run" "animation" (which might just be differing frame times). Which implies that accelerating to full speed takes only the length of the animation, usually a few ticks. Sonic is the only commercial platformer I can think of where your character looks like its sliding around.
Bob the Hamster wrote:
I love making enemy ai. I think it is probably my favorite thing about this project so far.
Making those damn ladder-ramps work correctly? My least favorite thing. Thank goodness they are done, and I shouldn't have to mess with them anymore!
I love making enemy ai. I think it is probably my favorite thing about this project so far.
Making those damn ladder-ramps work correctly? My least favorite thing. Thank goodness they are done, and I shouldn't have to mess with them anymore!
Shootin' petals, reminds me of those flowers from Yoshi's Island (which I used to know the names of, but I forget. I guess I'll look next time I play Tetris Attack)
dOn'T MiNd mE! i'M jUsT CoNtAgIoUs!!!
Play Orbs CCG: http://orbsccg.com/r/4r6x
BMR wrote:
That's not a bad idea actually.
SparElric wrote:
Maybe there should be a "show off your scripts" thread. XD
That's not a bad idea actually.
Thanks! ^.^
Meowskivich wrote:
Shootin' petals, reminds me of those flowers from Yoshi's Island (which I used to know the names of, but I forget. I guess I'll look next time I play Tetris Attack)
Piranha plant?
EDIT: Oh wait! Do you mean those flowers with the yellow balls for petals that Yoshi can eat and make eggs out of?!
"One can never improve enough nor should one stop trying to improve."
SparElric wrote:
EDIT: Oh wait! Do you mean those flowers with the yellow balls for petals that Yoshi can eat and make eggs out of?! 

Correct, young child!
dOn'T MiNd mE! i'M jUsT CoNtAgIoUs!!!
Play Orbs CCG: http://orbsccg.com/r/4r6x
Bob the Hamster wrote:
Making those damn ladder-ramps work correctly? My least favorite thing. Thank goodness they are done, and I shouldn't have to mess with them anymore!
Those are some very nice ramps. It looks a bit strange that the characters shoes overlay the ramp. it would maybe look best if the feet were overlaid by the ramp thus making it appear as if the shoes are stepping on some unseen steps in behind the grade of stones. Though overlaying the ramps on the feet may be difficult since there are times when the characters full body passes in front of a ramp. Just a suggestion, perhaps theres some easy work arounds.
I feel like I'll eventually want some ramps in my game too. Fortunately mines not a platform game so it may be easier to work out.
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
⍠ C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
If your heroes stay aligned to the grid, ramps should be relatively easy. They just get harder when you want to support pixel-based movement (and it also gets harder when like me, you are bad at math)
For the feet, I was thinking I might draw a whole separate walking cycle for up and down ramps, but for now it is not a priority.
I have to accept that some things just won't look perfect. For example, even if I draw extra ramp-walking frames for the hero, there is no way I can do that for every enemy.
Enemies don't normally walk on ramps, but they can do it when they have been possessed by Player #2 in multiplayer mode.
For the feet, I was thinking I might draw a whole separate walking cycle for up and down ramps, but for now it is not a priority.
I have to accept that some things just won't look perfect. For example, even if I draw extra ramp-walking frames for the hero, there is no way I can do that for every enemy.
Enemies don't normally walk on ramps, but they can do it when they have been possessed by Player #2 in multiplayer mode.



