I Wanna Be The Forums!

IWBTG => Announcements! => Topic started by: Kayin on November 09, 2011, 06:54:49 pm

Title: Fix My Game: IWBTG Source Code Release
Post by: Kayin on November 09, 2011, 06:54:49 pm
I am releasing I Wanna Be the Guy's source code right now. I'm not going to make up a fancy license or anything, I'm just going to tell you what is and is not acceptable.


Some other notes. I have NO IDEA about ANYTHING in the code anymore. It is out of my mind. Don't even bother asking me what something is. I can't even open these files anymore, I no longer use MMF2.

Secondly, some stuff is just NOT going to work in new versions of MMF2. I think the elevator platforms left of spawn are broken and I'm sure plenty  of other things are too. Stuff like that is going to need to be found and fixed and I can't help you. Also keep in mind that I LEARNED MMF2 ON IWBTG. Code is going to be AWFUL and unreadable and almost never commented. If you see a better way to do things, do it.

Thirdly, for said community project, if it so happens, let me set some ground rules.

First, no new content. Maybe negotiable later. Second, selective bug fixes. Of the 'beneficial' bugs I'd like to see fixed, the only one I can think of is using 'Retry' to teleport to the Kid's starting point of a layout. Stuff like riding a Zoomer out of bounds is too cool not to keep. Also tracking down the god damned "can't shoot max number of shots" should be fixed and any left over developer keys outside of the E-N-D and bossrush ones at the title screen should be removed.

Anyways I hope people find this fun and exciting and eventually we can have someone port IWBTG to OSX or something. That'd be super nice for a lot of people. Anyways, here it is. This might not be the NEWEST version, but if it isn't, I'll try and find it later. I got some portable harddrives it might be on.

SOURCE CODE RIGHT HERE BOYS (http://kayin.pyoko.org/iwbtg/source/)

And just remember, use common sense with what you do with my game. As I have borrowed from others, you may borrow for me.
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: [redacted] on November 09, 2011, 07:10:08 pm
I am releasing I Wanna Be the Guy's source code right now.
(http://27.media.tumblr.com/tumblr_lfmf0m1vCn1qbqlqlo1_400.gif)
Probably going to make a bugfixed version of this game.
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: tijit on November 09, 2011, 07:14:31 pm
Damnit are you saying you're going to get people to make me have to fight kraidgief legitimately? I'll take fighting mother brain with a GAME OVER overlay anyday.

Also the R to retry bug to skip massive parts of the game makes IWBTG awesome fun to speedrun t_t
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Venser on November 09, 2011, 07:16:29 pm
Kayin, are you saying that if the community gets together to fix bugs, assuming such a project is successful, you will reupload a new version of IWBTG from the communal code?
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Kayin on November 09, 2011, 07:18:03 pm
Tijit: I am actually willing to negiotate keeping any bugs, so this can be discussed later. And yes Venser, if the community gets together and does a good job, it can become the final version of the game.
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Ellipsis on November 09, 2011, 08:22:03 pm
YES!
This is great!
I love open source things. I'll hopefully get MMF2 and look at this later.
Also, yay maybe more content!
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Fred-eye-inc on November 09, 2011, 08:26:36 pm
If all the bugs are sorted out, would you be willing to finish the secret item gun?
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Ellipsis on November 09, 2011, 08:48:07 pm
Has the source code always been there?
If I keep entering words after /iwbtg/ will I find other secrets?
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Kayin on November 09, 2011, 09:49:12 pm
Haha, no. I also think additional content is unlikely.... but I won't say it's out of the question.
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: CrispyYoshi on November 10, 2011, 01:05:50 am
Funny you post this as I finish the final stages of my IWBT-Construct Engine.

This should help a lot with accuracy, thank you.
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Venser on November 10, 2011, 01:18:19 am
Haha, no. I also think additional content is unlikely.... but I won't say it's out of the question.
What about IWBTG: Gaiden? How does that fit into this?
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Kayin on November 10, 2011, 01:55:22 am
I already released the construct engine that was pretty accurate! As for Gaiden? Gaiden is not on the horizon right now, though it's still something I want to get to.
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Darkylight on November 15, 2011, 07:23:01 pm
I'm looking for your engine but I dont understand... various things, why do you use global alterable values without names? xDD, and... You complicate too much with the engine. You made your own version to make the kids move and same for triggers, I dont know the extensed code to do it... xD

Anyway, cool, I think, I only want to see :P, I saw much interestant things in your engine.
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Valkema on November 15, 2011, 07:30:22 pm
I'm looking for your engine but I dont understand... various things, why do you use global alterable values without names? xDD, and... You complicate too much with the engine. You made your own version to make the kids move and same for triggers, I dont know the extensed code to do it... xD

Anyway, cool, I think, I only want to see :P, I saw much interestant things in your engine.
Um you do know this game was made as he learned how to make games right?
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: dakaarts on November 15, 2011, 07:38:58 pm
I'm looking for your engine but I dont understand... various things, why do you use global alterable values without names? xDD, and... You complicate too much with the engine. You made your own version to make the kids move and same for triggers, I dont know the extensed code to do it... xD

Anyway, cool, I think, I only want to see :P, I saw much interestant things in your engine.
Um you do know this game was made as he learned how to make games right?
really? woah, he made a masterpiece while he was learning o.o
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Darkylight on November 15, 2011, 07:41:19 pm
I'm looking for your engine but I dont understand... various things, why do you use global alterable values without names? xDD, and... You complicate too much with the engine. You made your own version to make the kids move and same for triggers, I dont know the extensed code to do it... xD

Anyway, cool, I think, I only want to see :P, I saw much interestant things in your engine.
Um you do know this game was made as he learned how to make games right?

I know, that's why I dont know how he complicated it too much in the engine o.o
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Valkema on November 15, 2011, 07:42:25 pm
I'm looking for your engine but I dont understand... various things, why do you use global alterable values without names? xDD, and... You complicate too much with the engine. You made your own version to make the kids move and same for triggers, I dont know the extensed code to do it... xD

Anyway, cool, I think, I only want to see :P, I saw much interestant things in your engine.
Um you do know this game was made as he learned how to make games right?
really? woah, he made a masterpiece while he was learning o.o
You don't have to be a great programmer to make a platforming engine, double jump, a gun, and a save feature. You don't have to be a master programmer to design a good game.
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Kayin on November 16, 2011, 06:05:21 am
The version of MMF2 I used didn't even allow the renaming of variables. So that wasn't a "I'm learning" thing, that was a "I hate this program" thing that I'm glad got rectified.

Though if you wanna see examples of me learning, look at the Apple code in the first layout as opposed to later layouts. I really sorta figured out how to simplify stuff later on.
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Sarah on November 16, 2011, 06:47:02 pm
GUYS. It's not complex because he was learning or anything.

It's because understanding the works of a god can be hard sometimes.

Seriously though, I hope to see a bug-free version and although I doubt it'll ever happen, maybe a finished game? <3
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Ellipsis on November 16, 2011, 06:56:28 pm
Ah, just another bug I'd quite like to be fixed:
timers - you've used literal time (like 1 second) and no offence but measuring delays in frames would have been nicer.
For example Mecabirdo places bullets close together in slowmo if you have lag, this is because the game runs slower but the bullets are created with delays between them as if the game was running normal speed.
Instead of using timers you can instead have a variable that you set to 0 when the game starts, then just add one to it each frame. Lets call that variable "framesFromGameStart" this lets you keep track of the number of frames passing. You can just store its value in another variable to start a timer (call this bulletTimer), then see if bulletTimer+30>framesFromGameStart. Or whatever.
If that makes any sense. Regardless hopefully it should be easy to change and it would help remove a few glitches.
If someone could do this that would be great, otherwise *maybe* I'll get a copy of MMF2 and try edit it myself (I have no idea how to use it).
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Kayin on November 17, 2011, 12:37:53 am
Yeah, I didn't do any sorta delta time stuff in IWBTG. Though I don't in Brave Earth either, but there won't be any sort of 'modes' or anything. 60 frames fixed, that is all.

But it's supposed to be a nintendo game so thats okay in that case.
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Ellipsis on November 17, 2011, 11:23:34 am
I don't know. I mean, using timers instead of frames would be fine if there was never lag.
However I guess you have to plan for it?
I remember Mechabirdo was really really easy for me on my old computer.
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Kayin on November 17, 2011, 04:33:36 pm
Well with mechabirdo, using time obviously is an issue because I didn't realize that I was building the game around a 'tick' model instead of a 'real time' model so I didn't see the problem in mixing them. For stuff like BEPRO, I'm never using time calls. I'm measuring things by ticks. So if there is lag, the game slows down and that's just the way the cookie crumbles.

I generally don't like using times like delta time because you get movement that isn't totally predictable. For example if you have a jump that's like, every frame, set y to like...

player.y - (jumpheight * (timedelta * 60))

The * 60 is nice because it makes the timedelta roughly around 1 when running the game around 60fps and makes a lot of numbers make more sense. But whatever. So lets assume on a normal frame it looks like..


player.y + (jumpheight * (timedelta * 60))
(436)    -  (    10        *           (1)       )

So we get a position for that one tick of 426

So lets craft a totally impractical situation where it takes 5 frames to get to the peak of the jump and theres no gradual acceleration or deacceleration.  If we do this 5 times, we get 286. If the game is running only a 30 FPS, what happens?


(436)    -  ((    10        *           (2 (due to the lower frame rage)       )
This makes us move 15 frames per tick and what was 5 ticks at 60fps is now...... 2.5 ticks? Yikes. So our final position in the air is either. 296 or 276, both of which are 10 frames off of what we want.

In a real world situation, with jumps that go on for awhile and bigger numbers, the variance can be as low as a pixel. That can still matter, but it can be designed around. But here comes another nasty situation. Lets say the game moves at 60 fps and then like, near the top of the jump arc, the game lags -- especially if it lacks for a moment into the 10s of FPS. You can get a significant jump boost from there. Now you can limit that too by say, capping the minimum FPS at 30 (anything under 30 produces slow down) but still, this all adds to a lot of uncertainty. When working on BEPro, the NES style made me forgo all of this. Every pixel matters when your character can precisely jump a 48 pixel gap. It seems more legitimately NESy too.

There are other tricks and work arounds too that might show up in future games. One method is controlling how much something's logic loops and mix that with time delta. For example you can have the player's platform code run like, 180 times per second. At 60 frames per second, the platform code for the player will run 3 times.  at 30, it'll 6 times and at 120 fps, it'll have to well, alternate the amount of updates each frame. But in practice it shouldn't be so hard to notice gives you totally reliable jump arcs and stuff. You can then use standard time delta for things that don't particularly matter much.
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: tijit on November 17, 2011, 11:07:55 pm
Delta time is appropriate for some games, but I agree stuff with pixel perfect precision, ie something like IWBTG or certain shmups, the programmer should just be writing code that isn't horribly inefficient so it runs at 60fps no matter what. Unfortunately with things like MMF2, that isn't always possible :~

Also lag spikes can cause some ridiculous collision bugs in frame rate independent games, as Matt found out while he was hatlands, the most common being falling through the floor.
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Kayin on November 18, 2011, 05:26:03 pm
Yeah. You can get around that if you use an incremental style of player movement (Instead of moving a player up or down 10 pixels and checking for collision, you increment him down 1 pixel at a time in a loop). But yeah thats what leads to nightmares with the frameskip version of IWBTG and platforms. I think my goal in BE:TiTS, when I get there, will be to mix time delta movement (For things like enemies or fireballs or other bullshit) with high iteration logic for movement for the player. So that way the amount the logic loops per tick can be figured out by a time delta expression and movement will still be pixel perfect, but without the huge overhead that comes with applying that to every bit of logic.

Though this potentially could lead to some weirdness so who knows if it works it. I would like BE:TiTS to be vsyncable at variable refresh rates though.
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Ellipsis on November 18, 2011, 05:57:32 pm
Yes I totally agree with you, delta time frame independent things are a total pain and mostly you should avoid them.
Slowdown in lag is much better in my opinion.
In my games I've recently  found a bit of a compromise. My game always, always runs at 60 frames per second, however in times of lag it just doesn't show some frames. Now strange as it is, actually showing a frame uses a lot more cpu time than just working it out. So working out 60 frames per second uses about 1% of the cpu, the rest is just updating the image (if I used video card acceleration I could cut this down a lot).
So in this way my game is ideally 60fps shown also but if there's some lag it just drops with say, 30fps and should still look seamless. In more lag it could drop to like 10 frames per second and then it starts to look very jerky but the jumps are still all correct and really my game never lags too much any how. I mean there's always a breaking point somewhere with any "solution". On the bright side, by doing this there's never any slowdown and jumps remain pixel perfect and predictable.
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Storyyeller on December 30, 2011, 11:20:54 am
Well with mechabirdo, using time obviously is an issue because I didn't realize that I was building the game around a 'tick' model instead of a 'real time' model so I didn't see the problem in mixing them. For stuff like BEPRO, I'm never using time calls. I'm measuring things by ticks. So if there is lag, the game slows down and that's just the way the cookie crumbles.

I generally don't like using times like delta time because you get movement that isn't totally predictable. For example if you have a jump that's like, every frame, set y to like...

player.y - (jumpheight * (timedelta * 60))

The * 60 is nice because it makes the timedelta roughly around 1 when running the game around 60fps and makes a lot of numbers make more sense. But whatever. So lets assume on a normal frame it looks like..


player.y + (jumpheight * (timedelta * 60))
(436)    -  (    10        *           (1)       )

So we get a position for that one tick of 426

So lets craft a totally impractical situation where it takes 5 frames to get to the peak of the jump and theres no gradual acceleration or deacceleration.  If we do this 5 times, we get 286. If the game is running only a 30 FPS, what happens?


(436)    -  ((    10        *           (2 (due to the lower frame rage)       )
This makes us move 15 frames per tick and what was 5 ticks at 60fps is now...... 2.5 ticks? Yikes. So our final position in the air is either. 296 or 276, both of which are 10 frames off of what we want.

In a real world situation, with jumps that go on for awhile and bigger numbers, the variance can be as low as a pixel. That can still matter, but it can be designed around. But here comes another nasty situation. Lets say the game moves at 60 fps and then like, near the top of the jump arc, the game lags -- especially if it lacks for a moment into the 10s of FPS. You can get a significant jump boost from there. Now you can limit that too by say, capping the minimum FPS at 30 (anything under 30 produces slow down) but still, this all adds to a lot of uncertainty. When working on BEPro, the NES style made me forgo all of this. Every pixel matters when your character can precisely jump a 48 pixel gap. It seems more legitimately NESy too.

There are other tricks and work arounds too that might show up in future games. One method is controlling how much something's logic loops and mix that with time delta. For example you can have the player's platform code run like, 180 times per second. At 60 frames per second, the platform code for the player will run 3 times.  at 30, it'll 6 times and at 120 fps, it'll have to well, alternate the amount of updates each frame. But in practice it shouldn't be so hard to notice gives you totally reliable jump arcs and stuff. You can then use standard time delta for things that don't particularly matter much.


This, so much. Game coders that use delta time should be sent to the moon. *cough* Team Meat *cough*


Anyway, I unfortunately don't know MMF2 and don't really feel like learning, but otherwise, I might have a try at porting it to C++/SDL sometime.
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Einstein1896 on March 16, 2012, 08:54:48 pm
There's a very good reason why one would use delta time: the game can be slowed down or sped up dynamically. (E.G, bullet time fighting!)
Also, you can completely avoid the jump height problem with calculus or kinematics: just add 1/2 * g * t^2 to the y position every update, where g is the gravity and t is the delta time.
full pseudocode:

let dy = yspd*t + .5*g*t*t;//dy is the change in y this update, yspd is the current vertical velocity (positive or negative) in units per second, g is the acceleration y-component in units per second per second, and t is the delta time in seconds.
yspd += g*t;
for (int i=0;i<dy;i++)
{
    if (no obstacle one pixel below)
        y++;
    else
        yspd=0;
}


of course, you'd also check if there was something below you /before/ you accelerated in the first place.
If it's not a pixel-based game, still use the same dy code, but instead of iterating through every pixel of vertical movement, iterate through all the obstacles, find the highest one that intercepts your path (from the starting y position to y + dy), and set your y position to be that objects y position (minus how tall you are)
theoretically, this will work perfectly and consistently with any amount of lag, though it gets more complicated with horizontal speed; rather than plotting a linear path, the path has to be a parabola.

Furthermore, the problems with this being hindering to user input under laggy conditions can be fixed by inserting fake slow-down under heavy lag.
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Storyyeller on March 16, 2012, 10:23:19 pm
I know how delta time works. It's just that it's a horrible idea that should never be used in a game under any circumstances.

The problem is that you throw consistency out the window, which also means it's impossible to balance and debug.
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Winhelp on March 17, 2012, 01:01:26 pm
I know how delta time works. It's just that it's a horrible idea that should never be used in a game under any circumstances.
Now i am totally confused (or I really don't understand what do you mean by "delta time"). What is wrong with this(Free the Physics paragraph): http://gafferongames.com/game-physics/fix-your-timestep/ (http://gafferongames.com/game-physics/fix-your-timestep/)

It is still "delta time" for me and solves almost all problems mentioned.
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Storyyeller on March 17, 2012, 01:07:58 pm
That article is talking about a fixed physics timestep. It's right there in the title.
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: Einstein1896 on March 17, 2012, 09:09:57 pm
Sorry -- I didn't mean to imply that!
I just meant, some clever coding can ensure consistency...

(I like your avatar, btw)

on the original thread topic... I feel like it might be easier and better to just rewrite the whole game from scratch in C++ or Java or something, because (no offense) Kayin's code is a nightmare.
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: gkinfinity on March 24, 2012, 09:41:17 pm
So did anyone ever try to fix the bugs in the game?  I'm actually quite experienced with mmf2 and I'd be willing to put some time into it.  The .mfa is downloading now so I haven't seen what the code looks like yet or anything.  It's actually a pretty simple game so I might just try to recode the entire thing.
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: 'Sup, Hero? on May 06, 2012, 05:07:14 pm
I get a bit confused with mmf2, especially with the engine that was posted ages ago
Title: Sir,
Post by: Uctioc100 on May 10, 2012, 08:37:05 pm
I'm pretty good withy game maker so I'LL give this a go Later:)
Title: Re: Fix My Game: IWBTG Source Code Release
Post by: sam136 on May 17, 2012, 03:06:20 pm
Well, I would like to do a convertion of the game to SDL as to compile it on windows/mac/linux. Now with the source code, i can have a pixel perfect reproduction of the game, but i only have one, stupid trouble... How can i export the images from the MFF project ? I've been looking everywhere, and it just doesn't seem to be possible ?

So the question is, can I export all of the tiles from the MMF2 project or do I have to find sprites and rip what has not yet been done ?

Also, thank you very much for releasing the source, and may the next version of IWBTG the most mazochistic experience ever :D