Wordrescue and I had a plan to make an entry for the Tigsource.com Cockpit Compo, but a combination of forgetting about the compo until the day before the end of the extended deadline, and not having any particularly concrete ideas resulted in a game about being bored while playing a Virtual Reality Studio game. Behold the amazing combination of my uninspired 3D city and WordRescue's clever pixelart cockpit:

The mouse-only controls are in red around the cockpit, placed in unintuitive and annoying locations The meter on the left measures how bored and upset with the game you're becoming. First time I've ever got one of those status bars to work in a 3D Construction Kit game!

In an effort to avoid dying of boredom, you can try to fight a gigantic enemy crab (shown glitching during its space-invaders attack pattern). Even targeting his weak point for massive damage does little to stop the fatal tedium.

Inevitably the boredom meter maxes out, and you die.

Other interesting facts: even though I set the initial conditions and default border, the stand-alone executable doesn't load correctly until you reset the game at least once. We might try to work on it again later, but not unless we get a good idea of what it should be about.

This is my first attempt at a community project, so let me know which parts are good, which are bad, etc...

Presenting the first GloriousTrainwrecks.com Community Chainwreck! A chainwreck is a game built by multiple members using the same template. Each level (or should I say "railway car") of the chainwreck is linked in a consistent way to the preceding and proceeding screen. The objective of the participant is to create a fun and challenging obstacle to the player's progress from the current screen to the other screens.

For this specific chainwreck, participants need to position two objects in their level: The goal and the exit. Everything is set up so that the goals will show up in 5 randomly chosen levels. Once the 5 goals are collected, the exit will appear in one of the levels. To make your level difficult, obstruct the player's path, or reset the level (death). The template consists of the existing counters and objects, and the first 10 events. These shouldn't be deleted. Don't use player values (score and lives) as these values are used extensively by the template.

The file has two copies of the template, so you can see how the game transitions between levels. One template is using a platform movement for the player avatar, while the other is using the 8-directional movement. You are not limited to these two movements! BE CREATIVE! PM your completed levels to me, and I'll assemble them all together in a chaotic manner. The current deadline for submissions is the day before the next KOTM. Feel free to submit more than one level, but remember you're not limited to 2 hours or anything.

"Eddie the Engineer's traingame is off the tracks! Track down the 5 missing gears, before Eddie loses his mind completely!"

Merry Kristmas, everybody! This is my Christmas game for you.

Original game idea, and line-art for the title screen by StorybookWeaver, coming-soon game box version by WordRescue (two good friends of mine). I'm pretty proud of this game. It was a really fun exercise in simplified game design, and pixel-art. Personally, I think the main title screen turned out beautifully.

WordRescue will be by in a bit with the "commercial box" for the game. Consider this the shareware version.

After successfully finishing Tek Demo, I've been thinking about other aspects of KnP that haven't been fully explored. I've never made use of active object internal flags. What does "spread a number" do to alterable values? The event editor has its own options panel? But one thing really hit me as being full of potential. Klik & Play had support for a very old animation format: FLC/FLI. No sound, palletized, somewhat dodegy playback speed, and very poor compression. That, and no modern video converters seem to support the format. But a while ago, I found this old DOS command-line converter called DTA. Running it under dosbox, I could convert a directory of tga or pcx files into a knp compatible flc video. And just now I've finished the conversion path, from shooting video, to jpg sequence, to tga sequence, to fli animation.

The filesizes are awful. What started out as an 882kb avi lasting maybe two seconds turns into a 4.5MB(!) fli animation with no sound. But I have the batch processing steps down now. And my planned idea won't take more than maybe 8 videos to do, each lasting about two seconds, at double the tested video dimensions, and half the framerate. I'm looking at about 64MB of fli video, plus whatever filesize the actual GAME part of this idea clocks in at. I think this could end up being very, very funny indeed.

My first step is going to be shooting video, of course. And dealing with the difficulty of convincing friends that they desperately want to be the stars of this overwhelmingly foolish idea.

KnP FMV, here we come!

Let me repeat that: TEK DEMO is the full game. (Not a demo)

You are Tek Demo, on a quest to find the missing gems! Marvel at the lush realistic graphics, and unbelievable advanced special effects! Featuring no less than three title screens, Tek Demo is my most ambitious KnP trainwreck to date. By my records, the first version of this game's engine is over 8 YEARS OLD, and was never released online. After hearing about Glorious Trainwrecks on Tigsource (which I heard about for... other reasons) I knew I had to finally complete a game using this engine/trick/technique/whatever. So this is my gift to you, internet. A little bit of knowledge for an obsolete game maker nobody uses anymore. I hope you like it!

note: If the full version starts acting weird at some point, try the lite version. It has less data, which might avoid the collision detection freezing up.

My greatest KliK project is nearing an end: one way or another. Every which way I seem to advance in this project, the physical walls of the ancient KnP engine seem to close in. Adding a score counter to the game now causes the collision detection engine to go haywire after a few minutes of play. Adding even one active object to the play field maxes out the object availability, and ruins my environment engine integrity. Changing the layout of the level by moving one more object into the initial render window drops out the overlay layer.

I'm going to try and finish this thing this weekend. I may have to sacrifice a UI in order to keep the game stable. I'm on version 14 now, with each incremental update warranting a separate save, in order to avoid game corruption. Much like "A.M.O.S.D.", I'm nearing an impasse. Will I be able to surmount it? Stay tuned!

I've been in a kick of doing strange things with KnP lately. I'm working on a 2vs2 stealth action game (that requires a large piece of cardboard to enforce split screen exclusivity) and I'm probably going to finish up that HUGE KNP TECHNOLOGY BREAKTHROUGH that I've been none-too-subtly alluding to during nearly every single KOTM. But what I have here today is not that breakthrough, but rather something incredibly impractical in KnP, done for the heck of it!

I had recently seen a simple demonstration of the new version of flash drawing an isometric voxel landscape. Since I've never done anyting with voxels before, it struck me as to how simple it really was. After the idea sat in my head for a while, I decided to try the effect myself. On a whim I decided to do it in KnP. I showed it to someone once I got it to render a single static landscape. They helpfully suggested I make a flightsim. So a few events later I had a scrolling isometric voxel landscape flightsim in klik! Since it hits the active object limit almost from the start, it's a little on the small size. Press fire to keep the joust-like plane aloft! Watch out for clouds, their cold air will stall your plane!

Just when you thought I wasn't going to be updating anymore, a new update comes right out of nowhere!

A while ago I read an interesting article about the indie games scene, and the creation of what they referred to as "a new genre of game" that had arisen entirely due to the efforts of independent developers. While I think it can trace its roots to some rather big budget games first, it is an interesting notion: The origin of the time manipulation game genre. While it probably traces directly to the Prince of Persia commercial title "The Sands of Time", the concept has evolved a fair bit past simply rewinding time, fast forwarding time, pausing time, or perhaps the real father of the genre, bullet time. Now games like Cursor 10 and The Misadventures of P.B. Winterbottom have multiple timelines: parallel, intersecting, reversed, accelerated, and slowed all together. It's a very interesting concept, allowing for a lot of creativity on the part of the player, as to how the recorded movements are arranged or manipulated.

Which brings me to tonight's topic: Recording and playing back motion in KnP. The mechanic is something new, but that doesn't mean you can't make it in something old. My first thought on this was a description I read once of sending information between multiplayer game clients. It read something like this: "You don't just send the current location of all the players, you also send their direction and velocity. That way the computer can fill in the space between updates by moving the character according to the most recently sampled velocity and location" While taking a look at the path motion in KnP, it looked a lot like the principle from the motion sampling for multiplayer games I'd read about. But there was no way to manipulate a path object during a game, I saw a way to recreate it. If I could draw a path of objects, and have another object read them one at a time, I could record and play back motions.

Using objects for path nodes was necessary because KnP has no support for arrays of any dimensions (except 0!). But I had to make each object numbered, and store a speed and direction. I finally decided I didn't need to store a direction, since that would be taken care of by the position of the next node in the path. So I used a simple trick to number each objects alterable value A immediately after creation, along with storing the recorded object's current speed. Quickly I had a path of numbered objects with stored speeds. It was just a matter of waiting 5 seconds, and adding an object that would start reading at the beginning of the path, changing its speed as it read. The following object very nearly matched the motion of the recording object, with little difficulty or error.

I chose to destroy the path as it was read, but it would be easy to reuse the path as in TMOPBW, or reverse along the path like in sands of time. Or even record multiple paths, by setting the alterable value C!

Attached is the result of my experimenting. The first stage uses the mouse, which is capable of achieving speeds in excess of the KnP maximum 100, so it's not perfect. The second stage records the movement of a platform movement object, with one-way collision between the player and the echo. Press SPACEBAR to switch between the examples.

(It is important to note that this technique is better than constantly creating objects, and repositioning the trailing object at the oldest one. This trick is much smoother by simulating interpolation between points by the recorded velocity. Also, this technique allows for more complex timeline manipulation that this short example file demonstrates)

I have an incredibly good excuse to not update this week, but I'm going to go through with an update anyway. It's going to be short.

Last week I got a comment linking me to the KnP tips & tricks thread here on Glorious Trainwrecks. One of the last posts in that thread was about making an object turn towards another object or direction. I remembered asking that very question of the KliK Kommunity a long time ago, and receiving almost the exact same answer: later Clickteam products have the direction calculator, which solves the problem entirely.

Not content with this, I decided to finally solve that problem in KnP. I got out some paper, sketched out the problem, and found a simple solution. I knew there were 4 situations. The first two were obvious: If the target angle is greater than the current angle, add to current angle (and vice versa). The second two were difficult. Under what situation should you subtract to get a larger number, or add to get a smaller number? What was the difference between moving from 12 to 20, and 4 to 28? The difference was, unsurprisingly, the difference. Once the absolute value of the distance between current and target grew greater than half the circle, it made more sense to loop around 0 instead. A bit of figuring, and voila! Turn Towards accomplished in KnP.

Note that this technique alone only works for one object, not a swarm of objects, because direction retrieval doesn't know which object pair to select from and give to. But that's a whole 'nother article. "Object selection" is one of the most confusing aspects of KnP event writing. Sometime I'll talk about that in greater detail. But for now, here is an example of a basic turn towards effect. Enjoy!

Welcome to part 2 in our ongoing series of weekly updates on my experiments with my old friend, Klik & Play. Last week I discussed linked/paired object chains, and their potential application to swing simulations. While I considered using this week's entry for a further discussion on pairing or the advantages of wait-based simulation, I decided to talk a bit about one of the most overlooked object movements in KnP: The Platform Movement.

The Platform Movement is generally looked down upon. It doesn't function well with sprite animations of irregular height and hotspot combinations, landing a jump zeros horizontal momentum, its rudimentary inertia simulation mirrors momentum when the player tries to switch directions, and the wall jumping bug is well known. But despite all this, the built-in platform movement has great potential.

If you've every tried to make a two-player game with the platform movement, I'm sure you've noticed that the "bounce" condition when applied between two platform movement objects treats the slower/unmoving player as a wall. But a simple trick can change that dynamic. One of my recent experiments was to try transference of inertia between platform objects of different speeds. It's simple. Three events. The first tests collision, and object A moving faster than B. If A is faster, B takes its direction, and both object swap speed. The second tests collision, and object B moving faster than A. If B is faster, A takes B's direction, and both objects swap speed. The third event simply tests collision, and results in a bounce. The effect of this (with tweaking) is the ability to unexpectedly shove the other player off a platform, or into a trap.

But the greatest potential I found came from not using the platform movement as a player movement. Set a number of these object to control by an imaginary player 2, and lock player 2 input at the start of a level. When two of the same collide (from being shoved by a player object), "switch position with another object" and the two appear to transfer inertia from horizontal collisions! I've found a few other tricks with locked platformer objects, but I'll probably save them for the next KOTM. It's coming up in about 11 days, I think?

edit1: fixed a few typing errors. Original post was written under time constraints.