Posts for Kuwaga


Experienced Forum User
Joined: 10/20/2006
Posts: 1248
But those dates in the file names would hurt my eyes. :( If I'm searching for a file, I won't look at the dates. At first I'd look at the game name, that's the easiest one to remember, lol. Then I'd know it's pretty old, but not the exact date. A made up version# would keep the file name shorter. It's then easier for me to locate the rest of the relevant information within the file name.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
I really must say having the date in would just be too strange. Too many numbers just to make them get sorted correctly. I'd rather you used just v+version# (v01) and regardless of if it's in a different category, the numbers would essentially just sort them by date. Then we could still add the category as extra information. I'd prefer this a lot over including the very unintersting and more redundant information of the exact release date, which the files have, as moozooh pointed out, already built-in.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
Hoot at the purple djinn.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
bkDJ wrote:
an input file was released, and there's a video file showing all 4 plays with various audio options... (http://tas.monotoli.org/mov/Sonic_1_2_3_K-wip01.mkv). But that thread has gotten no attention since shortly after. A shame, he was doing a decent job, and I'd definitely find it more fun to watch than the megaman one.
That was me. I had already tried some routes for the next section and all I found out was that it's not very desirable to get those bubble shields. Part of the reason why I quit was that it was eating way too much time. Also, I lost my modified version of Gens as well as the source code that enabled me to run those 4 games simultaneously, due to a harddrive crash. I still think it would be cool if somebody took the effort of finishing the run. For the audio, I guess it would seem much more impressive if it was SFX only of all games played at once. This could be done by subtracting the raw BGM tracks from the games' audio tracks. Of course this means nothing if nobody wants to continue it, and I simply don't have enough spare time atm.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
Pressing left, then left+right, then letting go of left makes you walk backwards while looking forward now. This is possible to do unintentionally. There's a curious bug that occurs if you stand on the small black platform between the two fans in the middle, then slowly walk left and let yourself blow into the yellow ceiling. It freezes your frame to a certain one temporally and stays like that even after turning around. This happens because y_vel never gets <= -0.25 or > 0.75 to change the floating animation frame. It's possible to zip horizontally through those moving platforms. This shouldn't be a big surprise though. Floating into the ceiling still looks pretty ugly. Except for the glitch mentioned above, this can be seemingly fixed by replacing "self.y = something" by "self.y = round(something)" in the wall collision part of the move_y method. And I personally think setting the subpixel part of your position to zero if you hit a wall makes sense anyways. Good job on further cleaning up the code and adding new stuff! ^^
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
Boco wrote:
You mean "get_sprite" in SpriteSheet? What's a better name? "find_sprite"? "update" then "get_sprite"?
I guess it would be best to split it up into two methods.
Boco wrote:
I don't know this bug.. maybe it's only true for Vista. Try minimisingand then refocusing the pygame graphics window.
Yea, simply moving the window works too. I don't have a problem with it, but the developers of pygame might want to fix it, lol.
Kuwaga wrote:
Also, it's possible to get stuck at both of fans in your demo by doing a small air jump at the top of one of the fan areas. You should either change the code or keep this in mind when designing levels.
Or add something like this when pressing down # def begin_drop(self): # # self.gravity = self.weight * 2
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
I looked a bit into the code and python in general, but unfortunately I think I won't have much spare time this month to do anything anyway. Your wall collision code could allow for some super fast zipping if there was a bug to enter the walls far enough. ^^ Also, there is a very minor bug with dashing. You can start and keep dashing by turning around quickly. Your shadow will keep facing into the direction of your initial dash. Also, if you press left, then left+right you'll be going right. If you then let go of right you'll keep going right instead of left. Again, this is a very minor thing. There's also a bug if you switch to some other window that partly overlaps the game and then back to the game. It'll stop updating the part that hasn't been overlapped. (I'm using Windows Vista). This seems to be a general pygame bug, I guess. If it really is we should report it. Your code could be more readable, but I guess you just don't care enough atm, lol. You change an object's properties in a get-method. This isn't very pretty coding style because the name of the method is misleading. Also it's often better to use 'round' instead of 'int' when converting a float value. Drawing a sprite with an y coordinate of 8.75 at an offset of 9 pixels just makes more sense than at one of 8. A good example where this makes a lot of difference is the draw-method in your MobGroup class. If you let yourself blow into the ceiling by the fan in your demo your sprite keeps wobbling up and down. Using round instead of int fixes this. Other than that you did a great job. I'm fairly impressed. Keep up the good work. ^^ Edit: Found another bug. If you hold the jump button, let yourself blow up by a fan, leave the fan area and then let go of the button you can stop your vertical momentum. I think it would be better to leave this bug in though. Also, it's possible to get stuck at both of the fans in your demo by doing a small air jump at the top of one of the fan areas. You should either change the code or keep this in mind when designing levels.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
I think it isn't as big of a problem as it was before. People who didn't know the game well also didn't know that backwards walking was faster. They probably thought it was just used to be funny, in some geeky way. And to them it wasn't. Now, that won't happen with side hopping because it also looks faster and you see at least a bit of where Link is heading to. And I'd love to see some very unusual camera angles while super sliding. ^^
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
But if the whole world calls H.264 a codec because it's shorter, then it gets normal to call it a codec. And the meaning of the word codec may change over time as a consequence. That's how language evolves. So, whatever.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
Yea, it looks pretty amazing if you know nothing about card tricks. (that doesn't mean I dislike it though)
AKA wrote:
A trick like that could very easily be edited, if you look at the one minute mark the guy takes an age to flip over the top card.
True, but the trick works well without editing too.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
Boco wrote:
Yes, and a whole lot of other things besides before talking about "the main character is a cookie that's HILARIOUS".
I don't get the kicks if the main character is a cookie. It was an idea, and while expanding it I realised it was a bad one. Also, I'm just not so good at thinking first, and then doing. I'm more of the trial and error type.
Boco wrote:
Yes, no thanks to you. The movement engine is done except for one annoying bug I want to squish before I move to animation.
I'm well aware of the fact that I don't deserve any thanks yet, lol. I hope I can still be of help later on. Even if all I can do is motivating others by making them want to prove that I'm a fool. :X Anyways, glad to hear you're making good progress. ^^
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
Very funny. I thought Boco was making a quick Rockman clone now anyways?
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
I know how hard it is to make games. The main problem that prevents me from doing it myself is that I have no clue how to properly handle graphics/sound. And I don't want to spend ages just to find out how it doesn't work, which I've already done several times. I know how it works in Java, but it's too slow. I could never get it to work in C/C++/C# the way I would have liked it to. So, my point is, if somebody posts working source code, even if it's in Pascal, which is a language I don't know, I think I should be able to help by modifying it.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
My favourite FF is the SNES jap-only one with the crystal shards and the many chooseable job classes. Second favourite one is FFX. And those are the only ones I've completed. I hated FFX2 and FFCC and disliked FFT. The other SNES ones are OK imo. I haven't played the remaining ones at all.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
Wow, I'd totally love the idea of making glitches part of the plot too. ^^ If we keep a cookie as the main character (looks like we don't), here are some ideas for the physics: A cookie is light, so it shouldn't fall fast. A cookie is round so after passing a certain speed limit or on certain slopes it would start rolling. This would make it more difficult to stop. The cookie could walk on water if it's fast enough. Only if it's soaked up, it would drown. A soaked up cookie is heavier (falls faster, starts to roll earlier, faster when rolling downhill) and it slowly dries in the sun. A cookie is delicious so some enemies would try to eat it, which would instantly kill it. Crashing into walls or into the ground at high speed would cause a cookie to break, which would also kill it. Maybe it would only get some cracks at first which could slowly disappear again. How can it hurt enemies, difficult question. Maybe by using a chocolate chip blaster? Maybe you could charge the blaster and the more charged it is, the faster the bullets go. They'd also fall to the ground after a certain time, due to gravity. Other enemies would try to shoot the cookie too, again causing it to slowly crack. While it's rolling, the cookie might be fast enough to hurt enemies. Using the chocolate chip blaster while rolling would theoretically cause it to shoot into a semi-random direction. This would maybe feel kind of lame though. EDIT: Maybe shooting while rolling could slow the cookie down as a result of the repel. But it would waste ammo (?) in the process. On ice, the cookie could maybe move like a puck and be able to pass through small passages that way. Later upgrades could maybe include an ice shot to put ice on the floor or a water/coffee shot so the cookie can turn into its soaked up form. So far I imagine this to be very difficult to program, while it maybe wouldn't be that much fun to play the game, but who knows. Mh... I guess the whole cookie idea sucks. XD I'm sorry if my ideas aren't interesting enough or if they don't come quickly enough. But I'm trying to do my best. >_> The big difference between freeware and comercial games is that in freeware games the programmers decide what they want to do and what not. So yea.. Anyways, good luck, Boco!
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
Bisqwit wrote:
I object to anything that uses my nickname as a pun or otherwise.
Would you be OK with a cookie that's not called Bisqwit or anything similar?
upthorn wrote:
I'm just going to chime in to say I think this is a bad idea. Not the part about making a freeware game, just the part about making a game solely so you can TAS it.
I'm also not so sure about this... But the idea of limiting the use of TAS features as part of the plot could maybe turn out to be fun. Idk.
upthotn wrote:
Of course, the other part that I think is a bad idea is making a serious story for it
I think there has to be at least a bit of a story behind it, or else the game would seem too random. Nothing like an RPG though. Look at the story behind Sonic, for example. It's just enough for the game not to seem entirely random.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
I see. Too bad. We can maybe call him TASman or something instead. A cookie just would have been more original..
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
curtmack wrote:
That wouldn't work for frame advance (it doesn't matter if there's a wait time for frame-advancing if he's frame-advancing). It would definitely work for a slow-down ability though...
It would work for frame advance if we limit how long it can can be used in real time or by limiting the amount of frames you can advance through until you have to recharge. Nice character art btw, lol. He looks kind of creepy though. :p
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
Good point @ moozooh. That way not even the developer of the game knows the fastest path. ... An idea that's maybe stupid... Bisqwit (a biscuit) wants to prove he is the best video game character of them all. To achieve that, he starts a journey to defeat all of the other well known characters, they'd be the bosses. His huge advantages over all other characters include the power of slow down/frame advance and rerecording/save states. After defeating a character, he receives some (or exactly one) of their abilities. The downside would be that it would make the game very complex and it would maybe never get finished. The good thing would be that we could rip graphics of other games. Imo, the idea is cool, but it maybe goes a step too far. I still had to post it though. xD Edit: Maybe Bisqwit would need a certain time to recover after using frame advance or a save state before he can do it again. Idk yet if this would be a good idea though.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
The problem with rom hacks is that it's hard to get anything totally fresh and new into the game, isn't it? Like, the bosses would need to stay the same and so on.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
He should move by using different attacks or by running. x_x But I get what you mean. To answer your questions we would basically already need to know who the main character is and what his and his enemies' basic abilities are. Maybe we could use some lame Touhou character. ;) Or how about Bisqwit being the main character? A walking biscuit/cookie. XD Edit: If the biscuit is round, it could also be able to roll, maybe after receiving a power up.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
Hm, yea, a platformer would be cool. It think it should be non-linear with complex maps like Metroid or maybe you could select the order of the stages like in Mega Man. We could also include a move list system like in fighting games or weapon switching like in Mega Man to make a wide range of attacks possible for the main character. Maybe both. There should also be a reason not to use the same attack over and over again. Maybe by having the character use up ammo or energy or maybe the need to use a different attack to cancel the lag of the first. Maybe both. The downside of having many different attacks is of course more work, especially graphic wise.
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
Wow, that's cool. Reminds me of the Tetris I made years ago as a school project. It sucked, but it had its own level editor. >_>
Post subject: Our own game?
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
I had a fairly interesting idea today. A huge problem with speed running is that there are only few games that are optimal for it. So why don't we try creating our own games we can make speed runs for? We could, of course, embed rerecording as a feature of the game. I think the main features a game needs to have to make cool speed runs possible are: Slowly rising difficulty Huge amount of freedom Some diversity between stages A relatively speedy main character No unskipable significant slowdowns of action Decent amount of non-game threatening bugs/glitches No glitch makes all other glitches useless (like skipping to the last boss) Different power ups with advantages and disadvantages in terms of speed I know it would mean lots and lots of work. But I'm sure we can do it if enough people are interested. I, myself, am not so good at coding, but maybe I could at least help by providing some ideas. :/ Another problem would be that we'd maybe have the fastest route already in mind when designing the levels. And we'd maybe change the levels later on to make faster routes possible. I don't know if this problem is solveable at all. Maybe by forming teams?
Experienced Forum User
Joined: 10/20/2006
Posts: 1248
A run where Sonic starts from a save file with all emeralds would be what makes the most sense for a third run. It would be entirely different from both published runs. Collecting the emeralds would mean we need to watch Sonic redoing stages in the same way as in the Sonic&Tails run and collecting all emeralds like in the Knuckles run, while starting as Hyper Sonic would be something entirely new. The game doesn't label starting as Hyper Sonic as its own mode that you have to unlock, but I've always seen it that way. And it's high speed, it just has to be done. One could also see Hyper Sonic as an unlockable character. I personally wouldn't put a run like this in the concept demo section because it's actually the most common way to play the game (at least for me).