VOR-COM game

[eXedit]

I think that GM stores the entire project in a single file. To have mutiple developers you need to send the project file to other and use "File -> Merge Game".

[ImaginaryZ]

Yup, I played with GM this morning, and you are right eXedit, and it also adds a new folder to organize the imported objects.

Fooling around with it, I realised it has the same problems as KNP: Bad Collision Detection/Response. This is a personal hate of mine, and it really bugs me to see objects interact poorly in thier environment. However, it will be sufficient, as the example games they have prove that a platform game can be done.

Back to what I hypothesised earlier, by writing some standard scripts for predators, prey, interactions ect... we should be able to make the development process a lot easier. As soon as I can build a test script I'll try posting it.

Not to be a killjoy, but I wonder what made VOR-COM decide to abandon flash. As it stands, flash could very easily do everything we are asking for, except it would force at least one person to do the dirty work of importing sprites into flash. Ah well. If you want proof, visit my website www.gocaco.com. I've made a platformaing game before in flash, look for "Lutin".

On a other note: If we need sprites for testing, I recently learned how to use MAME to steal (yeah we can't use them, it was for educational purposes) sprites for most arcade games. Just hit F4 at some point, and use the arrow keys, page up/page dn to navigate through tiled memory. It tursn out most games store the tiles in a somewhat logical order, and using Paint Shop Pro it's relativly easy to reconstruct sprites and stuff.

[eXedit]

Bad Collision Detection? The 1945 game seems to be using pixel collision detection.

[Adamant_Borb]

According to the current specs. laid out by Adamant_Borb, GM is sufficient for the game requested.

Excellent. So we'll really be able to overlay our belly sprites onto the character frame? If so then it's official - we are all going to use Game Maker to create this project. As work gets done, I can review progress.

I don't use any IM programs, but I visit this site at least once daily and can use PMs to work out difficulties.

I went and tried out "Lutin," and I like it! The game is very simple and straightforward, and the animation was very fluid. Naturally our project will be more complex, but I saw good things in Lutin.

If Game Maker really does support pixel collision, I would be in favor of that.

[leeeroy_jenkins]

From what I've seen, if you know what you're doing, collisions work fine in GM. It's just that a lot of games are produced by people with little idea of what they're doing.

[ImaginaryZ]

Well, I haven't lookd into the overlay ability, but I think we can hash it either way. there IS a way to do it, although it may not be the most efficient way. (we can manually position sprites, so that'll work)

At this point we need everybody to get GM. If we end up finishing this project, we will owe GM some money, unless we expect to build the game without the full version (too late, I already got a serial) I played with it a bit today, and it is magnitudes better than KNP on the surface, but, like all game creation software is fundamentally flawed in it's design.

Although, being given a scripting language is my cup of tea. I need to clean up the scripts I have, but I managed to get Lutin equivalent physics working with GM. The next step is setting up how in the world a level would be designed, and writing scripts to dynamically parse that kinda stuff.

right now I'm using a highly complex fighting sprite I took from some random MAME rom. We will need a tileset if we expect to have consistency in a given level, and honestly, I prefer to work in powers of two for tiles, so a bunch of 32x32 tiles would be nice to have. I ripped some earlier and slapped something together.

The next thing to figure out is a state diagram for animations. I've dome something like this before (surpize, surprize) and it turns out the easiest way I know how to manually control animations is with a state variable, but animations have priorities in thier order of exection. Obviously, the idle state has the least priority, whereas death animations get the highest.

yeah, the collisions work OK if we use bounding box approximations and write a manual script to better control how things move, but the pixel to pixel has the classic interaction problems. I am much more fond of vector based games, but I can deal with this pixel junk for a while.

Oy, this is really going to need a chat room or some way to communicate besides forums. I attached all the junk I have at the moment. It's junk, but proves some sort of game CAN be made with GM, using scripts.

[eXedit]

Just setup a room on some IRC network.

[Adamant_Borb]

If I had a chat program, I'd do that. I'll get an IRC host if someone will help me figure out how to use it

[Sikhoten_Tiger]

I hate to bring this back to the pre-production phase but I must ask, why are you making a vore RPG. While initially this seems to make sense as a concept trying to recreate as much as possible the chat enviroment. However upon closer examination I at least see the core of what goes on in the chat not as being close to an RPG but to a toe-to-toe fighter. You have a pred and a prey and they both duke it out with their various abilities and moves until one is the winner and the loser is in the belly. RPG's on the other hand distance the player from this core action. While better RPs tend to have a lot more of the character developpment and customization that RPGs are good at, the core still is the encounter and struggle between pred and prey. My thought is that a toe-to-toe fighter would better represent what we all want to get out of a vore session, the pre-vore (start of the fight both intact and ready), voring itself (duking it out with different techniques to pull the enemy down) and post-vore (victory, next round). Naturally you don't have to listen to a thing I say but I think it's at least worth considering.

[Adamant_Borb]

I hate to bring this back to the pre-production phase but I must ask, why are you making a vore RPG.

I didn't think we were... I thought we were making a vore platform game.

The way I look at it, there already are a couple vore RPGs: Duamutef's and Taito's. I was looking to make a new vore game that nobody else had covered yet. Not only that, but this is the kind of game I'd like to play and I figure that if I'd like it, other people could too. I've never RPed vore and wouldn't know what the chat environment is like. This game was the idea I had and I'm sticking to it.

You bring up a good point in that the struggle is what draws some people to vore. However, if this is going to be a platform game I can't have elaborate fight sequences every few moments. I just like big bellies and I cannot lie. So the game focuses more on getting the big belly, and not the struggle.

Thanks for your input, though!

[ImaginaryZ]

I've fooled around with GM a little more. Not enjoying it, but it works.

On the flipside, myraids of questions come to mind:
How exactly do we want the characters to attack? Say, pressing attack starts a "upper Right Punch" animation which is a single frame, and creates a single collision box that collides with enemies?
Do attacks interact physically? (IE a punch knocks an enemy back?)
How many different attacks do we want? (Punch, kick, combo strings... should be up to the artists)
We aren't using the down key except for ladders, should we have a defend stance?
Should vore actions be an optional event? (Having to jump on top of a KO'd enemy then hit down + attack?)
Should attacking be forbidden when you have vored an enemy? (Saves considerable animation expense, believe me)
Can enemies actually fight back? I mean, really, besides just walking into you?
What powerups items are retrievable?
How interactive do we want the environment to be? (Lutin was complicated in that regard, open it and type in "first.txt" then hit load. This level shows everything in the game.)

One thing I want to have happen in code is to make ALL characters fundamentally the same. thus, you could play as ANY character in the entire game without significantly impacting the gameplay (Yeah, I know size differences might seem to cause problems.)
This codition doesn't need to met strictly or anything, but it would be a convenient feature if you had to fight a equal opponent as a boss fight.

That's all for now, my weekend is practically over, so don't expect replies till friday.
Peace out.

[Adamant_Borb]

How exactly do we want the characters to attack? Say, pressing attack starts a "upper Right Punch" animation which is a single frame, and creates a single collision box that collides with enemies?

The original concept was that when a character would approach an enemy, they'd have to be within "arm's reach" (about 20 pixels) to attack. Then they would have to repeatedly tap the space bar while a generic "grappling" animation played for both their character and the enemy. The enemy and character would each have a "stamina" value that would be measured against each other, and the player's pressing of the spacebar would increase the character's stamina temporarily for that fight. It would only last five seconds (at maximum - if the player didn't press the spacebar enough or if the enemy overpowered him it would end earlier). If the player's stamina defeated the enemy's, he would win and vore the enemy. If the enemy won, he would damage the player and take away one health. The base values would be tweaked during beta testing.

The only problem with this is it would be very hard to grapple an opponent once the character's belly is too big to reach around. I thought maybe when the player reached a certain fat level, like 5, the attack would change from a standing grapple to a belly attack of some kind (bumping, slamming) and the stamina value would increase the fatter the character got. Maybe the character could baseball-slide on their back towards the enemy.

An alternative way to attack would be to give the player a simple "stun gun" like in Commander Keen 4. Of course, then there would be no problem with arm's reach there, but there also wouldn't be much of a challenge.

Another alternative that I just came up with is a three-direction attack system. When the player entered a combat, he could attack from three angles: high, middle, and low, each attack just a single frame. High would be a high punch, middle a straight punch, and low a kick. The enemies could dodge by ducking, backing away, or jumping. Some enemies could only be hit by certain attacks (e.g. the rabbit could only be hit by a low attack). This would force the player to anticipate the enemy's next dodge and then attack where they weren't dodging. The fights would still last a certain amount of time, and if the player didn't score a certain number of hits he would take damage. Different enemies could take a different amount of hits (e.g. rabbit takes only 1, cow takes 5). Once the player got too fat to reach he could switch over to the belly slam technique again.

Please let me know which system you think is best. My personal preferences lie in either the spacebar system or the high/mid/low system.

Do attacks interact physically? (IE a punch knocks an enemy back?)

No. However, the enemies could flee a certain distance away if they escape the character's first attack.

How many different attacks do we want? (Punch, kick, combo strings... should be up to the artists)

Depends, as before, on the combat style. If we go with the spacebar system, artists would only have to draw one or two grappling frames for each character and enemy. If we go with the raygun system, they'd only have to draw a "firing" frame. If we go with the high/mid/low system, they'd have to draw three attack frames for every character and three dodge frames for every vore-able enemy.

I don't want to make the artists draw too much, so I'm avoiding elaborate combat animations.

We aren't using the down key except for ladders, should we have a defend stance?

I never thought about this. Good idea! As in Mario Bros., the down stance could be the character's "duck" frame. It would become less and less effective as they got fatter. The only use I could see for it is in boss battles where the character has to dodge projectiles. We could give it an additional use in combat - if the player fails to win, he could tap the down key during the enemy's "attack" animation to avoid the damage. Please comment/discuss.

Should vore actions be an optional event? (Having to jump on top of a KO'd enemy then hit down + attack?)

Yes. Another great idea! The down + attack key combo will allow characters to vore KOed enemies and gain points. There will be instances where the character is very fat and a cow blocks their path - they wouldn't be able to vore the cow to move on, so they'd be stuck until they digested some stuff. You could just go around KO-ing things, then pick what you wanted to vore.

Should attacking be forbidden when you have vored an enemy? (Saves considerable animation expense, believe me)

Yes and no. As I said, at certain fat levels the character can't reach his enemies coz his belly is too big. But I still want people to be able to get up to fat level 10. Of course, at fat level 10 you're unable to attack because you're immobile.

Perhaps you meant something else by this question. Please clarify it if I didn't answer you fully.

Can enemies actually fight back? I mean, really, besides just walking into you?

No. Like in Mario Bros. enemies can't damage you unless you lose a combat to them, or they touch you when you're not attacking them. The only enemies that actively attack you are some machines (like robots and rayguns) and the bosses. If every enemy could attack, the game would probably get too hard and would be too much for the artists. The "attack" animations enemies get when they damage you should only be one frame long.

What powerups items are retrievable?

By this I'm sure you mean just what powerups are there in general.

First aid kit = Restores health to full
Food (hot dog, hamburger, ice cream, egg, lollipop) = +1 health, +0.5 fatness, points
Digestive pills = -1 fat level
Digestive acid = fat level drops to zero
Spring shoes = Jump height x2
Rocket pack = Unlimited jump height
Boxing gloves, barbell = attack bonus (this depends on our combat system)
Money = points

How interactive do we want the environment to be? (Lutin was complicated in that regard, open it and type in "first.txt" then hit load. This level shows everything in the game.)

I'm opting for no environment interaction. It increases the workload on both coders and artists, and might make the game too complex. Only in certain instances will the environment affect the player (e.g. lava, ice, etc.), and the player will only be able to affect the environment during boss battles (e.g. dropping bricks on the farmer).

One thing I want to have happen in code is to make ALL characters fundamentally the same. thus, you could play as ANY character in the entire game without significantly impacting the gameplay (Yeah, I know size differences might seem to cause problems.)
This codition doesn't need to met strictly or anything, but it would be a convenient feature if you had to fight a equal opponent as a boss fight.

This was my idea as well. The player characters would all have the exact same abilities. It lessens coding and prevent players from picking the same character over and over again because of the character's powers. The whole idea of selecting the species and gender of your character was only meant to cater to people's tastes in pred. All characters will also be the same size (even the dragons and snakes). Only enemies will vary in size.

Thanks for all the great questions and ideas. Keep 'em coming! I want to leave no stone unturned.[url][/url]

[ImaginaryZ]

Ok, things to note:
1. Overlays work flawlessly. May require more frames than desired, look into alternatives
2. Basic setup of a platforming game works.
3. Simple animation works.
4. Script based game setup works, puts low strain on authors.
5. Merging projects works, ideally content makers would use strict naming conventions and coders would merge that art with the master project.
6. To do this requires the registered version of Game Maker

I'll have more questions later, Adamant_Borb. Thanks for answering the last couple!

[Eka]

Now all we need is basically the sprite? Maybe it is time to make a list of sprites we need with the detail and dimesion along with it?

[Adamant_Borb]

I've PMed our artists with the basic sprite guidelines. Only one has responded as yet.

Let's discuss our naming conventions - what standards should we use?

Also, we've pretty much outlined our character and powerup sprite needs. Coders, please help me out with what file type and background color we should use.

Floor tiles are set at 32x32 pixels. There will be tilesets for every group of four levels - each group will be a different "world."

Here are my current ideas for enemies, with their sizes in pixels (width x height):

Rabbit = 35 x 35
Chicken = 40 x 40
Duck = 40 x 40
Goose = 50 x 50
Cat = 60 x 40 (tail straight out)
Turkey = 70 x 70
Fox = 80 x 45 (tail straight out)
Dog = 100 x 60 (tail straight out)
Human = 75 x 150
Pig = 130 x 75
Sheep = 135 x 90
Deer = 190 x 130 (no antlers)
Cow = 225 x 150 (tail flat down)

These are genero-brand enemies to be found in all levels. I'm still working on mechanical enemy concepts.

[ImaginaryZ]

I boosted the power of the setup I have. This one demonstrates lots of things, but is still flakey. I'll comment more this weekend, but I don't think we have to restrict sprite sizes (When you download the test project, go to the "CharacterInitScripts" folder, pick a init script for some character, and change the value "int_scale". It will dynamically scale characters. you might fool around with the others too.)

With this script based setup, GM is suddenly like flash. And I'm decent at flash.

Peace out.

[ImaginaryZ]

OK, first thing I need to explain a lot about what I have so far with Game Maker.
I have managed to:
1 get basic platforming almost working (penetration/locking issues still)
2 added "trinkets" and "foods"
3 and some powerups
4 made some simple tiles so I wouldn't have to worry about those later
5 copied some sprites for temporary art
6 added a simple vore system similar to what Adamant_Borb described
7 added projectiles
8 got a smashed together GUI setup working

Now to answer questions:

Let's discuss our naming conventions - what standards should we use?

Well, since Game Maker has to eventually import each image (or series of images), the internal naming convention is really the only important one. I've made a pseudo-standard for that, but it doesn't apply to artists. It ends up that somebody has to import the sprites, and set centers and bounding boxes for each animation. I've made 3 examples using MAME srites, so for GM people it should be straight forward.

As for game applied naming conventions, I've made up these: (arbitrary)

"character" - anything that moves around based on a input. this includes player characters and enemies driven by AI scripts. Characters contain a large list of variables that alter thier actions.
"trinkets" - those little collectable things that only give you points. I could lecture about this for at least 5 pages.
"foods" - Food items that increase fatness and health slightly
"powerups" - Anything that gives a character a additional ability, whether temporary or permanent

Each character as of right now has these animations:
idle - the most important frame, when a character is idle (0 - n frames, cyclical)
walk - animation for a character moving (0 - n frames, cyclical)
jump - animation for a character jumping or flying (0 - n frames, cyclical (keep it low) )
climb - animation for a character climbing a ladder (0 - n frames cyclical)
hit - animation for character recieving a hit/being hit (0 - n frames, keep it low please)
duck- animation for character ducking (Not Implemented yet, ignore)
dead - animation for character being dead (0 - n frames, stays at last frame permanently)

Also, each character can support a "bulge" overlay, which at this point is a overlay for only the idle animation. This is apparent in the current version I uploaded. It is a good idea to keep your character centered in a way that makes sense, so that bounding boxes and centers can much mroe easily be generated.

All the other important statistics can be filled out in the Init scripts in GM.

Coders, please help me out with what file type and background color we should use.

Filetypes, I would prefer 256 color .bmp's, and once again, the leftmost, bottom-most pixel is the transparant color. I reccomend using (255,0,255) as your trasparency color as it is rarely used. do NOT use black, white, or other commonly used colors.

Important: This current system uses a base unit of 16x16 pixels, so 1 tile is 16x16 pixels. This means, you should keep your sprites in proportion to this unit. Although, I have made this setup to use dynamic scaling, so oversized/undersized sprites can be scaled in code, but at the loss of quality. I would request that characters stay in this square range: 32x32 to 192x192. Any dimensions inbetween should be A-ok.

The more sprites the better! (sprite is a generic term for a 2D character in a video game)

Now for some questions:

Adamant_Borb, I've probably gone way out of bounds with all of this, could you review what I've done and make a list of additions/corrections? Thanks.

Attacking: As of now, I'm not quite sure I like the idea of two rectangles fighting it out. I didn't like how barbftr.swf's mechanics ended up, and I know how hard it is to get a Hybrid Heaven type system working. So, I suggest we make it like many games, where an attack is actually the creation of a projectile that has a timeout and short range, making it look like you threw a puch when in reality you just threw a projectile. This is usually much more fun in terms of gameplay, and won't affect the "kill a character then vore them" concept. Also, it will make it much simple to animate, because a attack animation isn't required. What does everyone think?

Demonstrations: Should I compile an .exe and post it so everyone could see what I'm talking about?

Environment: A game needs environments. I need a list of potentials so I can continue to make the RunCharacter script more and more robust. For example, Adamant_Borb, you mentioned ice levels with killer penguins, that's a good classic environment to use, but we need more. Possibly, we need some sort of gameflow map for all this, so the character can jump from area to area without feeling too disoriented. (farm to field to village to forest ect...)

Audio: this is easy to do, but I'm not sure how we want to hangle this. Goofy, realistic, abstract? Maybe a mixture of sounds? I like abstract noises for interactions (Like using real instrument sounds for collisions and actions) and goofy sounds for everything else (boings, zips, and chimes, ect...) Ideas?

Mechanics: this setup may get some things done right, and the basic idea won't change. However, additional speed-ups and accessories and functions are still lacking. Any help would be appreciated.

Thanks for tolerating this huge post! Keep up the good work![/quote]

[Adamant_Borb]

I've played the new demo over and over and I like how it's coming so far. The look of the sprites will of course be different, but the gameplay is great. We'll work on the combat method.

One thing I've noticed: it seems that the little lizards can eat the food items. In the final game the enemies can't interact with powerups.

OK, first thing I need to explain a lot about what I have so far with Game Maker.
I have managed to:
1 get basic platforming almost working (penetration/locking issues still)

There are a couple problems with going up/down ladders. Apparently you've got to be in just the right spot to do so. I'm sure this will be fixed later.

2 added "trinkets" and "foods"
3 and some powerups
4 made some simple tiles so I wouldn't have to worry about those later
5 copied some sprites for temporary art
6 added a simple vore system similar to what Adamant_Borb described
7 added projectiles

Oh yeah - I'm a dope and can't figure out how you programmed the attacks. I've just been jumping on enemies. If we used the high-mid-low combat variation, I'd want the attack keys to be E, D, and C. But it seems that combat mode is a bit clunky. We'll work it out.

Good job with setting up the naming conventions. Everyone will use those for the project to streamline business.

Each character as of right now has these animations:
idle, walk, jump, climb, hit, duck, dead

No animations missing! Good job.

Filetypes, I would prefer 256 color .bmp's, and once again, the leftmost, bottom-most pixel is the transparant color.

All right, it's set. Everyone will use this standard.

I would request that characters stay in this square range: 32x32 to 192x192. Any dimensions inbetween should be A-ok.

If dimensions for sprites are to remain square, I'll re-set the sprite sizes accordingly, and put them in a 16-divisible pixel size. But the actual characters won't have to take up the whole sprite canvas, correct? The actual sizes of the characters will remain the same as previously listed.

The more sprites the better!

Absolutely right!

Adamant_Borb, I've probably gone way out of bounds with all of this, could you review what I've done and make a list of additions/corrections? Thanks.

The only thing I'm worried about is the sprite size. I don't want all characters to have to be square, but as I outlined above, they probably don't need to be, right?

Attacking: As of now, I'm not quite sure I like the idea of two rectangles fighting it out. I didn't like how barbftr.swf's mechanics ended up...

Barbftr's mechanics were difficult to figure out at first. The way I looked at it, barbftr was a good start. I was looking for something a bit more simplistic, but the players should still have to work for their vore. As I've said twice above, we'll work it out.

I suggest we make it like many games, where an attack is actually the creation of a projectile that has a timeout and short range, making it look like you threw a puch when in reality you just threw a projectile.

I like this idea. Unfortunately I can't figure it out in the current demo, but I'm sure I'm just a dumbass. The "projectile-punch" method would probably be better than the hi-mid-low method. We'll go with that.

Demonstrations: Should I compile an .exe and post it so everyone could see what I'm talking about?

Absolutely!

Environment: A game needs environments. I need a list of potentials so I can continue to make the RunCharacter script more and more robust. For example, Adamant_Borb, you mentioned ice levels with killer penguins, that's a good classic environment to use, but we need more. Possibly, we need some sort of gameflow map for all this, so the character can jump from area to area without feeling too disoriented. (farm to field to village to forest ect...)

I've already given some thought to this. Earlier I said the farm animals listed in one of my last posts would be genero-brand enemies found in all levels. I'm scratching that. From now on, vore-able enemies will be different depending on the world the player is in. The standard enemies will be the non-vore-able ones: robots, rayguns, etc.

Previously I said there would be 24 total levels, divided into groups of 4 with a boss at the end of the 4th level (a la Mario Bros.). This creates 8 different environments, and they will be as follows:

Farm World - cows, chickens, sheep, etc. Boss: Farmer.
Village World - humans, pets, raccoons, etc. Boss: Giant Police Dog.
Forest World - bears, rabbits, deer, etc. Boss: Bigfoot.
Mountain World - goats, cougars, marmots, etc. Boss: ???? (Suggestions?)
Ice World - polar bears, killer penguins, seals, etc. Boss: Abominable Snowman.
City World - humans, pets, pigeons, etc. You got here by sliding back down the mountain on your big belly. Boss: Army Tank (yes, you still vore it after you beat it.)
Sewer World - big rats, sewer monsters, humans, etc. Boss: Great Sewer Monster.
Dragon's Lair World - lizards of all shapes and sizes. Boss: The Great Dragon.

Audio: this is easy to do, but I'm not sure how we want to hangle this. Goofy, realistic, abstract? Maybe a mixture of sounds? I like abstract noises for interactions (Like using real instrument sounds for collisions and actions) and goofy sounds for everything else (boings, zips, and chimes, ect...) Ideas?

Sound is the one area I do have expertise in. I figure once we've worked out everything else we can add the sound effects in. I will compile and create sound effects for the game. Allow me to use this time to request that everyone send me their sound effects, either by PM or email, and I will go through and extract the ones I like. I figure this'll be my share of the hard stuff.

Mechanics: this setup may get some things done right, and the basic idea won't change. However, additional speed-ups and accessories and functions are still lacking. Any help would be appreciated.

We'll have to divide up the workload now. I know leeroy_jenkins said he'd be willing to do anything but level creation. eXedit, I'm not sure we ever worked out if you wanted to help, and if so, what you wanted to do. Everyone please PM me and I'll divide up the workload accordingly.

ARTISTS: Let's see some ideas! Feel free to PM me with conceptual artwork.

Okay, I'm done.

[ImaginaryZ]

One thing I've noticed: it seems that the little lizards can eat the food items. In the final game the enemies can't interact with powerups.

No problem, just change the variables for that enemies init script. "int_collectsfoods = false" will prevent an enemy from collecting food items.

There are a couple problems with going up/down ladders.

I haven't noticed the glitch with the ladders yet, but I'll see what I can do.

To attack, you first need a weapon. Ammo is on the lower right, hitting j, k, l or the "." key will change weapons.

The only thing I'm worried about is the sprite size.

Whoops, yeah. What I said was pretty ambiguous. All I meant was that to make it easier for the setup of a sprite, that all the frames for that sprite should be the same size, and probably no larger than 192 pixels in any dimension

I like the environment seuggestions! All we need is art and a lot of code improvements and polish.

Most of the work is by correctly setting up the sprites, by making sure all frames except for dead and hit have the EXACT SAME CENTER and collision box. This is critical for the game to operate correctly. Also, the weapon offsets have to be manually entered, and that takes time to get right. The easy part is filling in enemy scripts and adding enemy objects to Game Maker.

Sounds great everyone! Let's see where this thing goes...

Play the test application! Give us feedback! Yeah!
(Argh, the game was too large to post so I put it on my gallery. Bummer.)

[ArrenJevleth]

I'd so very much like to try the game out, but without a registered version of Game Maker, I can barely touch it. >_>; Is it at all possible yet to make it so that the registrationness isn't needed? Or is it not meant to be played by just anybody yet?