Just a game about Edgar. What are you looking at?

Dear Diary,

I hesitate to tell you that today I needlessly used up a couple sheets of paper trying to derive a general transformation from (x,y) coordinates to rotational coordinates. It sure made for an odd feeling. I'm in my 30s -- long out of school -- and couldn't remember the word for 'trigonometry.' I assume stubbornness kept me from trying to look it up. Or maybe I thought this would be a fun way to spend an early Saturday morning?

I did, however, remember that A squared plus B squared equals C squared, though Mr. P's theorem turned out to be a red herring (half a page worth of scribbles down the drain! You should be happy you're not made of paper, dear Diary, else I might have been tempted to scribble those notes in you).

What did the trick was punching in test cases into a calculator until I remembered how sine, cosine, tangent, and their variants work (ArcTangent I don't remember ever learning about, but it's brilliant!), and drawing up test cases until I realized what I was actually trying to do was to rotate the coordinate system through a certain angle (which would change over time based on position and velocity).

It turns out it works like this (for future reference, or in case you're interested, my bestest bookish friend):

Rotational Speed component = Sin(Angle-of-Motion - Position's-Angle-from-origin) * Speed-of-motion
Centripetal Speed component = Cos(Angle-of-Motion - Position's-Angle-from-origin) * Speed-of-motion

And that Angle-of-Motion is the ArcTan(vertical-speed-component/horizontal-speed-component)
And that Angle-from-origin is the ArcTan(vertical-position/horizontal-position)

Diary, am I proud of these accomplishments? Yes, of course. I only tell you this so you will love me more.

Yours, as always,
nobody.

p.s. - Why no superscript and subscript tags? This entry could have been so much spiffier.

This is my first Game programing.
Im just learning how to create games in java.

Dear Diary,

I'm no spambot, but I'll likely be shy for a bit.

Yours,
nobody.

p.s. - You are my best friend.

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.