Doomed Dreams

by DivineTraveller
Doomed Dreams
This is what happens when a man dreams... of boxes.

Doomed Dreams

Page: 1 2
ID:100910
 
Aug 25 2010, 8:59 am (Edited on Aug 25 2010, 10:01 am)
My entry for the casual contest, Doomed Dreams, is a simple pixel platformer based off of I wanna be the guy. It is nowhere near as difficult, nor does it take quite as long, but I hope it's still enjoyable!
[note] I am being told by a few people, keypresses lag, and lasers lag for some others, but I haven't seen this myself, so I apologize if this happens to you, but I can't reproduce it.

Since I didn't have an artist for this, I did most of the artwork myself, aside from the walls, and the player (Forum_account had those in the demo). To accomplish this, I used Forum_account's Sidescroller demo.

There are a few bugs with some of my trap implementations:
  • Left and right springs do not work as expected - I manage to get a div/0 error quite a bit, by jumping as far right as I can, and landing on the spring from there. If you want to try to help me with this, the source can be found here, with a more updated version HERE (SVN).
  • To test it, you would use the test map, and just run and jump into the wall conveniently located at the right, and prepare for errors.
  • Going down a ladder (with the down key) also produces a div/0 error. I have removed this from the game and commented it out in the source, but it's still an issue.


Best of luck, and don't be too furious!

I'm also releasing the source because maybe someone would like to continue it, make some more traps, or whatever they'd need to without having to redo all the work I did. It's not the cleanest, and it's not completely commented, but I hope people can figure it out.

[edit] I forgot to mention that this wasn't my initial plan for the casual contest, but this is, in case anyone would like to pursue it.

[editedit] Maybe and hopefully if Tibby glances over this at some point, he could let me know if I'm still allowed to update the game between now and the time it's judging time? If not, 'kay, but I figure I totally jumped the gun and ended up forgetting a few things.
Aug 25 2010, 9:34 am
I really with positioning windows at 1,1 becomes common practice soon, I don't know how much more I can take.
Aug 25 2010, 9:39 am
SuperAntx wrote:
I really with positioning windows at 1,1 becomes common practice soon, I don't know how much more I can take.

Updated/changed.
I seem to forget that DM, for whatever reason, stores these locations of where the window is, and causes me to forget to manually change it.
Aug 25 2010, 9:42 am
You have made on anoying game this isn't even fun to play :(. Random wall shooters are a no no >:(.

Edit: You might want to set up a couple more of those save things after a challenging obstacle to ease the pain a little.
Aug 25 2010, 9:49 am
MdNight wrote:
You have made on anoying game this isn't even fun to play :(. Random wall shooters are a no no >:(.

I haven't heard any honest complaints about them, other than that they make it a bit more difficult. I've since made them shoot 66% slower, and I haven't heard too much about it since then.
Edit: You might want to set up a couple more of those save things after a challenging obstacle to ease the pain a little.

I tried to put two in each tower. Which challenge are you referring to with this?
Aug 25 2010, 9:52 am
Randomness does not make for good platforming. Traps should have predictable patters.
Aug 25 2010, 9:56 am
DivineTraveller wrote:

I haven't heard any honest complaints about them, other than that they make it a bit more difficult. I've since made them shoot 66% slower, and I haven't heard too much about it since then.
Edit: You might want to set up a couple more of those save things after a challenging obstacle to ease the pain a little.

I tried to put two in each tower. Which challenge are you referring to with this?

Just obstacles that needs multiple tries to get it. The least you can do is offer a save ball thing after countless of times so you don't have to re do it after dying again (which wouldn't be too far apart)
Aug 25 2010, 9:58 am
MdNight wrote:
DivineTraveller wrote:

I haven't heard any honest complaints about them, other than that they make it a bit more difficult. I've since made them shoot 66% slower, and I haven't heard too much about it since then.
Edit: You might want to set up a couple more of those save things after a challenging obstacle to ease the pain a little.

I tried to put two in each tower. Which challenge are you referring to with this?

Just obstacles that needs multiple tries to get it. The least you can do is offer a save ball thing after countless of times so you don't have to re do it after dying again (which wouldn't be too far apart)

Yeah, I see what you mean. I've had the idea to add difficulties in, which would basically determine the save point frequency, and the easiest would have save points appear more often, which would account for this. I honestly will not have time to take care of this for a few weeks yet (college next week), but when I get some time to myself again, I could sit down and add more to the game.
For now, sorry. Still trying to do a lot in a little amount of time.
Aug 25 2010, 10:45 am
NP. Also the yellow pee lazors are a little hard to see on that white background.
Aug 25 2010, 10:48 am
MdNight wrote:
NP. Also the yellow pee lazors are a little hard to see on that white background.

Alright. I think I'll make them orange then. I'm also going to do some laser optimizations (since right now, I think I can see how they clutter this up a lot). Maybe this will clean up some performance issues, at the very least.
I just ran through it again, just to make sure everything was, in fact, still doable, but I'm now noticing the little bits of lag people had mentioned.
Aug 25 2010, 12:01 pm
DivineTraveller wrote:
MdNight wrote:
NP. Also the yellow pee lazors are a little hard to see on that white background.

Alright. I think I'll make them orange then. I'm also going to do some laser optimizations (since right now, I think I can see how they clutter this up a lot). Maybe this will clean up some performance issues, at the very least.
I just ran through it again, just to make sure everything was, in fact, still doable, but I'm now noticing the little bits of lag people had mentioned.

When u are under the up and down the platform thing and you jump you kind of teleport or something maybe that is the lag they are talking about.
Aug 25 2010, 12:04 pm
MdNight wrote:
DivineTraveller wrote:
MdNight wrote:
NP. Also the yellow pee lazors are a little hard to see on that white background.

Alright. I think I'll make them orange then. I'm also going to do some laser optimizations (since right now, I think I can see how they clutter this up a lot). Maybe this will clean up some performance issues, at the very least.
I just ran through it again, just to make sure everything was, in fact, still doable, but I'm now noticing the little bits of lag people had mentioned.

When u are under the up and down the platform thing and you jump you kind of teleport or something maybe that is the lag they are talking about.

You mean if you jump into the platform from below, and end up on top of it?
Aug 25 2010, 12:26 pm
DivineTraveller wrote:
MdNight wrote:
DivineTraveller wrote:
MdNight wrote:
NP. Also the yellow pee lazors are a little hard to see on that white background.

Alright. I think I'll make them orange then. I'm also going to do some laser optimizations (since right now, I think I can see how they clutter this up a lot). Maybe this will clean up some performance issues, at the very least.
I just ran through it again, just to make sure everything was, in fact, still doable, but I'm now noticing the little bits of lag people had mentioned.

When u are under the up and down the platform thing and you jump you kind of teleport or something maybe that is the lag they are talking about.

You mean if you jump into the platform from below, and end up on top of it?

Yes. But is not a smooth transition just just move there
Aug 25 2010, 12:28 pm
MdNight wrote:
DivineTraveller wrote:
MdNight wrote:
DivineTraveller wrote:
MdNight wrote:
NP. Also the yellow pee lazors are a little hard to see on that white background.

Alright. I think I'll make them orange then. I'm also going to do some laser optimizations (since right now, I think I can see how they clutter this up a lot). Maybe this will clean up some performance issues, at the very least.
I just ran through it again, just to make sure everything was, in fact, still doable, but I'm now noticing the little bits of lag people had mentioned.

When u are under the up and down the platform thing and you jump you kind of teleport or something maybe that is the lag they are talking about.

You mean if you jump into the platform from below, and end up on top of it?

Yes. But is not a smooth transition just just move there

No, this isn't lag, this is what happens when you get stuck in an object that suddenly appears or becomes dense. There is a puzzle in tower four that has disappearing blocks, and if you are inside one when it becomes dense again, you end up on top of it. It's just how it happens.
Aug 25 2010, 12:30 pm
Movement is choppy when you run to the left, you need to change the check in the movement loop to something like this:

if(!istype(loc,/turf/ladder))
    vel_y -= 1

// becomes
if(!istype(loc,/turf/ladder) && (!on_ground() || onPlatform))
    vel_y -= 1


The way collisions are checked, if you're moving to the left along a smooth surface you'll continually bump the ground in the x and y directions (because x gets checked first) so this causes your x velocity to reset. You can get around this by eliminating downward acceleration in these cases.

Also, I didn't look through the code for this, but projectiles didn't look as smooth as I'd expect them to be given the lower value of world.tick_lag.
Aug 25 2010, 12:32 pm
Forum_account wrote:
Movement is choppy when you run to the left, you need to change the check in the movement loop to something like this:

> if(!istype(loc,/turf/ladder))
>     vel_y -= 1
> 
> // becomes
> if(!istype(loc,/turf/ladder) && (!on_ground() || onPlatform))
>     vel_y -= 1
>

The way collisions are checked, if you're moving to the left along a smooth surface you'll continually bump the ground in the x and y directions (because x gets checked first) so this causes your x velocity to reset. You can get around this by eliminating downward acceleration in these cases.

Also, I didn't look through the code for this, but projectiles didn't look as smooth as I'd expect them to be given the lower value of world.tick_lag.

I'll make the changes - thanks a bunch!

In regards to the pixel projectiles, I was also told they hog a ridiculous amount of CPU by someone else who did some testing. Personally, I didn't see it as that bad, but they aren't as great as they could be. Then again, the library itself might be at fault, because of it's age (and lack of being upkept). I'm not too sure.
Aug 25 2010, 12:35 pm
DivineTraveller wrote:
In regards to the pixel projectiles, I was also told they hog a ridiculous amount of CPU by someone else who did some testing. ... Then again, the library itself might be at fault, because of it's age (and lack of being upkept). I'm not too sure.

There's no reason that pixel projectiles should cause any more lag than a player's pixel movement. If it can handle one it can certainly handle the other, though I can't speak for the library.
Aug 25 2010, 6:08 pm
Forum_account wrote:
DivineTraveller wrote:
In regards to the pixel projectiles, I was also told they hog a ridiculous amount of CPU by someone else who did some testing. ... Then again, the library itself might be at fault, because of it's age (and lack of being upkept). I'm not too sure.

There's no reason that pixel projectiles should cause any more lag than a player's pixel movement. If it can handle one it can certainly handle the other, though I can't speak for the library.

Yeah, I figured as much, but the library procs seem to report a really high cpu all around. Maybe the low tick_lag is throwing it off, or something - I've never done any daemon profiling when tick_lag wasn't 1, so I don't know.
Aug 25 2010, 6:28 pm
Edit: I forgot to mention this, but it was the purpose of writing this comment. You can get away with larger delays for projectiles but you should use the smallest delay possible for moving platforms. When you're standing on the fast-moving platform below the ones that go in a circle things look horrible.

For a single player game, pixel projectiles shouldn't cause much lag. Over a network they can cause significant lag because you have to notify each client of every projectile's new pixel x/y position every tick. For single player that's not a factor, the lag will only come from the CPU time to compute each projectile's position and the time to draw them all.

For projectiles this can cause problems because collisions are only checked at each discrete step that the projectile makes. Bullets can go through the corners of objects by skipping right through them. To combat this you need to decrease the size of each step the projectile makes.

To keep network lag down (if it is a factor) you can keep the higher movement delay but break a move into multiple parts. Instead of calling pixel_move(8,0), call pixel_move(4,0) twice on the same tick.

By the way:
You died 74 times.
You saved 48 times.
Aug 25 2010, 10:34 pm
Update to your hearts content.
Page: 1 2