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.

Two days ago I had an incredible idea for a hilarious, but easy to make game. I've spent some time collecting the basic sources for it, ranging from sounds to art, to ideas, to "implementation/translation". There's just one problem with this idea. It is likely to be highly controversial. It's a parody of a well known game series, but with a strong message, that is likely to upset a fairly large group of people. The presentation is pure Stephen Colbert, where I present ideas in an accurate, but self-contradictory manner.

The game would not be fun, for the most part. Much of the humor would come from this fact. But it would be interesting, and informative.

I sometimes wish Glorious Trainwrecks had private messaging. I'd like to ask SpindleyQ if he feels it's appropriate or not. If I find him on IRC, I'll ask him there. If he thinks it would be too much hassle for Glorious Trainwrecks, or not in the spirit of the site, I'll take the idea in another direction: either as a Shockwave Flash game submitted somewhere else, or as an animation on YouTube.

My first instinct was to make the game in Klik & Play, simply because I've been getting to grips with the system again, and I thought it would be a fun experiment. But the topic may be too serious for the light-hearted nature of our community.

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.