Test release.

Use the arrers to catwalk strut around, Z to give it all some bladed wrist action and C to magically appear more zombies.

In my continued efforts to avoid working on Monster Mashers (and due to a bolt of inspiration) I am now working on what is basically Oneechanbara with a dinky visual style and more exploitive animations. I've laid down the basic groundwork here which I will obviously elaborate on further. Zombies will wander around aimlessly until they approach a 64 pixel radius to you where they will then home in. Slashing them with your sword will cut them in half when they will shortly disappear. Only a maximum of 32 zombies can hang around at once if you ignore the few that are hanging around at the start, slightly more than 32 if you leave those cats be. I intend to enlarge all the sprites but only after I have all the animations done so you'll have to bear with the titchy bird and her dead friends for the time being.

Next version will probably have more attack animations (combos!), blood, zombie dismemberment and my version of the 'tired' animation which is totally different as it involves more ass shaking and breast swaying. Achievement Unlocked: Objectivism Get!

Attached are screenshots from my linked even/odd object pairing tests. There are two shots of the rope/grappling hook test (old version) and three from an attempt using the same idea to generate artillery-like landscapes. (I have it set up to make the ground in the middle steeper than the flatter terrain, in hopes of it generating mountains.)

Sorry about the boring solid-colored research-paper-like graphics, but I am just messing around with behaviors and effects right now.

In an effort to help this site grow, I will be giving weekly updates on my various experiments with Glorious Trainwreck's favorite democratized game creator, Klik & Play. I haven't used KnP in 8 years, during which I've learned a fair amount about both programming and game design by making games in other languages, and working towards obtaining a college degree in computer science (the last part being in the last 3 1/2 years). So far, returning to the event-based game design paradigm has felt extremely limiting. Many simple things I could do in more advanced languages are either difficult or impossible to accomplish in Klik & Play. What I've found very interesting, though, is that solving Klik & Play problems rely on both computational, and physical strategies. What would be impossible to do with the built-in object movements can usually be done with numbers, and what is difficult to do with the limited calculation abilities of Klik & Play can be assisted with the built-in movements, or other properties and behaviors of the program.

One of my later projects in KnP was an attempt at recreating the grappling hook, or "Ninja Rope" from the game Worms. At the core of my original design was a platform movement object constantly shooting particles at the grappling hook center point. I assumed that I could measure the distance from the player to the center point by the number of particles not destroyed by contact with the hook. Whenever the number was too high, I would lift the player higher. Eventually there would be some swinging code, changing angles, and everything would work out fine. Of course, this didn't work at all. The player quickly levitated off-screen, never to be seen again.

Yesterday, I took up the problem again. My first notion was to create chained object groups in even-odd pairs, aligning them by hotspot to action point. After a lot of testing various object selection methods (to some rather hilarious and frustrating results), I found a simple cycling scan worked best to build a segmented chain. I could easily manipulate the length by setting visibility cutoffs for chain elements with values higher or lower than the desired length. The biggest drawback to this multi-object line was the apparent refresh rate, due to the cycling update. With only 16 chain elements, the fastest I could rotate the construct was once per 30/100th of a second. I went as far as adding objects to calculate and visualize impulse speed (IE: letting go of the rope), but the results were inconsistent.

Today I plan to revise the system to a two-origin line, by calculating the end point of the chain directly, and drawing the line from both ends. This should effectively double the refresh rate, and thereby the maximum rotation speed. But by calculating the end point directly, the chain becomes not the driving force of the simulation, instead a visual cue. If the visual representation of the chain becomes broken slightly at high speeds, at least the actual positioning of the end point will remain consistent.

I have taken screen shots of this experiment, but I'm not currently at the computer they're on. I might post them later if people are interested in them. Next time I'll either talk about the difference between a swing simulation powered by update wait adjustments vs distance adjustments, or I'll talk about misuse of the built-in platform movement to approximate a limited physics simulation. Whichever people are more interested in. Or I'll post some pixel art. Who knows for sure!

Back in the heyday of Klik, I sometimes called myself "The Master of Useless Effects". I've spent a lot more time on game design balancing as of late, but sometimes it's just fun to make effects. At least now I have a better chance of transforming these ideas into finalized projects!

While I realize this community is relatively new, it seems a pity that so few people participate in such an inviting opportunity to rapid prototype simple games and quickly receive feedback. Much of the humor of this site comes from the internet stigma of Klik & Play, which can both serve as a retro incentive for creators to return to using tools they had long since discarded (and discover new possibilities), and to deter potential creators with our self-deprecating ironic use of horrendous pre-amateur design. While we can appreciate the unique aesthetic of non-design, it should not be the isolated goal of Glorious Trainwrecks to reproduce the past without recognition of the present. There have been changes in the independent gaming scene. Just because we use a tool from 1994 doesn't mean we must use it as it was used in 1994.

A defense of Klik & Play:
On the surface, KnP may appear limited. And in many ways it is. Events will never be like lines of code, and "Active Object" is not the only class we need. But consider this: Many of the games gaining recognition in the independent gaming community today could have easily been produced in KnP, if not for a few surface details in graphics. KnP could be used to make interactive comedy like "I wanna be the Guy" or "Death Worm". It could be used to make surrealist experiences like "Psychosomnium", or introspective commentaries like "Passage". It could even present political commentary like "Harpooned". KnP may lend itself more easily to comedy, but it gives your average Joe a chance to try to say something with a game.

My goals here on this site are twofold. First, I will use my participation in the KOTMK to experiment with pure game design. I wish to see what new goals I can set for a player, and what new ways I can have the player interact with a system. Secondly, I will begin a Hosted Trainwreck, the purpose of which will be to push the boundaries of advanced KnP event writing. KnP is capable of far more complex things than we think. The Moteur engine proved this. KnP Tetris proved this. Time and time again, people have done unexpected things with a limited palette.

And who knows? Maybe my impression that KnP still holds potential is perfectly in line with the overambitious naive klikkers of yesteryear. If my lofty ideals are doomed to irony, there is no better place for me to fail than here.

Shovel some more coal on the furnace, and sound the steam whistle. This train is on its way.

I haven't done anything regarding the engine since the last entry, instead I've been animating a golem character. Until I pixel wolfman and vampire sprites this will be what players will control during most of the developmental stages. It's not really placeholder art, I intend to keep him in as a third character when the other two are done then I can work on a fourth character as this game will have support for four players.

All the animations aren't finished yet, I have to add two more throwing animations (and fix up the leg on the last sprite in the 'throw left and right' animation), a hurt animation, one for falling over and a victory animation. Then do everything over again thrice more.

So my comment on Pizza Time's Monster Mash ideas and my love of Earth Defense Force 2017 has led me to

EARTH DEFENSE FORCE 1817

A KNP effort. The game play lacks that certain something, but it has some elements I dig:
* Robotron style controls
* Looming Alien Ships with Shadows
* Bugs who track you down but have to move around the buildings

I think some of these elements could be used in future games.

In the unlikely chance I can't make it to the KotM I'd like this to count as my entry...

New version of Grand Theft Shmup! YAY! As this is a rapid prototype, new versions should be very rapidly released.

This game is becoming a really weird shmup. I heard that dashing doesn't give good feedback to the player, so I added a trail, and I then wanted to show enemy bullets bounching off the dashing player, so I made it so that enemy bullets colliding with the trail are replaced with player bullets going the other way. This had the side effect of meaning that whenever the player dashes, he creates a shield from enemy bullets that lasts a second.

I think it's kinda cool, but I'm not sure if I should leave it in. Any feedback from you guys?

Also, I think I should make it move obvious that you can take over the enemy ships by touching them while not dashing and that you can destroy enemy ships by dashing into them, as not many people are going to try to collide with the ships on purpose. Maybe I could add a prober help screen next version? Or a tutorial or something?

Changes to v0.03 are:
Dashing now creates a shield that defects enemy bullets.
Dashing now make a noise.
You now cannot dash the whole time.
Sub Boss appears sooner, and is harder

Credits:
PenguinSeph - Game Design, Programming (I used MMF1, but it's still kinda programming), "Art"
DrPetter of http://www.cyd.liu.se/~tompe573/hp for making sfxr
Everyone who has commented so far!

The controls are:
Arrow Keys - Move
Shift - Dash (while in dot mode) or Shoot (while in Ship mode)
Control - Jump out of ship.

DOWNLOAD IS HERE

I think this is starting to come together. Once the prototype yields a solid, playable mini-game (I'm shooting for one level) I can start production proper. I guess I'll need some decent graphics at that point.

Give the racing game the run-around and put Freestyle Box Wasteland back on the shelf, it's monster time!

Attached is a test version of the fourth idea I had that I am going to be working into an actual game, the third one was going to be a Chu Chu Rocket clone only it was going to be Cock Cock Rocker where you had to guide the rockers into the limos and turn away the screaming fans away but I only could go far as having a single rocker turn ninety degrees when hitting a wall (by, cleverly, changing the angle, which is a device that I should use in more games) as I don't think it's possible to take it further than that or at least my skill level.

See, I want to make a game that could be fun in both single and multiplayer (single player in Cock Cock Rocker would just be a puzzle mode as there is no way I would be able to do multiple AIs using such a basic Klikteam product. Maybe in Multimedia Fusion but not this) and the whole players managing a group of NPCs seemed like a good idea for fast action and laffery so I took the 'herding' mechanism of Chu Chu Rocket and changed it to something that was more direct and that evolved into what we have here. The next step will be either be making the game about herding small objects or eating the most small objects before the timer runs out.

Or maybe just giant Dracula versus giant Wolfman battling whilst small objects run away only to be crushed underfoot whilst you toss buildings and cars at each other until there's only one monster left. That's pretty rhinoceros innit.

That will be the plan for Monster Mash - Gigantic Creature Feature Throwdown.

New version of Grand Theft Shmup! YAY! As this is a rapid prototype, new versions should be veru rapidly released.

Changes to v0.02a are:
You now have a life bar. The dot can take 3 hits before being destroyed.
After taking a hit as the dot, you are invunerible to damage for a few seconds, and all onscreen bullets are destroyed.
When you jump out of a ship with Control, all on-screen bullets are destroyed.
When hijacking a ship, all bullets are destroyed.
Mid boss added. Note that he hates people getting close to him. He appears after 45 seconds.
Number keys 1 to 4 place the player inside a ship. These are debug options I've left in for fun.

The controls are:
Arrow Keys - Move
Shift - Dash (while in dot mode) or Shoot (while in Ship mode)
Control - Jump out of ship.

LINK IS HERE

I think this is starting to come together. Once the prototype yields a solid, playable mini-game (I'm shooting for one level) I can start production proper. I guess I'll need some decent graphics at that point.

Also, I personally really like the idea of allowing players to steal mid-bosses. But I'm worried that players will just mindlessly dash towards the mid-boss, so I made it so that the mid-boss has a special attack he uses when the player get's close to him. I think it may be a bit overboard however right now. Any thoughts on this?

Also, does dashing while in dot form make sense? Is it useful?

New version of Grand Theft Shmup! YAY! As this is a rapid prototype, new versions should be veru rapidly released.

Changes to v0.01a are:
Shump misspelling changed to Shmup. Thanks UncleSporky at www.platformers.net!
Score now resets to 0 after player is killed.
"Spider" enemy ship (The one that fires a bouncing shot and looks like an upside down "U") is now easier.
Touching an enemy while dashing kills it.
Pressing Control while in a ship no longer causes an overload attack, but instead just destroys the ship.

Credits:
PenguinSeph - Game Design, Programming (I used MMF1, but it's still kinda programming), "Art"
The maker of sfxr (I will find out who it is for the next version. I promise)

Link is here!