So I've been interested in making some platformers in LÖVE / Love2d for a while, but haven't produced much of anything so far, until this month. To get the ball rolling and reduce procrastination, I started writing more: jotting notes on paper, keeping a personal diary, and writing up public-facing devlogs with weekly goals. (Warning: unfocused ramblings about platformers). I found that writing about ZZT here helped a lot in the summer.

It is my intention to get something playable out the door between now and the end of the year. It would be a mistake to take on something larger than I can realistically pull off, so I've put my current ideas on the backburner, and I'm setting a goal to make something small but wholly realized in about two weeks. This would help me find issues in my current codebase, get familiar with packaging LÖVE games, and also give me something tangible for my efforts.

I wrote up an idea that has been in the back of my mind for a while, started a simple XM soundtrack, and outlined how gameplay would work yesterday. But I'm realizing today that I won't have the energy to pull it off in two weeks. So back into the cabinet that one goes. Started on another idea, but upon review, its workload requirements are also too high for this timeframe. Think smaller, damn it!

I need to take a few steps back. There are platformers with very little to them that are still very enjoyable. I'll post some more once I've got something that's scaled appropriately.

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.