The demo:http://www.youtube.com/watch?v=twI6I0FUHkw
Old demos:
Old Files (Will be updated soon):
The back story:
I've always wanted to create a platformer. I've been brewing ideas for the past year or so of how I want my very own game to play, what its gimmick would be, and various other details. It would control like a mix between Mario and Sonic. Gameplay would be a mixture of platforming and beat-em-up combat. The twist would be a built-in rhythm gameplay engine driving combos, attack strength, and jump height.
Last week, I stopped thinking and started doing. I got Pygame installed on my laptop and just started developing. First I wrote up a parallax background scroller, then movement/collision detection. Eventually, I got used to the development environment and wrote up some basic physics, control code, USB pad support.
Alpha 1: I now have the basics of a platformer. There's a little man and there's a level. He can move and jump.
Alpha 2: He doesn't get stuck in the walls anymore.
Alpha 3: He can also do other things, like punch, kick, stomp the ground, hit things with his head, and throw spiked balls. There are enemies that hop around and hunt the player.
Alpha 4: There are spikes and exploding balloons and a trigger system that allows for scripted events in levels. There is a camera that moves, zooms and tilts. The levels are rendered in full 3D
There's also a rhythm engine hidden somewhere in the back end, just to make sure it all keeps running as a develop things. Who knows if this will ever work out to be the game I imagined. It probably won't at all. I'm ok with that.
What this thread is:
I'd like to gauge interest in the game, get feedback on how it feels at this early stage, and, ideally, recruit some people for this project, no development experience necessary. I'm looking for a few people who would like to design some levels, create some sprites, etc. If someone wants to help with programming, just let me know. I think I'm all set but, who am I kidding, I'd love for someone to swoop in and whip up the perfect collision detection system.
This is strictly just for fun. If the game ever gets to the point where it would be a compelling experience for others to play, you get your due credit and it goes up in a released form for free. If not, that's just how it goes.
There are always threads that are like: "Hey guys, let's make a game!" and then they never go anywhere. This has already gone somewhere. There is a running engine packaged into executables, ready for new level designs, sprites, and (you'll have to work with me on this one) animations. Sure, it's early and in-progress. You have to start somewhere. Get in on the ground floor.
How to start:
First, download the game and try it. There are no enemies or goals or interface to speak of. It just is. Take it in. If it's running like crap or you'd like to change the demo level or controls, open up the data folder and poke around with "conf.txt" and "controls.txt" Windows users, you may need to use Wordpad to edit the files because notepad could choke on their linebreak format.
Next, if you're interested in levels or sprites, you'll need a graphics editing program that can handle transparent PNGs and, for your sanity, layers. I use Photoshop but the gimp will do in a pinch. Anything that can make a legitimate transparent PNG will do.
Open the data folder, open up levels, and pick one of the three examples (vida, testbig, palevel). There are 6 files that make up each level. "back.png", "front.png" and "rear.png" are just graphics with no bearing on gameplay. Front is the layer of the level over your character. Back is the layer immediately behind. Front and back should have the same pixel dimensions. Rear is the panel that sits in the back and gives the illusion of depth. It should be smaller than front and back but larger than the screen size.
"ground.png" is the ground surface, the places the player can walk. "mask.png" represents the walls the player will bounce off of. Play the game and inspect the examples and you'll get a much better idea.
This picture shows ground and walls overlayed in Photoshop.
"props.txt" determines what song plays and at what coordinates the player starts. Eventually, this will flesh out to do more.
The details:
The Controls
Left/Right arrows: Movement
Up arrow: Jump
Left Ctrl: Run
Tab: Spawn a basic character entity called "Jumper"
Space: Rhythm code interface
Esc: Quit
More pictures:
Posts
Running Ubuntu 8.04, Python 2.5.2, PyGame 1.7.1
Edit: suggestion - the file size would go down and levels would be easier to edit if you either pulled a Sonic the Hedgehog and used a lot of sloped/curved tiles, or if you saved the levels in SVG format or something.
I guess I should go back to working on my own game so it doesn't become one of those projects that never go anywhere.
However, this looks good and colour me interested.
Steam: abunchofdaftpunk | PSN: noautomobilesgo | Lastfm: sjchszeppelin | Backloggery: colincummings | 3DS FC: 1392-6019-0219 |
I'm still thinking about the level format. As impractical as giant PNGs are, it's the simplest way to do what I want. Also, Sonic had a continuous listing of the slope at each pixel.
You need to upgrade to pygame 1.8.x. 1.7 doesn't support collision masks, a major feature I use.
Edit: Make that a major feature I don't use anymore because they totally suck.
Eventually, I did a performance profile of the game's code and found out that what's causing the most trouble is by far the physics calculations. Specifically the mask-based collision detection. I was surprised at how little the software rendering of the graphics (all that blitting!) was by comparison.
Since collision needs a rewrite anyway, I installed the NumPy mathematics library for Python and I'm in the process of transforming the level masks into NumPy arrays for lightning-fast collision checks and surface normal calculations. Luckily, this means absolutely nothing changes in terms of data files getting read in. In the end, the code will look neater and run faster, locking the frame rate at 60. So that's what I'm working on.
The game would slow down a lot when there were four or more balls on the screen.
Your first post contains "Space: Rhythm code interface", but I don't notice anything happening when pressing space and it doesn't seem to be mentioned in the controls file.
1.) The way the character bumps off of things is made a lot more severe because of a hack I placed on top of collision detection to stop the player from getting stuck in walls. This does make it hard to navigate small areas. The Testbig level was designed entirely to present odd cases to the collision detection code to make sure we never got stuck in an infinite loop, to make sure that bizarre level shapes do not clip you through walls, etc. The level is not meant to be fun, it's meant to push the limits of the code so I can quickly test to see if the physics are working pixel perfect like they are supposed to.
I made a design decision that the player would bounce off walls the way he does, so that's not going away unless someone convinces me that killing all momentum is more fun. If after all the collision code is fixed, it's still really hard to navigate tight spaces, the solution is just to avoid tight spaces in level creation.
2.) I know. You add 4 balls and the frame rate drops to 45. Any more and it takes a nosedive. That's why I added the feature to spawn the balls. I needed to test the physics and collision code on more than just the player to see when I'd encounter slowdown. I was hoping it would be more than 4 balls on most machines, but that just means I'll have to aggressively optimize the physics (which I am doing, see my post above yours) and even then, the game may have to limit the number of enemies onscreen to about 5 or 6. Non-physical sprites (effects, environment animations) will not count toward this total.
3.) I didn't detail what this does exactly. It's not in the control file because it's not part of the standard control object that unifies keyboard/joystick and passes stuff to the player.
If you want to know, open the conf file and make sure training is switched to 1. Run the game and forget moving around. Instead, tap the spacebar to a beat. You don't have to tap for the whole song. Press esc when you're done. The game will capture this tapping to the beat as a rhythm track. Now, set in the conf file, training=0. Run the game again. This time try to tap the space bar to the same beat. The game will grade you on how well you are hitting each beat in the upper right.
This is the beginning of the rhythm code. Once I'm satisfied with the way the platforming elements work, I'll move back to this and start fleshing it out. (Give it a better interface, visual feedback of when beats are coming, tie rhythm to physical variable in the game, etc)
Hope this gets done though!
http://www.microsoft.com/express/samples/gamecreators/default.aspx
I am thinking of just playing around with it (making a tower defense game, heh) just on my free time, and since it works with Visual C++ Express it won't cost a dime. Unless you guys think using the OP's software would be easier.
I just got the code to a spot where it compiles. I haven't optimized it yet. It doesn't even totally work right. But...
I opened the game, walked out into the level. 60FPS. I spawn a jumper guy. 60FPS. I spawn 10 jumper guys. 60 FPS. I mash the tab key as many times as I can, spawning about 100 jumper guys.
SIXTY FRAMES PER SECOND. HOLY SHIT. I expected a speedup but nothing this dramatic. The game engine can now support hundreds and hundreds of enemies onscreen at once. More than even makes sense from a design perspective.
I've arrived. I'll get this version up once I finish the physics rewrite, hopefully very soon. Numpy is the goddamn greatest thing ever.
Edit: This screenshot, busy as all hell, was taken running at 60FPS on my laptop. I haven't even started optimizing.
(Its a start....right? )
On the game front, the rewrite was a success. The new collision system is 99% complete. I'm now tracking down the last little bug that caused sticky walls (if you were falling, you could hold the direction of the wall and actually come to a full stop because the friction and elasticity of the collisions would bleed away all your force). There would also be certain walls where the normal calculation would go a little wonky and your bounce would send you back into the wall, getting you completely stuck. I'm currently fixing that.
I'm not sure how well that would jive with the most basic elements I had planned (platforming, rhythm/combat).
New features:
-New physics engine based on Numpy array manipulation offers greatly improved performance and no more jerky or shaking wall collisions. Eliminates many bad clipping cases that could trap or incorrectly warp the player.
-Tiled graphics: You can specify a PNG, a game layer, and a position in the level properties file and the game will stencil the PNG on to the layer before starting the level. This should help keep file sizes down and allow for some image recycling, especially for simpler levels.
-Animated tiles: You can also specify a layer, position, and an animation name and have the game load up a series of PNGs and animate them. This allows for moving waterfalls, windblown trees, swaying grass, moving clouds in the background. It's all done with PNGs and text files to specify animation order and rate. No coding required. No apparent performance hit either.
This waterfall looks pretty nice in motion. Screenshot taken with game running at a silky 60fps:
The level config file, showing how I spawned a few repeating animate waterfall tiles to create that effect.
I need to write a better cross-platform build script too. You know, once I figure out how to get it building again. (The Numpy - pygame interface runs fine on the command line but segfaults if you try to build a package.)
Since a few people mentioned wanting to contribute to Zack's game, I may have a tool that will help you test ideas before you spend the time coding them to perfection. I'm creating a game development toolkit called Venatio Creo, which is a WYSIWYG toolkit that requires no programming to make fairly complex games. One thing it seems particularly useful for is creating platformers (quickly too, I'm talking in minutes). You should be able to jump right into the program with few problems, but I recommend playing a few of the games that are included with it to see how everything flows.
It might be a great sandbox for you guys to use to test ideas you have for Zack's game, so give it a shot if you are just itching to develop. Any graphics or sound that you make to try ideas in VC will port just fine to Zach's engine, so you don't need to worry about wasting time and remaking assets. You can get a release candidate from Venatio Creo's Website. Let me know how it goes if you decide to try out the program. It's currently Win32/64 (XP/VISTA) only right now.
Thanks for letting me mention this Zack.
I'm curious about your rhythm based combat system. Do enemies have their own unique rhythm? How many buttons are involved in making the rhythms?
Nothing is coded aside from a basic 1-track rhythm system and a little code to compare when you hit the space bar to when the beats in the rhythm track are. Just a little proof-of-concept I can expand on later.
In terms of what I'm planning, I've got 4 assignable attack (kick and punch, high and low) buttons and a charge button. What I hope to do is tie the power behind punches, kicks and jumps to how on-beat the player is. As you play, each successful move boosts the charge meter. (This could include tapping the charge button right as an enemy attacks to block and absorb). Once some power is in the charge meter, you hold down the charge button and hit an attack or jump to the beat and it gives you double the strength. Hit the beat poorly or miss with the charge active, it hurts you or knocks you around. I'm not sure just yet.
Ideally, I'd have 4 or 5 tracks for the player, each would work for any move, but only one, say bass, would give the most power to low kicks and punches. This would all be represented on a scrolling track along the HUD. At no point would it be required to use a charged jump to complete a level, but maybe for shortcuts or secret areas. Uncharged and offbeat moves still do damage, just not as much. Maybe they'll go off with a quarter of the power. The multi-track rhythms and HUD are next on my to do list.
As for enemies, I don't know yet. It would be neat to tie their movement and attacks to the player's rhythm track too, but I haven't started any AI. It's definitely possible and something I'm thinking about. Maybe give them their own track with just a steady beat at first and work up to reading directly off the player's track as the game progresses.
WYSIWYG should be implemented in pretty much every program. Loved the program, I'll download it one of these days and try it (I like to play around with GM).
Also, will different types of platforms react to certain parts of the song? I mean, if you're going to code all those separate tracks, might as well get the most out of it.
As of right now, there are no "different kinds of platforms." I'm thinking of adding some basic support for moving platforms but I don't know how well my physics engine will behave. I'm sad to admit that it was not coded with relative velocities in mind. Y-axis motion will be ok because the routines that cause the player to hug the ground will stay in effect. X-axis motion will very likely leave the player behind without some kind of ugly hack or system overhaul.
Lastly, Lenard Lindstrom on the pygame mailing list has identified my obscure problem with building standalone apps. Thank you sir, you are a gentleman and a scholar. I am, as we speak, setting up a google code page. I'll post it and links to the new binaries once they are built and up.
Anyway, yours is coming along nicely. I like the character.
Well make sure you give Venatio Creo a shot if you are still open to engine ideas. All the details are a few posts above yours. At the very least it can get you started on a simple platformer really quickly. You can also wait until Zack has some of his source code available and try modifying little stuff here and there.
Windows standalone exe
Mac OS X standalone app
Platform Independent Source (requires Python, Pygame, and NumPy)
Data Files (Unzip and place in the same folder as the executable (or on OS X, in the same folder as the .app bundle, NOT inside the bundle)
Brief FAQ:
Q: Why are these files so huge?
A: The standalone executables include an entire Python distribution, Pygame, Numpy, SDL, and various other libraries to ensure they run on any system. The data folder is mostly uncompressed PNGs and music. With tiling, I should be able to shrink it a little going forward. For now, it's ok, my host gives unlimited bandwidth.
Q: What are the controls?
A: See the OP
Q: Are you supposed to be able to cling to the walls?
A: Yes. It'll make more sense once the air control animations are in place.
Q: It crashes right away. What can I do?
A: Make sure you have the data folder along side the executable or app.
Q: Didn't you say you'd set up a Google Code page?
A: Coming soon.
Great stuff, Zack. I was going to ask if you had done any tiling stuff, but I guess you haven't yet. I want to make a top-down kinda game and tiling seemed pretty essential.
I can't remember why I stopped trying to make my game in python, but I guess I can start from scratch again. I can't seem to get very far.
I love these kinda threads, they always make me want to try again.
http://www.youtube.com/watch?v=ypS1AG_Tbx0
The Power indicator is looking pretty sweet though. It animates too, draining and filling over time if you add or remove a large chunk of power.
In New Super Mario Brothers, the bad guys would dance along to the music. Maybe something like that, swaying trees, mountains, or something to show the rhythm.
Or, the main character that your staring at all the time could snap his fingers or something, and you have to hit space bar or whatever to beat he's snapping.
You're right, in an action platformer, people will always be looking at the MC or the environment. Some kind of neat animation could make it clear to the user, and make the whole game visually interesting.
bobbing his head up and down perhaps?
One thing I tried is eliminating the white strip shortening the bar, and centering it around the stomach of the player at all times. It's not too distracting and it's easy to watch while you play. Then I was thinking I'd open up the player's sprite, add some kind of hole or receiver in its chest and reskin the beats into a little smaller blue energy orbs, similar in color and style to the arms and legs. Then you get the sort of visual impression that when you hit buttons to the beat, the orb gets sucked in and bursts out the arms/legs depending on your action.
I'm also considering scrapping the rhythm aspects and focusing more on the platforming and combat, because the music is posing quite a few more problems. For example: where to get decent free tracks and finding the delicate balance between making the levels fun with but not depend on the boosts from following the rhythm. I'd definitely like to finish prototyping a few aspects (combat, basic rhythm) before seriously visiting that idea.
07/02/09 10:01:55 PM Platformer[2016] Platformer Error
An unexpected error has occurred during execution of the main script
IOError: unable to read font filename
07/02/09 10:01:55 PM [0x0-0x121121].org.pythonmac.unspecified.Platformer[2016] Traceback (most recent call last):
07/02/09 10:01:55 PM [0x0-0x121121].org.pythonmac.unspecified.Platformer[2016] File "/Users/kristofernelson/Downloads/Platformer.app/Contents/Resources/__boot__.py", line 137, in <module>
07/02/09 10:01:55 PM [0x0-0x121121].org.pythonmac.unspecified.Platformer[2016] _run('Platformer.py')
07/02/09 10:01:55 PM [0x0-0x121121].org.pythonmac.unspecified.Platformer[2016] File "/Users/kristofernelson/Downloads/Platformer.app/Contents/Resources/__boot__.py", line 134, in _run
07/02/09 10:01:55 PM [0x0-0x121121].org.pythonmac.unspecified.Platformer[2016] execfile(path, globals(), globals())
07/02/09 10:01:55 PM [0x0-0x121121].org.pythonmac.unspecified.Platformer[2016] File "/Users/kristofernelson/Downloads/Platformer.app/Contents/Resources/Platformer.py", line 1519, in <module>
07/02/09 10:01:55 PM [0x0-0x121121].org.pythonmac.unspecified.Platformer[2016] if __name__ == '__main__': main()
07/02/09 10:01:55 PM [0x0-0x121121].org.pythonmac.unspecified.Platformer[2016] File "/Users/kristofernelson/Downloads/Platformer.app/Contents/Resources/Platformer.py", line 1266, in main
07/02/09 10:01:55 PM [0x0-0x121121].org.pythonmac.unspecified.Platformer[2016] gameinfo = GameInfo()
07/02/09 10:01:55 PM [0x0-0x121121].org.pythonmac.unspecified.Platformer[2016] File "/Users/kristofernelson/Downloads/Platformer.app/Contents/Resources/Platformer.py", line 699, in __init__
07/02/09 10:01:55 PM [0x0-0x121121].org.pythonmac.unspecified.Platformer[2016] self.font = pygame.font.Font(os.path.join('data','freesansbold.ttf'), 36)
07/02/09 10:01:55 PM [0x0-0x121121].org.pythonmac.unspecified.Platformer[2016] IOError:
07/02/09 10:01:55 PM [0x0-0x121121].org.pythonmac.unspecified.Platformer[2016] unable to read font filename
07/02/09 10:02:06 PM com.apple.launchd[106] ([0x0-0x121121].org.pythonmac.unspecified.Platformer[2016]) Exited with exit code: 255
07/02/09 10:02:06 PM com.apple.launchd[106] ([0x0-0x121121].org.pythonmac.unspecified.Platformer[2016]) Exited with exit code: 255