Thanks all for the comments!

What about the actual Apple II (C64 FTW!) era game Jumpman?

Hi,

So, the name "Jumpman" was intended as a reference to Donkey Kong. I've actually never played the 1983/Epyx "Jumpman" (though this is maybe kinda odd because there apparently was an honest-to-goodness Apple // version). But I guess that game must be a bigger deal than I thought, because a number of people have mentioned it. (Also something I found out after my game went up is that the C64 version of the Epyx Jumpman is actually on Virtual Console.) I don't know if this is going to be a problem or not.

Thanks all...

minasss, if I compile using Mesa and then I distribute the game, will it run on other people's machines using Mesa or will it use the local hardware acceleration?

The VM thing is actually a really good idea... unfortunately my options are sharply restricted on that front because my mac is PPC and can't run VMWare etc. Thinking about it though maybe I can get Linux to run under qemu... I will see how workable that turns out to be.

Any other C++ developers here? I have a bit of a problem and I don't really know where to go for help.

I made this game. Because the game was made using SDL/OpenGL and I carefully controlled the libraries I used, I'm able to do all the development on my mac and just run the game through mingw to create a windows binary. In theory, also, it ought to be possible to just compile the game for Linux and it should run.

However, I'm running into trouble when I try to actually create a Linux binary. What I'd ideally like to do is set up a crosscompiler, like the mingw install I already have for compiling Windows, on my computer. But I have two basic problems.

First, I'm not even really sure what target I'm supposed to be hitting with this crosscompiler! My understanding is when you build/install gcc you have to specify a single "target" that the gcc you're building compiles for, and this includes some fairly specific things like a libc and such that you're linking against. But aren't there more than one libc in wide use today?

Is it actually possible to compile just for some kind of generic "i386-linux" target and create a binary that different linuxes can run? Will I have to create separate binaries for different distributions, or different versions of a same distribution? (I'm not too worried about package managers, in theory my program should just be able to run out of the directory you unzip it into).

Second, where exactly do I get OpenGL headers from? When I installed mingw it came with opengl headers. However, I did some abortive attempts awhile back to compile my program on a linux server I have access to, and if I understood things correctly (maybe I didn't) apparently there are no standard linux headers? What was claimed to me at the time was that linux opengl headers actually come along with your video card drivers, like you have to install the nvidia drivers and the headers come with it. But this seems to mean that if you're compiling on a headless server (i.e., no X, no video card) or compiling outside of Linux altogether, you can't install video card drivers and thus can't get the headers. Am I missing something?

Every time I look into it it seems the answer to "how do you distribute binaries on Linux?" is "distribute source". But I don't think I'm comfortable doing that at this time. Has anyone ever tried to make linux binaries, does anyone have any advice on how to proceed?

Thanks.

So, this is a game I made. I've been working on it for awhile and I just finished it. It's called "Jumpman". There are mac and PC versions and you can get it at:

http://runhello.com/

There's also a video of the game at that page.

The idea of this game ( if it's OK for me to get pretentious for a minute ) was to kind of imagine this platonic form of the generic "really old platformer"*, like from the age of the 2600 and the Apple //, and then to try to take the world that these games described sort of "at face value". All those old games (for hardware reasons, of course) seemed to kind of take place in a world of floating neon blocks where faceless creatures slide endlessly back and forth for no reason. I wanted to imagine a world that was really just built that way.



The thought was to kind of take all the things that have become possible in games in the last 29 years-- physics, 45 degree angles, a z axis-- and bring the new technology into an early-80s-style platformer while at the same time changing the platformer's basic nature as little as possible. The hope is to try to make you believe that every 2600-era platformer would have looked like this if only you'd pulled the camera back about 4 feet. Like, every old game had something where you could walk off one side of the screen and suddenly appear on the other, right? What was actually happening there? Did space in the world where Pac-Man lives just happen to loop back on itself every ten feet? What would happen if you just took the camera and turned it a little bit to the right, would you see Pac-Man duplicated every 10 feet stretching off into the distance forever...?



The gameplay in Jumpman is, as the premise would suggest, pretty standard for a 2D platformer (although, about as hard as I could make it) but there are a few new mechanics added that are hopefully fun. Most of these have to do with exploring the idea of taking a single "level" from a platformer and trying to bring out all the possibilities latent in it, thinking, if you just jostle the components or look at it from a different angle it becomes something totally different. Like, if you think about it, the levels in these games were basically just abstract blocks-- in the days before those fancy-schmancy tiles there was nothing really to distinguish wall from ceiling. You could take a level map from one of those games, hold it sideways or upside down, and half the time you'd have an equally valid level map.

So, Jumpman outright lets you do that. There are controls to "turn the world" in the middle of play and rotate things such that the walls become floors and ceilings. In a lot of levels you have to do this to progress. There's some neat things you can do with this, like sorta you can walljump by just tilting the wall just enough to get footing on it. Etc.

Anyway the end result of all this is a game that (I hope) is built out of just a few simple, familiar components, but that comes at these components with just enough of a weird perspective to make some really fun and unique and occasionally fairly complicated situations emerge.

--- --- --- ---

If anyone cares, I started making this game about a year ago after I played "Passage", which kind of blew my mind and showed me just how complicated a really simple game can get (this + Knytt were basically the only modern indie games I had played at that point) and at about the same time a particularly sadistic romhack called "Kaizo Mario World" (which is really fun when you give it a chance!). The early-80s graphics were partially at first a way to make a video game with very few art resources, but the more I got into the project the more the game sort of turned into an intentional love letter to the apple // games I'd played as a kid and the more I kinda started to like the aesthetic on its own terms. I'm now actually planning to try to play with the whole alternate-dimension-of-apple-// thing more in future projects (Hence "RUN HELLO"...).

Anyway thanks for listening to me ramble, and I hope you enjoy this

So uh hi! I go by mcc. I spend way too much time playing and thinking about video games, which is occasionally frustrating because my taste in video games is just slightly odd enough I sometimes have trouble finding games I like. I'm basically interested in anything that challenges the boundaries of how video games traditionally work, and anything that captures the way games felt before 1997. I also find increasingly I have trouble enjoying things that don't challenge me. Modern commercial gaming has not been consistently good at indulging these three things. Indie games on the other hand...

I did not get into indie games until relatively recently because I am a mac user and so can't run a lot of the good stuff, so I just missed that any of this existed. A friend basically started hounding me until I played knytt stories and that sort of turned me on to the existence of this entire community of people who are seemingly as obsessed with ancient video games, insanely difficult platformers, and show-don't-tell storytelling as I am. Since I got turned on to indie gaming I've practically earmarked the times when my spouse is at work on weekends to sneak onto her laptop and play whatever the new windows indie games (I'm currently working my way through Iji...). I've occasionally followed content on tigsource while doing all this but never got around to making an account.

I have a rarely-updated blog that has somehow fallen into a pattern of being about pop physics and video games. If it amuses you, the probably two best samplings on there are an elaborate numerical breakdown of the physics behind Super Mario Galaxy and a half-serious attempt to establish emulator save states as an analogy for the many-worlds interpretation of quantum physics.

I have this tendency to start programming projects that get absurdly out of hand. The most recent one has been a game. I had so much fun making it that probably my next project will be a game as well. I will probably post about the game in the announcements forum if that is okay.

I like noise music a lot.

Hi, I don't have any personal experience to apply here, but have you ever come into contact with 2xSai or EAGLE? (Wikipedia lists a couple other scaling algorithms designed specifically for use with pixel art also). Some emulators I have used use these and they are the only kind of scaling I as a player am able to put up in emulators. It seems like pixel art invariably winds up incorporating sharp edges, and so then if you scale in any traditional manner it makes these edges look muddy. (Of course I imagine if you designed the art to look good with some kind of trilinear/asintropic scaling then it would indeed look good?)

Anyway the neat thing about the 2xSai/eagle algorithms in specific is that since they seem to sort of straighten out lines and smooth areas of color:



...they actually sort of look better the more heavily you apply them, if you apply 2xSai on top of 2xSai on top of 2xSai you wind up with this really interesting stylized look that makes everything look like everything's been drawn with a sharpie and a straightedge.