The place of Everyone’s Platformer is somewhere between that of a textbook, in being able to use it as a basis for practicable assignments, and an electronics lab kit, in offering raw components that can safely be rearranged on anyone’s own time in the search for emergent patterns and application to each person’s particular interests.
Budding inventors need to take things apart; open source commercial projects are often too massive to fully understand (developed over 6-24 months of large team collaboration), while demonstration code is often too simplified and isolated to be understood in context. My goal was to make something in the middle: 1 person, 1 month, taking on a recognizable form, with multiple meaningful points of entry for developers having differing interests and skill levels: map design, aesthetics, game AI, and so on, up to a complete overhaul.
This is not so much an open source project as it is an unusually expansive pile of connected demonstration/example code, though intended to encapsulate as much or more about game design (user experience, tuning, system relationships) and game production (development tradeoffs, efficient authoring, content pipeline) as it is about the underlying programming.
Play, Edit, Compile
I think the loading stall is fixed as of v98b. (If it hangs though, Refresh.)
Everyone’s Platformer: Exercises
I spent my HobbyGameDev writing time this month creating Everyone’s Platformer, which means this will be the only HobbyGameDev post for Sept 2010.
In keeping to my usual pattern of separately addressing Beginner, Intermediate, Advanced, and Special Topic, here are recommended exercises to be done with the downloaded source, depending upon your experience and interest in solo game development:
Play through the demo, making notes of what you wish was different about the level design. What frustrates? What excites? What lures or confuses? Then, explore using the level editor to build a few new maps, attempting to account for the ideas in your notes. Save those maps (it saves to your hard drive with a file name prompt, no worry about overwriting my or anyone else’s work) to test with friends, or expand and refine in the future.
Stretch Goal: Unlike enemy/item art or audio, the level theme art can be changed without recompiling, and it will be read in when the game or theme next loads. If you’re comfortable with (learning?) GIMP/Photoshop, modify the appearance of level art in the themeart folders to give one or more of the themes a completely new feel. (Although the level art can be replaced without compiling, you will still need a local version of the swf – just unzip that to the same directory the unzipped source code is in, next to the themeart folder and FlashPlatformer.as file, then double click it to start the editor with your level art.)
Explore the “Piece Edit” mode, in the context of what effect it has on the level editor. Based on that finding, replace the art assets in one of the theme art folders with new shapes. Use the Piece Edit mode to define their collision data (be sure to save the coll.dat file from that mode when done), then create some maps using your custom building blocks.
Stretch Goal: If you are comfortable with (learning?) command-line, follow the mxmlc install tutorial then ReadMe.txt instructions (see below) to be able to recompile the game. Once compiling works, you can replace enemy, item, and player animations, as well as the game’s audio files, and so long as file names stay the same simply recompiling will update those assets in your swf (no programming changes required). Replace the sounds and animation for the player character – or as a less ambitious start, replace the enemy art.
Inspect the source code to see how it fits together. Pick any enemy, determine a change you would like to make to its behavior/AI, and implement the change. Develop one or more levels (employing custom pieces if interested – see the Intermediate section above) that can serve as an ideal habitat for the player to engage with that new AI behavior.
Stretch Goal: Add any of the following to your copy of the engine: menus, text+image transitions between levels (only relevant when ALLOW_EDITOR in c.as is set to false, since otherwise stages don’t advance), projectile weapons, linked teleporters, moving platforms, contact volume triggers, AI line-of-sight checks, “warp zone” doors connecting locations in different level files non-linearly.
Total conversion. Re-skin and modify the content into something coherent and original. Through replacing the graphics and audio, building levels appropriate for that new media, and at least a few programming tweaks, transform this into something unrecognizable from its current presentation. Old western, or cave man platforming? Roman gladiator training course? Cleanup after a time travel catastrophe?
Stretch Goal: Build some game type from this engine that is not a platformer. Side view helicopter combat, overhead tank RTS, or something else entirely. The foundation is there for optimized rendering/collisions, level editing/exporting/importing, audio handling, keyboard and mouse input, enemies, items, particle effects, etc. Keep what’s handy, throw out what isn’t, and figure out how to add whatever’s needed.
There is no time frame for these tasks, besides the one you choose. If there is something you want to do (and more compellingly, something you want done), but to do it may take 5 days, 5 weeks, or 5 months, that’s fine. There’s no due date, it’s just a matter of learning and making progress one day at a time.
Source ReadMe.txt Contents
This project compiles at the command-line using Adobe’s free mxmlc compiler. Although the output is a genuine Flash SWF file, compiling or modifying this project does not require Adobe Flash CS or Adobe Flex/Flash Builder software.
For this project, cd to the flex_sdk_4 directory, then, replacing @ with your relative source folder path from flex_sdk_4 (mine is projects/FlashPlatformer )…
Web compilation, to be played and shared online:
.\bin\mxmlc @\FlashPlatformer.as -static-link-runtime-shared-libraries
Local compilation, to be played or tested locally:
.\bin\mxmlc @\FlashPlatformer.as -static-link-runtime-shared-libraries -use-network=false
Web compilation, to be played and shared online:
./bin/mxmlc ./@/FlashPlatformer.as -static-link-runtime-shared-libraries
Local compilation, to be played or tested locally:
./bin/mxmlc ./@/FlashPlatformer.as -static-link-runtime-shared-libraries -use-network=false
To clarify the above distinction: if use-network is true or not specified, the levels/art will not load if run locally. If use-network is false, the levels/art will not load if run online.
For additional resources on learning ActionScript 3 as it is used in videogame programming:
Free Programs to Edit Assets, Find Music
To play the game via the editor on your own computer, all that needs to be done is to compile a local/test build (see section on Compilation Instructions), then double click on the FlashPlatformer.swf file created in the project’s directory.
Instructions follow for deploying the swf to be played online.
In c.as, set the value of ALLOW_EDITOR to false. In addition to disabling Tab-key access to the editor, this activates level progression, so that as each level is completed the next in the map list will be loaded.
Have saved whatever map designs you would like as files lev1.map, lev2.map, and lev3.map in the same folder as the swf. Likewise, replace whichever art you wish to change in the images and themeart directories.
If you have not already done so, adding some simple title screen functionality would be a nice touch. The pattern for how editor help and end game message get shown can be used. Likewise, it would be nice to personalize the end screen graphic.
Compile for web/sharing (see section on Compilation Instructions).
Copy the following files via FTP to a server. Folder names, file names, and relative paths must be preserved, except FlashPlatformer.swf which can be renamed:
FlashPlatformer.swf – game file, to embed or share the URL for
coll.dat – collision data
lev1.map – level 1 map (these can be different if levNames in c.as is changed)
lev2.map – level 2 map
lev3.map – level 3 map
themeart/[all] – subdirectories of theme art (those listed by themeFolders in c.as)
If – and only if – submitting a game based on this engine to a host that insists on a single file upload (which is not a problem if it’s your own general web space, but many portals prefer single file games), the source can be modified to embed all level, collision, and theme art data into the swf during compilation. How to do that is not covered here, although google can help for embedding binary files (the map/collision data), and there are examples in the source of image embedding which could be extended. A lazy alternative to embedding the .dat and .map files would be to temporarily comment out the calls to compress() where data gets saved, save out all maps+collision information (yielding plaintext XML), then copying/pasting that XML into new XML variables within the source. Then the XML variables could be copied or referenced, rather than loading fresh from external files. Either way, how theme art is handled would require adjustment.
I can be reached via HobbyGameDev@gmail.com
To learn more about my background and work: http://chrisdeleon.com/
Released under Creative Commons Attribution 3.0
In summary: You are free to modify, build upon, or pull from this source, provided that you include a plainly visible attribution credit (fine if it’s buried in an options menu, provided it requires no secret knowledge to find) along the lines of:
“Everyone’s Platformer” Engine Code and Design by Chris DeLeon
or, if your game project is only vaguely derived from or severely modified off my source:
Based on “Everyone’s Platformer” Engine Code and Design by Chris DeLeon
It is important that the collision data for a level piece not go outside the boundaries of its art. This is because the same QuadTree structure gets used for both rendering and collision of level pieces. Though the in-game piece editor automatically cuts rectangle pieces safely into the bounds, if the dimensions of the art are decreased without making new piece collision to match it, strange/shaky collision behavior may happen near the edges of that piece.
On The Choice of Licensing
I decided to release this project under Creative Commons Attribution 3.0.
I am aware that the Creative Commons foundation discourages using non-code specific licensing (i.e. they suggest GPL) for software. However, this is a foundation for a videogame – each developer’s needs will be completely different. It’s not a utility program that warrants centralized updates of common interest to all users. This project has more in common with a book, a song, or a film, than it does with OpenOffice, FireFox, or a Linux distribution.
Developers should not have to worry about redistributing this with a particular license, facing a wall of fine print, or feeling any obligation to take part in open source if they’re not ready, able, or eager to do so. I just want people to learn from and/or do something with this.
It was a toss up between Creative Commons Attribution license, or none. I only erred in favor of the former because I find it civil and encouraging – it explicitly welcomes remixing and sharing, with only a simple credit as contributing author requested in return.
Use in Completed Games
I extended, modified, and further customized this engine to develop – with the help of some talented artists and another producer – Vision by Proxy: Second Edition, which has been played 6.9 million times (tracked by MochiBot) and won 1st in Student Showcase at SIEGE 2011. Propelled forward by that success we then built a sequel with a larger team, again building upon an even further updated version of this engine, creating Ms. Vision by Proxy.
Subscribe by e-mail to receive an update every month of all new HobbyGameDev articles, videos, and game development resources.