During a Twitter conversation about the current state of Glorious Trainwrecks, an idea suddenly dawned on me: if the site, as it is, is badly designed, and this is hurting site participation, why not just go ahead and do a rewrite?

While we could just upgrade to the latest Drupal, there are several reasons why that is a terrible idea:

- Drupal is written in PHP. PHP is a terrible language.
- Drupal has too much complexity, and this bleeds into both the user experience and site maintenance. A lot of Drupal's abstractions are aimed at trying to be useful for many different configurations, but makes managing all of them more confusing.
- Despite these abstractions, Drupal doesn't provide what we need out of the box. There's already a significant amount of hackery in this place to incorporate a list of registered games, and it took multiple attempts to get it working with events. This would have to be done all over again if we were to upgrade to a newer Drupal, and this is made harder by the fact that, again, PHP is a terrible language.

Instead, I would like to focus on creating what I'd like to call a "creative content system". This will be a CMS-like system where everyone can participate by default. While typical CMSs like Drupal allow for this, it seems like they are primarily aimed at things like organizational websites rather than open participation communities. This will be software that anyone can install on their web server, especially since SpindleyQ has always wanted something in the form of a "Glorious Trainwrecks kit" for other gamedev groups to set up and host their own Klik of the Month Klubs or whatever. However, I would also like to design this around Glorious Trainwrecks and its needs.

Additionally, when I refer to "creating content", I mean all kinds of media, including art, music, games, or whatever. Hence when I talk of functionality you'll see me refer to "creations" rather than, say, "games". I want to make something that artists working in other mediums can use, too.

For the sake of ease of use and cleanliness, I am going for a simpler design. I can always add more bells and whistles later, but this way we can start off on a clean slate. Here is what I currently have in mind:

- The main page will be the Activity Stream, even when browsing as a guest. This will be similar in function to the "Recent changes" page already on this site (for those who prefer "Recent posts", I might add a "new content only" toggle or something to that effect). Only here, it would be much richer, since it would provide image previews and a synopsis of each post inline. In fact, think of it as a combination of "Recent changes" and the Newest Games list currently in GT's sidebar, or a combination of a community hub and a social network (except not really). You will be able to filter by different types of content, or switch to an index list view for archive viewing purposes.
- All content is created in the form of a "Post". A Post may either be a "Communication" (which I need a better name for) which serves as a blog/journal post, a "Creation", or an "Event".
- A "Creation" can be media of any type that the site provides. For example, a site might choose to support both "Music" and "Game" type Creations, and the user would select which one to use. While I am not aiming for a very pluggable/customizable system for version 1.0, I would at least like to make the Creation types customizable.
- Events are displayed at the top of the main page, above the Activity Stream, to draw attention to upcoming and current Events. In the case of lots of Events, the system will select a few at random, and provide an "All Events" link to view the rest.
- Site staff can "pin" posts to the top of the Activity Stream for site announcements and the likes.
- All Posts can be assigned to one or more tags/categories. The site configuration can define one or more "categories" for each post type, which are like "official" tags that are always presented to the user during post creation.
- Users get basic profiles including username, avatar, homepage link, and a list of all of their posts.
- Users can also send private messages to one another.

Because I am aiming for a relatively simple system, there are some features that won't appear. Namely:

- There is no wiki, or at least there probably won't be a wiki in the initial version. If at all. I just think a lot of CMSs try to do everything and end up only doing a few of these things well. This project is not like that. I'm not even sure how a wiki would fit in with the user experience I have in mind.
- There are no forums. If you think about it, Communication (blog) posts are basically the same thing: a user can post something to start a topic, and assign it to a tag/category and it will show up if filtering activity by tag/category. Users can comment on it like one would reply to a forum topic. So really, I think it makes all the sense in the world to not have forums. It would just be pointless duplication.

The project itself will be a webapp written in Python. I think I should be able to handle it - I'll be using a "microframework" with extensions for things like SQLAlchemy for DB access (I kind of doubt this project will see any deployment on sites large enough to need something as scalable as a NoSQL-type DB), and OAuth (so that users can log in with Twitter).

Also, I really enjoy designing things and I think this is a pretty good design so far, but I'm worried the UX might be too radically different from what GT currently has. Also, I might have missed a thing or two. Please provide some feedback, if you can. Again, I want to base a lot of the design off of GT's needs, so it's important that I get to hear some opinions from other GTers. I do not currently have any UI mockups, but I'd like to make some soon so that I can better illustrate the design I'm going for.

One last thing: Since this is software that I don't intend to be limited exclusively to Glorious Trainwrecks, we'll have to think about other sites as well. GT has a super great community full of nice people, but not all communities are like this. Much of the design revolves around assuming good faith instead of expecting people to misbehave. I have been thinking of adding in admin-configurable limitations (such as each user only being able to host three events at a time, etc.) as well as the ability to remove EG. posting permissions from problematic users. Right now I feel like I'm trying to straddle the line between creating something aimed at super nice communities like GT vs increased adoption elsewhere in not-so-happy climates. Thoughts?

In order to make sense of how and when conditions are true and to use them to create the behaviors you want, it's good to know some of the most important ones. You'll find these under either the "Special" or "Storyboard Controls" categories when you go to create a new condition.

Always and Never

The simplest conditions are the ones that are either simply true or false: Always is always true, and Never is always false.

Always is extremely important as you need it for actions which should happen continuously. For example, you might always want the screen to scroll with your player character, or you might have a turret that should always point at its target. If you have your own custom movement system you might also want to keep objects moving. These are just a few examples of things which you would want to "always" happen, and for which using the "Always" condition is basically a requirement.

Note that Always only makes sense if you aren't placing it in an event with other conditions. In such cases, Always is unnecessary, because actions will repeat for as long as the conditions are true anyway.

Never is essentially the opposite of Always. Since Never is always false, and an event requires all its conditions to be true before it runs the actions, you might be wondering how the heck Never would ever be useful. Its use is not in running actions, but not running actions. More specifically, you can use Never to disable events for debugging purposes.

Start of frame/Start of level

"Start of frame" is only ever true once: at the very beginning of your level. Therefore, you can use it to perform any kind of setup you need. Common uses include playing music, making certain objects invisible (if you're on something older than MMF2), creating and/or positioning objects according to a set of rules, etc.

Only one action when event loops

An event's actions will keep happening every step of your game as long as the conditions are true, but what if you don't want that to happen? You add "Only one action when event loops" to the event. This condition is only true if the event's conditions were not true in the previous step.

Let's say you are making an arcade game where the player gets an extra life after reaching 50,000 points. Your first attempt at the conditions might look like this:

However, doing this will cause the game to flood the player with a constant stream of extra lives! Not what you want. Now let's add "Only one action when event loops":

This rewards the player with an extra life just once after obtaining enough points.

I should note that if the player's score somehow falls below 50,000 again, the player will become eligible for another extra life. If this isn't what you want, use "Run this event once" instead of "Only one action when event loops".

We will start off by jumping straight into the Event Editor, as that is the heart of Klik's true power, the place where you will spend most of your time designing your game's behaviors. For these next few articles, we will cover the basics you need to know to get the most out of the Event Editor.

In order to become a Klik Ace, you need ACE: Actions, Conditions, and Events. In the Event Editor, these are the building blocks that you use to describe your object behaviors. Understanding the role of each is key to understanding the Event Editor.

Actions are simply things that you can do in your game. Some examples of actions:

- Stop
- Destroy
- Create a new object
- Change animation sequence
- Add to the player's score
- Jump to the next level/frame

Conditions are bits of criteria. Some examples of conditions:

- Start of frame/start of level
- Player pressed Fire 1
- Two objects are overlapping each other
- An object is below a certain Y coordinate
- An animation has finished

Events are units that contain a set of Actions and Conditions. If the conditions for a given event are satisfied, the actions are performed.

Pictured: An event that causes the player to fire a bullet when pressing button 1, as long as there are less than three bullets in play.

Note that conditions actually have two functions. First, a condition may either be true or false. For example, if the player is holding button 1, then the condition "Repeat while Player pressed Fire 1" would be true. If the player's score is only 1000, then the condition "Player's score is greater than 2000" would be false.

An event's actions are only run if all of its conditions are true!

Second, a condition may limit which object(s) an action is applied to. Let's say you have an event with one condition: "Player pressed Fire 1". If we give this event a "Destroy Monster" action, it will destroy every single Monster in the level when you press button 1.

What if we replace that condition with "Collision between Bullet and Monster"? We will keep the "Destroy Monster" action. This time, when the condition is true, only the Monsters that have collided with any Bullets will be destroyed.

Typically, conditions serve to eliminate possible objects. That is, you use conditions to only apply actions to certain objects, and each additional limiting condition further reduces which objects targeted by the actions. There are exceptions, of course. Take the "Pick an object at random" condition. Its first use will eliminate all objects of a given type except for one that has been chosen at random. What happens if you add multiple copies of this condition? Now the actions apply to more objects! If you have "Pick an object at random" three times in an event, three objects will be picked (assuming there are three - if there are less than three, only that many will be picked).

Feel free to play around with different conditions and actions! Next, we will be covering the use of a few specific basic but important conditions.

I will start off by saying that Tips and Kliks is mostly intended to be aimed at novice to intermediate Klikkers. Tutorials for absolute beginners are important, but this is not one of them. We do have a good beginner's tutorial on this site already - see the Learning KNP FAQ.

I'd like to take the time to mention the Step-thru Editor because it's a novel concept, and also an important one - I was using it before I even touched the Event Editor.

When you use the Step-thru Editor, your game will run until certain things happen, and then pause to bring up a dialog asking you what to do next, like this:

You'll see a row of icons. By clicking on one of these, you can select an action you want the game to take in response.

The capabilities of the Step-thru Editor are rather limited, especially when it comes to the number of conditions you can write actions for:

- An object leaves or enters the playfield on the left, right, top, or bottom edge.
- An object collides with another object.
- An object collides with the background.
- All objects of one type are destroyed.
- A player presses one of the fire buttons.
- A player loses all of their lives.
- A certain amount of time has passed (accessed by pressing the Esc key).

Additionally, if you are using Klik & Play, you may only perform actions on the object(s) that triggered the event in question, and you are limited to these four actions:

- Bounce
- Wrap around playfield
- Shoot another object
- Destroy

I don't think these limitations are necessarily a bad thing. Because only a small number of the available conditions and actions are exposed, it is much easier for new users to grasp the basics of how the program works. Of course, you can't do anything advanced with this, but that's not really the point - the Event Editor covers those bases.

Because these Tips and Kliks will mostly focus on working within the Event Editor, I would strongly suggest you tinker around with the Step-thru Editor first if you're still unfamiliar with Klik. Otherwise you won't find these articles very useful.

And have fun with Step-thru! I know I did!

(Note: The Step-thru Editor was removed since MMF2.)

Hi, all! Now that I've finished my Secret Santa game and the new year is fast approaching, I would like to announce a new series of tutorials and articles called "Tips and Kliks". I've seen quite a few people here picking up on Klik tools lately, and I think that's great! These tools actually have a lot to offer - even Klik & Play is more powerful than it seems at first glance!

Why am I doing this series? After all I've kind of sworn off of Klik and I can write code in Lua, Java, C++! Well, before I was using any traditional programming language I used Klik for all my games (and a few "apps"). Using Klik to try out new gameplay ideas helped me gain familiarity with programming, and working around limitations by writing my own behaviors trained me to think critically. It is my hope that with this series I can help others do the same.

I plan to do a new article twice a week. I most likely won't provide game files for these articles (unless it's requested), because everyone is on different tools and sometimes things change between programs. I will provide plenty of images, however, and if you need help feel free to ask.

Scope

Focus will mainly be on the earlier Klik products (KnP/TGF1), but applicable to the later programs.

- (Re)familiarization with Klik basics (objects, built-in movements, editors, etc.)
- Basics of creating your own behaviors
- Some applications of custom behaviors, such as custom movements
- Other tips and tricks

One day I hope to be able to make super happy and queer music.

I really want to start a tutorial series on Klik tips and tricks that applies to a broad range of Klik products (though primarily targeting the older products). I'd like to cover concepts in bite-sized pieces to serve as an introduction to the building blocks used to create more complicated behaviors in Klik, as well as provide documentation on a number of useful tricks to give aspiring Klikkers greater control over their creations. I'd also like to provide a section on Klik backward compatibility to document behavior changes going from KNP to TGF1 (and perhaps later tools as well?) so that KNP users can make their games more forward compatible while users of newer products can fix existing KNP games to run on newer systems.

I just see a lot of people getting into Klik and creating new and interesting things but sometimes aren't sure how to do advanced things. I would like to help those people arm themselves with Klik knowledge.

IT BEGINS.

So I read a small portion of "Programming in Lua", which starts out easy enough and then becomes more and more bullshit the further you read into it. So I started skipping chapters, and then eventually decided to look elsewhere for information on OOP in Lua.

They recommended the use of metatables and goofy complicated things just to get stuff like inheritance and encapsulation working. Not my method! Relevant code is here. Any experienced Lua programmers are welcome to berate me on how my method is "too simple" and "doesn't use metatables" and stuff like that.

Next, I shall make a basic game in Love2D with this OOP method. I already have a framework in the works.

So I'm more or less fed up with MMF2. Here's why:

1. Slowness. Just try getting more than two-thousand objects interacting with each other at once. It shouldn't slow down on any modern processor, but it does.
2. Excessive use of mouse movement and dialog windows to create anything. I swear I'm developing wrist pain from moving the mouse between all these buttons just to perform simple tasks. And a separate dialog window for each individual parameter to an action? Really?!
3. Lack of editor or runtime on any PC operating system that isn't Windows (I could pay extra for that upcoming Anaconda runtime but why should I have to pay to fix something that's broken in the product I already paid for, which should have been fixed for free? Not to mention that this only covers the runtime, not the editor, and looks like it's being written by someone who's never used Linux before).
4. Absolutely ludicrous method of handling for loops and anything else related to algorithms that doesn't follow a linear code path (this is also a huge performance bottleneck).
5. Use of proprietary binary formats for data storage, which requires using an arbitrary sprite editor to "proxy" images into the game, even if I just want to use GIMP or grab random images off of the Internet or whatever, among other things. Not only that, but because everything is in one file, it works poorly with version control and collaborative services.

So seeing as I understand programming (I can probably write way better C++ code than most of my colleagues can), and I'm not on Windows anymore, it's honestly kind of bizarre that I'm still using something comparable to tinker toys.

Rant over. Time to talk about more productive things.

I want to write something that will help me do game prototyping and Trainwrecking without the pain associated with existing solutions. It will be something of my design, crafted toward my expectations for something usable for such a purpose. Now, I understand that I am starting to sound like the crazy, egomanic Linus Torvalds, Eric S. Raymond, or {insert bearded idealist here} of Glorious Trainwrecks, but so be it.

Here's what I'm planning for the design, which will either be totally awesome or really bizarre, depending on your tastes:

1. Runtime and per-game code built on top of Lua and Love2D. I still have to research this a bit further (actually, I need to read through "Programming in Lua" - just started today), so I might not end up using these. However, I do think they're very good candidates.
2. Game data represented as a filesystem. Hierarchical data is represented by folders on the hard disk. Image files are plain .PNG files or whatever. This means you can drag a picture of a dancing cat you found on the Internet right into a new folder in your game directory and have it immediately available for use inside your game. No import step!
3. Textual file formats for data. Unless there's a good reason for it being binary (EG. it's a bitmap or a sound resource), it should be editable in a text editor.
4. GUI editor for game data such as scenes, object metadata, the likes. Uses an Eclipse-esque Workspace system for managing documents except that it is directly coupled with the filesystem. You point the editor to the game's root directory and all your files will show up, ready for editing. Changes on the filesystem (EG. in an outside editor) will be immediately reflected inside the editor. Written in Qt because Qt is sexiness.
5. Cross-platform runtime package for Windows, OS X, and Linux in one download, so no setup time, no installing extra crap, no having to download some extra client or resort to anything like Wine. But since I lack a Mac (hee hee, I rhymed), someone will need to show me how to package for OS X.

Basically, the design philosophies behind this are more or less opposite to those in, say, MarMOTS (not to say that it's bad, but I don't think it'd be useful for quick and fun prototyping, personally). I want to design something that is minimalistic yet modern and a breeze to use (once you learn how to use it), as opposed to something more nostalgic. Possibly something revolutionary. You know, like Git! ...Except that I sort of doubt I'll be able to achieve that last bit, but hey, I suppose one can dream.

Edit: I suppose this is somewhat based off of KlikPunk, except that I intend for an implemented runtime and something that doesn't require Adobe AIR to run or Windows to develop with. Also, editing scenes will be a lot like KlikPunk but you'll be doing more than just assigning positions of items. This is data that will go hand-in-hand with other data formats to produce the game.