Barrel Primate

DeceasedCrab's picture

So this idea has been kicking around in my head for years and I've just never gotten it off the ground because I'm a total space cadet with a full time job. I've got a decent programming background, but I know damn well that the first real game I try to make in 11 years is going to be a trainwreck... and I kind of don't want it to be. I love the idea too much. So I don't really want to go it alone, but I might.

Wrong place for this, I know. But you guys know way more about making games than I ever will. I've seen some fan-friggin-tastic works come out of the KotMs and Pirate Kart. You really learn what works best by making games that don't.

So I wrote up a huge damned design document for this game. It might look familiar. It's basically multiplayer Donkey Kong and damnit why hasn't anyone made this before. Tired of waiting, need to get it made myself if I want to play it. Heavily inspired by Pacman Vs. formula. Yes, it's an obvious clone of Donkey Kong, but I don't know if anyone's tried this before. The closest I've found to this is a map in the Zombie Master Half-Life2 mod that I can't seem to get working. And I thirst for the ability to play this.

I'm going to try to get this made. The first step is clearly "get the lobby and 1 level done and working with networking, and go from there". Icing can come later, and I'm not even considering hammers/fireballs in the first release, or any levels past the barrel level.

I've given some thought to engines to make this is. Game Maker Pro is a possibility, network support seems rudimentary but doable. I don't know what the lag would be like with GM. Torque's a possiblity, but I know next to nothing about it. And I'm not going to use BYOND, that thing is awful. I don't have any particular art or sound skills myself.

If anyone has suggestions for a good engine to make this game under, tools to consider, or stuff like that, let me know. If anyone wants to work with me on it, let me know. If anyone wants to take the idea and do it themselves, by all means do. As far as I'm concerned this idea is open to anyone who wants to do it. I just want to play the damn thing.

barrelprimate.0.0.1.txt10.58 KB
zum's picture


Urg, I completely forgot to reply to this eariler. Sorry!

First: I might be in the minority here, but I definitely don't think you're in the wrong place for this! There are plenty of folks here who'd be happy to offer feedback and encouragement and assistance. That said, you have to accept that you'll be the driving force behind this; if you want to see a game made, then you've got to be willing to make it!

Anyway, I think it's a pretty neat idea.

Some recommendations:

  • Game Maker is a good place to start. I like Construct, myself, but I've discovered that it doesn't lend itself well to major projects; the longer you use it, the more likely you are to run into something broken or as yet unbaked. Game Maker is widely-used and well-documented, so there's plenty of recourse if you get stuck.
  • Important: forget networking. If you're really set on it, think about it again once you have the game working in an offline setting. Trying to work it in earlier -- or even worse, exclusively, which is what you seem to propose -- is going to complicate implementation, make testing and iteration much more difficult, and give you migraines. Most of what you wrote doesn't imply a network setting, and the few things that do can easily be designed around. (Besides, it seems like the sort of game that'd be more fun in the presence of other human beings.)
  • Your only mention of art/resources was to note that you don't have any particular art skills, so this may or may not be obvious: placeholders and programmer art are fine! Use 'em! Lots of people seem to get hung up on having complete sprites or whatever before they can progress with the game proper. This is total bullshit. Use squares. Use stick figures. Use Klik Klipart.
  • Don't sweat the design doc. You don't have to make some hundred-person team understand what you're trying to do, nor do you have to satisfy some faceless corporate overlord. Besides, most everyone knows what Donkey Kong is, so it's not necessary to descibe the mechanics of the game in exacting detail. (Hell, why can you even start to climb those broken ladders, anyway? Nobody ever tries that more than once. I get the feeling they were supposed to extend and retract like some do in DK94, but that clearly fell by the wayside.) More importantly, details are going to change when you implement things and can see what works and what doesn't, so there's no point in delving into minutiae. Notes are always helpful, but you don't need to make a bible for something of this scale.
  • This is a bit subtler: lifting mechanics from a game and using them in a different context can be okay, but you need to be careful about how you reimplement them. For example, Donkey Kong is a single-player arcade game. This implies a few things: one, that it's not necessarily meant to be balanced over continued play. You play through a series of increasingly challenging levels, and when you complete them, they loop, faster and harder, until you can't deal with it anymore. You are meant to win for a while, and then lose. This is true of almost all arcade games. Most competitive games, on the other hand, are meant to be balanced -- even asymmetrical ones. So what works in the one might need to be adapted, or replaced, or totally scrapped in the other.

    Which sort-of relates to the second thing: The things a single-player game does to challenge a player, the forces it applies -- the barrels it throws at you, so to speak -- be they random or deterministic or adaptive to player behaviour, might not directly permit for skillful play when placed in the hands of a player. This is something that might not be totally obvious to think about in the abstract, but that I figure most people understand intuitively when they see it in practice. It's the nature of competition: that you can be good or bad at something, comparably with other people; and, ideally, that you can improve at it with practice. For your part, you propose giving the DK player multiple options to determine barrels' paths when they throw them; this obviously allows more space for skillful play than, say, only letting them press a button to throw a barrel that traces a random path. Whether it's enough, well -- I totally have no idea. You should definitely try it and find out!

I hope this helps! I would like to see this game exist!

Danni's picture

I dunno. To be frank, I

I dunno. To be frank, I don't think Game Maker is real ideal for major projects either, mainly due to the poor (and almost non-existent) memory management used by the runtime. Loads every single resource into memory when you start the game (and seems to load MP3s _three_ times, about a second per song, and that doesn't even improve playback loading times in-game!) and never removes anything from memory. You can load on call, but then once you play through the entire game, you'll have everything in memory anyway, instead of unused resources being discarded like they should be. I once played a GM6 game featuring some dude flying around with a cape, and I had to relaunch the game a couple times because the game stuttered from running out of physical memory on my 512MB machine, because I played too many levels in one session.

Game Maker is probably okay for smaller scale games, though, and it seems this is what DeceasedCrab is after.

About Construct, the main issue from what I've seen (apart from the platformer tutorial that broke due to changes in one of the 0.99 releases) is that the runtime likes to crash. A lot. Even more than Klik & Play's runtime. You can ruin it by going overboard with physics (EG. spawning lots and lots of Cheerios in General Mills Presents: Euro-Puppet's Frosty Foot-Ball until you get below 1FPS). It also likes to soil itself at random intervals (I swear, they must have put in, like, if (rand() % 5000 == 0) { crash(); }. Still I think Construct has a lot of potential - it's just not user/developer-ready yet.

PyroMallet's picture

IIRC, the load times were

IIRC, the load times were fixed in GM8.

Just sayin'. :B

Danni's picture

I won't consider it fixed

I won't consider it fixed until they remove the loading splash, cut the initial loading time down to a second, and include proper memory management, which you can get in Construct simply by toggling a single option in the project settings.

BanditoWalrus's picture

Quest Accepted

I accept this quest with a glorious Huzzah!