This prototype is basically a fangame of James Burton's Stardust. But rather than being a straight puzzle game, this is intended as "a puzzle game, without the thinking". dess once described suteF as a game where the player is in a perpetual state of semi-confusion, where all they can do is stumble forward through a meager set of possible moves, only ever partially understanding what's going on. This is the sort of counterintuitive anti-friendly design principle I am hoping to capture with this game.

Choose a level file when you start up.
You must guide the blue person to the blue goal, and then the red person to the red goal.

Left, right: move.
Space: trigger the block that you are standing on. Each block has a different effect when triggered.
Press R to restart. (You'll have to press it if you fall out of bounds.)

http://www.glorioustrainwrecks.com/files/DustPrototype.7z (Windows)
http://www.glorioustrainwrecks.com/files/DustPrototypeMac.7z (Mac OS X)

Hey, just wanted to tell you guys about this program I found called 3D Rad. Judging by the tutorial, it's easy to use. Who knows, I may make something in it in the next few days...

http://www.3drad.com/

This started out as basically a trainwrecky thing for a weekly themed creative jam my friends and I do (or used to do--it's kind of fizzled) a few months ago where the theme was "freefall." After a couple hours, I ended up liking what I was working on quite a bit, so I decided to spend some time polishing the movement and the level design.

I'd like whatever feedback I can get. I'm thinking it's going to be just a one-level game, meaning it's going to run all of about 3 or 4 minutes from start to finish at the longest. I'm debating about whether or not to insert a checkpoint or three.

(I intend to also implement an endless mode, either as an alternate gameplay mode or as a separate release.)

Here's the current version, which isn't yet a complete build (so when you get to the end, there's just endless space). I've made it in Game Maker, so it's a Windows executable.

Fall Free 12/10/2011 (24 MB)

Also, the file's kind of huge, because I've included three samples of the kind of music I'm thinking of using, since I'm also kindasorta hoping I might be able to find some musically inclined person who thinks they might enjoy composing an original track for the BGM! To change the music, press "1, "2," or "3" either at the title screen, or before you restart the level after you die.

Arrow keys to move. X to use your fall-dash power.

Thanks to anyone who checks this out!

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.

Wildcard is a pretty fun game that I first learned about by reading this review. I checked it out and had a lot of fun with it, although I found a fatal error near the end of the game (I think it had something to do with the ultimate sword? I'm not sure) and never picked it back up, because I'm a huge wuss. ANYWAY errors aside it's a pretty fun game, if a little generic. It's an RPGMaker game, but I'm pretty sure you don't need an RTP file to play it (at least, I didn't have one when I played it) but you might need to install a font patch, else all the text looks wonky. It's not really very trainwreck-y at all, but given that it used to be hosted on Geocities I think it could fall under GT's game preservation philosophy.

OH HELL YES

Lots of good stuff in this latest update! Try it out!

1. Project support! This is an important step to keeping all of the drawings for a particular game together.
2. ANSI animation editing! You can now create a second type of drawing, called a "sprite", which is a small animation. It's still a bit rough, but it's already buckets of fun.
3. Smiley faces! Because they work with SyncTERM, and I'm long past caring whether this stuff works with clients that aren't SyncTERM.
4. Some small usability improvements in the drawing selection lobby.

Work continues!

When I last made a MarMOTS post, I was working on starting to make my scripting language do useful stuff. Well, it quickly became apparent that in order to make my scripting language do anything interesting, I had to have entities on the screen to refer to. So I've got project support working now, and am currently building an ANSI sprite animation editor! This is going to be the biggest and coolest addition to MarMOTS in almost two years. I'm hoping to get something out next week, but we'll see.

On the scripting front, I have written a simple VM for the scripts to run on, and verified that, yes, my scripts actually run and do what they're supposed to. One of the interesting features of my scripting language is that it is intended to be LIVE, all of the time. The idea is that you can edit a script that is in the middle of running and the program will actually continue to function correctly, incorporating your changes immediately. One way that I'm able to do this is by stealing the notion of failed calculations from an obscure language called Icon. (Actually, reading that now, I may want to steal more ideas from it :) Basically, if you're editing a script and have a logic bug or even a syntax error, no big deal -- it's just a failed calculation, it gets logged, and your program continues to run. No game-killing exceptions, ever. I believe that it's much better for a designer to be able to see a failure happen, and have as much information as possible about the actual problem as it occurs during play, than to be told "the computer can see this will never work! You aren't allowed to run this program."

I have ambitions.

So now that Game Maker is $40 and Construct 2 will eventually be $65, I've found myself turning back to MarMOTS and wondering what it would take to get it into shape as a game-making tool.

My first focus has been getting my scripting language / editor into shape. I lump the two together because the scripting language, while textual, is never parsed from free text; instead, the user is edits the source tree directly using a friendly structured editor, with lots of autocomplete help, and in which it is literally impossible to forget a semicolon or a closing parenthesis. For power users, it should be as fast or faster to type in programs with this editor than with a text editor, and yet newbies will still be able to discover all of their options in a nicely readable self-describing English syntax.

So over the past couple of weeks I have torn apart my previous attempt at this language and rebuilt it. I've arrived at the point where I can type in any programs I like, and add features to the language without much effort. The UI is still pretty painful to use at this point, but that's mostly because I haven't focussed on improving the interaction at all besides making sure auto-complete is usable.

I was thinking I should maybe do like a screencast or something, but the scripts don't DO anything yet. I'm thinking that the next step will be to start integrating the scripting language with ANSI layouts that I draw in MarMOTS. I'm pretty excited to start hacking on that stuff! You should be too.