Crashes on exit, but otherwise performance is just fine now.
Gameplay quibbles:
Character jumps way higher than he needs to and it makes it difficult to bounce on enemies
The variety of inclines means you're never sure if you're going to move horizontally too fast and walk into space rather than down the slope
Glitches
The moving platform sometimes just vanishes and drops you into the spikes
I'm on Windows 7 (beta 7077) 64-bit and had no performance issues without applying the patch or anything.
The first level is surprisingly hard to navigate. Maybe I'm bad at platforming, but that last bit was really a bitch to get through.
Also jumping on enemies across the spikes in the 2nd level? Doesn't work too well for me. It seems to work on the first one but then after that it just does regular jumps and then I die from landing in the spikes too much.
Crashes on exit, but otherwise performance is just fine now.
Gameplay quibbles:
Character jumps way higher than he needs to and it makes it difficult to bounce on enemies
The variety of inclines means you're never sure if you're going to move horizontally too fast and walk into space rather than down the slope
Glitches
The moving platform sometimes just vanishes and drops you into the spikes
Only crashes when you use the GUI menu and not the in-game menu. Working on it.
Bounce height is determined by how long you hold jump. The guy is supposed to be able to jump really high but there are about 20 variables that I can tweak to make it slower, more controllable, or, shorter, I guess, but I'll have to redesign the levels.
There is already code in place that keeps you glued to the ground. Any ground angle 45 degrees or less is probably safe. Anything more plus running and you might become unglued. This is really a level design thing. Is there a particular place where you noticed it?
The moving platform should never just "vanish". If any hazard hits it, be it spikes or even your own attacks, it'll break and wood chips will fly everywhere, indicating that you broke it. If the woodchip effect is missing, then it might be a little confusing. Is the main character also missing arms and legs? When you stomp on the little walker guys, do they explode with a fiery blast?
I know bounce height is controlled by how long you hold the button, but with a max jump height so high, attempting to bounce on an enemy means either:
A) Holding down the button and "aiming the fall"
or Releasing jump for a shorter initial jump and pressing it again to bounce
I still have no particles for the breaking platform or arms/legs - I never stuck around the walkers long enough to see their explosions.
The angle problem is right before the cup-shaped platforms. Regardless of whether or not the character is "glued to the ground", his normal h-speed makes it seem like he should go flying off, which I guess is why it's confusing.
Delzhand on
0
AntimatterDevo Was RightGates of SteelRegistered Userregular
edited June 2009
This thing won't even launch for me. I click run game, a black window opens up with "blah blah platformer.exe", two more windows open and close within a few milliseconds, too fast to read the title of the window, and the whole thing closes. I replaced the lib file even. I'm running a vista system.
e: OK, the mysterious closing window title says "Py Game Window".
I need to find a Vista 64 machine to test on and troubleshoot, because it seems like everyone is having the same bizarre set of issues.
Antimatter, you probably don't have OpenGL installed. Check your graphics drivers. I also need to work on getting better error handling so that the game can tell you these things.
Technical
Crash on quit: Fixed. Dropdown menus and Xs work just as well as the in game menu.
OpenGL failures (No driver, old driver, missing hardware features): Identified and will now be reported to the user rather than having the game quit with no message or some cryptic console text. Some errors that were fatal are no longer fatal but result in decreased visual effects.
The angle problem is right before the cup-shaped platforms. Regardless of whether or not the character is "glued to the ground", his normal h-speed makes it seem like he should go flying off, which I guess is why it's confusing.
I made a change to the physics that fixes this issue. Now when you're running up or down a slanted surface, the running velocity limit is calculated against the magnitude of the whole movement vector, not just the horizontal component.
In English: The steeper the hill, up or down, the slower you go. It makes things look more realistic and you don't feel like you're on the verge of falling off the earth when you run downhill.
While my main computer has been away for repairs, I've been working on optimization and resolution independence. The game is about 50% faster in certain cases where it was CPU bound. I managed that by fixing a few bugs in the particle engine and caching systems. It can also handle any resolution "properly" now, rather than just stretching the viewport like it did before. The only problem is from a camera control and level design perspective. Should I allow the change in resolution to zoom out the gameplay or should the zoom always be the same? In some areas, I use camera hints to keep the action on screen, but once you zoom out, those hints sometimes no longer make sense and make things worse. I'll just need to figure that out.
Evil Twin (HD)
For full effect, visit youtube to watch, as the forums do not allow HD embedding.
Do people connect multiple USB joypads to their computers and leave them there all the time? I really like my simple USB HID implementation and I don't want to change it.
The game starts up and looks at all attached HID devices. After investigating all devices, it determines which are game pads based on device class and exposed functionality (it's good at skipping over mice, keyboards, and little knobby peripherals people use for various things). It then takes the device most likely to be a game controller and uses it in-game. If there is more than one likely device, it picks the one with the most buttons. Maybe I'll design some presets for more common devices (like 360 controllers).
Is this unreasonable behavior? I like the "just works" aspect of not needing to configure which device you want and I don't think it'll be worth it to code up something more complex. Does anyone use their computer in a way that would make this implementation a pain?
Typically if I'm going to play a game with my gamepad, I plug it in before I start the application because I just assume games and things won't be able to look for it other than at startup. I've never used multiple gamepads. Local multi isn't real big on PC games.
I've been working on polishing things up and getting the game running faster on on a wider variety of systems. Changes soo far:
Implemented OpenGL feature detection. Game now runs on ANY system with at least OpenGL 1.1
Fixed many missing particle bugs.
Improved performance in particle engine
Added in-game config menu for visual and control settings
For alpha 5, here are some notes of tasks to be done:
Before Alpha 5:
Fix broken Factory Boss AI behavior
Change checkpoints 2 and 3 in Factory2 to make more sense
Improve crush pillar performance by removing giant inefficiencies
Fix Factory 3 Background
Factory 1 cage disappears on respawn
Track down and fix missing particle bug
Move debug codes to pause menu
Finish caves level for hijack hand object
Implement game saving and progress
Player state consistent from launch to launch
Improved particle performance and effects (this is a demo of rain and the invincibility powerup):
It's been three months and I haven't done much, but I just wanted to drop in and give a short "the project isn't dead yet".
The project isn't dead yet. I've been working on it in very, very small bits but they've added up to some considerable polish for the engine and game mechanics. This video is a reprise of the "Factory Run Through" video, only with all the newest little changes applied.
Changes:
3D backgrounds
Rain and lightning
Ambient sounds
Better animation
Powerups
More enemies
More complete levels
Improved boss movement and behavior
Dynamic, smoothed camera
Smoother video capture
Yes, very very outdated. I kept in sync with an SVN repository with google for a while but it became a hassle. Since no one had looked at the code in months, I stopped maintaining it. At some point when I package up the next alpha, I'll be sure to wrap up the source too.
That's cool. I saw a "Let's make a game" thread with Win/Mac support and thought "WHERE IS MY BELOVED LINUX?" I figured if you were putting out source code I could see if I could add some code to make it support Linux too.
I sure hope this game isn't dead! Looking at the videos, I'm surprised it can run that smoothly using pygame. I'd like to try it out, but when I run run_game.bat, a command prompt opens up and prints a few things about openGL, then closes. I'm using x64 vista, if that helps.
I have python 2.6, pygame 1.9.1, and pyopengl 3.0.1.
Hah, saw you used an old tune of mine on a YouTube video, Zack. You still kickin' this thing around? I've gotten better!
Kaseius on
www.youtube.com/user/kaseius -- Let's Plays
0
facetiousa wit so dryit shits sandRegistered Userregular
edited July 2010
I just watched the first vid in the OP and I'm really impressed! There are some really clever and imaginative ideas in the gameplay mechanics and level design. I particularly like the hand powerup - that's brilliant.
The graphics and sound are great too - simple but charming, with their own unique style that just fit with what you're trying to project. I'm eager to follow this project and see where it goes.
facetious on
"I am not young enough to know everything." - Oscar Wilde
Hey, thanks guys. I came across the project the other day while cleaning up some files and thought I'd check this thread. I don't think I'll ask for any more music unless I restart development in earnest. I had honestly forgotten how much work I put into this thing! It's pretty well polished.
I remember I stopped development because I got frustrated with the python packaging tools and the in-game physics (I tried for a while to rewrite things for Chipmunk physics) but after taking a long break from the project, I think I was too hard on myself and what I'd done. The engine is basically completed for a standard puzzle platformer with basic physics if I wanted. There's plenty that could be made out of what I've done.
I'm back in school for a while and my schedule is pretty busy, but maybe as a little relaxing side project I'll pick things up and just design graphics and new levels for fun. And if I get something together that's worth releasing, maybe I'll ask for more music and polish things up (save system, better gamepad support).
I figured out an easier way to bundle things up last night, so I took the latest code and just threw it together into distributable form for you guys. I'm not sure how different this is from Alpha 4 way back when but it doesn't crash and it seems to have 5 more or less complete stages.
Posts
Gameplay quibbles:
Character jumps way higher than he needs to and it makes it difficult to bounce on enemies
The variety of inclines means you're never sure if you're going to move horizontally too fast and walk into space rather than down the slope
Glitches
The moving platform sometimes just vanishes and drops you into the spikes
The first level is surprisingly hard to navigate. Maybe I'm bad at platforming, but that last bit was really a bitch to get through.
Also jumping on enemies across the spikes in the 2nd level? Doesn't work too well for me. It seems to work on the first one but then after that it just does regular jumps and then I die from landing in the spikes too much.
Otherwise it's pretty cool.
SC2 NA: exoplasm.519 | PA SC2 Mumble Server | My Website | My Stream
Only crashes when you use the GUI menu and not the in-game menu. Working on it.
Bounce height is determined by how long you hold jump. The guy is supposed to be able to jump really high but there are about 20 variables that I can tweak to make it slower, more controllable, or, shorter, I guess, but I'll have to redesign the levels.
There is already code in place that keeps you glued to the ground. Any ground angle 45 degrees or less is probably safe. Anything more plus running and you might become unglued. This is really a level design thing. Is there a particular place where you noticed it?
The moving platform should never just "vanish". If any hazard hits it, be it spikes or even your own attacks, it'll break and wood chips will fly everywhere, indicating that you broke it. If the woodchip effect is missing, then it might be a little confusing. Is the main character also missing arms and legs? When you stomp on the little walker guys, do they explode with a fiery blast?
A) Holding down the button and "aiming the fall"
or
Releasing jump for a shorter initial jump and pressing it again to bounce
I still have no particles for the breaking platform or arms/legs - I never stuck around the walkers long enough to see their explosions.
The angle problem is right before the cup-shaped platforms. Regardless of whether or not the character is "glued to the ground", his normal h-speed makes it seem like he should go flying off, which I guess is why it's confusing.
e: OK, the mysterious closing window title says "Py Game Window".
Antimatter, you probably don't have OpenGL installed. Check your graphics drivers. I also need to work on getting better error handling so that the game can tell you these things.
This thread has been very helpful. Thanks guys.
Technical
Crash on quit: Fixed. Dropdown menus and Xs work just as well as the in game menu.
OpenGL failures (No driver, old driver, missing hardware features): Identified and will now be reported to the user rather than having the game quit with no message or some cryptic console text. Some errors that were fatal are no longer fatal but result in decreased visual effects.
Gameplay:
I made a change to the physics that fixes this issue. Now when you're running up or down a slanted surface, the running velocity limit is calculated against the magnitude of the whole movement vector, not just the horizontal component.
In English: The steeper the hill, up or down, the slower you go. It makes things look more realistic and you don't feel like you're on the verge of falling off the earth when you run downhill.
Evil Twin (HD)
For full effect, visit youtube to watch, as the forums do not allow HD embedding.
http://www.youtube.com/watch?v=4LH2bcYuiwc&fmt=22
There's just something so illicitly satisfying about possessing an enemy and marching it to its doom.
The game starts up and looks at all attached HID devices. After investigating all devices, it determines which are game pads based on device class and exposed functionality (it's good at skipping over mice, keyboards, and little knobby peripherals people use for various things). It then takes the device most likely to be a game controller and uses it in-game. If there is more than one likely device, it picks the one with the most buttons. Maybe I'll design some presets for more common devices (like 360 controllers).
Is this unreasonable behavior? I like the "just works" aspect of not needing to configure which device you want and I don't think it'll be worth it to code up something more complex. Does anyone use their computer in a way that would make this implementation a pain?
Implemented OpenGL feature detection. Game now runs on ANY system with at least OpenGL 1.1
Fixed many missing particle bugs.
Improved performance in particle engine
Added in-game config menu for visual and control settings
For alpha 5, here are some notes of tasks to be done:
Improved particle performance and effects (this is a demo of rain and the invincibility powerup):
Config menus:
The project isn't dead yet. I've been working on it in very, very small bits but they've added up to some considerable polish for the engine and game mechanics. This video is a reprise of the "Factory Run Through" video, only with all the newest little changes applied.
Changes:
3D backgrounds
Rain and lightning
Ambient sounds
Better animation
Powerups
More enemies
More complete levels
Improved boss movement and behavior
Dynamic, smoothed camera
Smoother video capture
http://www.youtube.com/watch?v=twI6I0FUHkw
It's also played by someone other than myself for a change.
I have python 2.6, pygame 1.9.1, and pyopengl 3.0.1.
The graphics and sound are great too - simple but charming, with their own unique style that just fit with what you're trying to project. I'm eager to follow this project and see where it goes.
Steam: Chagrin LoL: Bonhomie
Same! Totally give a shout if you need more music.
I remember I stopped development because I got frustrated with the python packaging tools and the in-game physics (I tried for a while to rewrite things for Chipmunk physics) but after taking a long break from the project, I think I was too hard on myself and what I'd done. The engine is basically completed for a standard puzzle platformer with basic physics if I wanted. There's plenty that could be made out of what I've done.
I'm back in school for a while and my schedule is pretty busy, but maybe as a little relaxing side project I'll pick things up and just design graphics and new levels for fun. And if I get something together that's worth releasing, maybe I'll ask for more music and polish things up (save system, better gamepad support).
I figured out an easier way to bundle things up last night, so I took the latest code and just threw it together into distributable form for you guys. I'm not sure how different this is from Alpha 4 way back when but it doesn't crash and it seems to have 5 more or less complete stages.
So here's the latest stuff I have:
http://dl.dropbox.com/u/107712/Platformer%20a5%20Mac.zip
http://dl.dropbox.com/u/107712/Platformer%20a5%20Win.zip