Here's my entry to the 2014 speedhack.

E'th

{"name":"608630","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/4\/54dafc9207ba595a5655a58cfefa8172.png","w":1206,"h":725,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/4\/54dafc9207ba595a5655a58cfefa8172"}
{"name":"608631","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/e\/cef42af64454b4eeb8273804952a065b.png","w":1206,"h":725,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/e\/cef42af64454b4eeb8273804952a065b"}

Blog.

Competition version

Source.
Windows binary (3 MiB) (now should work with WinXP).
Linux 64-bit binary (1.7 MiB).

Post-competition fixes (fixes the fuel bug)

Source.
Windows binary (3 MiB)(now should work with WinXP).
Linux 64-bit binary (1.7 MiB).

Start with the 'BETH' mission set, as it's a mini-tutorial. 'BRADFORD' is in principle doable, 'IRA' might be impossible. Check out options.cfg file if you find fullscreen/music to be objectionable.

It's actually not too bad to compile this from source (as long as you get everything at the revisions mentioned in the Readme) if you have some time to kill... either way, I'll make some static Linux binaries tomorrow.

If anybody observes this working on WinXP, please tell me, as I've went through some pains to patch the Rust runtime just for you .

Thanks to Matthew for hosting the event..

Uh?
{"name":"608635","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/b\/fbcd1ab99c91ba20ae8861d2bbe44ab2.png","w":413,"h":165,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/b\/fbcd1ab99c91ba20ae8861d2bbe44ab2"}

The folder and file is there.

Gosh darn it, I keep forgetting that the audio addon dynamically loads some libraries! Seems like a nice feature, but nightmarish for getting the distribution right. I've updated the download with the missing files.

Glad I got the dialog addon working .

Don't we have a cmake option to disable the dynamic loading?

Wouldn't do me much good, as I'd have to remember to turn it on.

Anyway, I just created a 64 bit Linux binary with statically linked Allegro (see OP). I had to fix a small bug in RustAllegro, but the game code is unaffected.

I thought that compiling an universal Linux binary was 100% impossible. I tried on xubuntu and I get:

task '<unnamed>' failed at 'Could not init audio addon', /home/siege/src/rust/src/libstd/option.rs:167

Why am I seeing that directory?

{"name":"608645","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/b\/5b05a00e86335bd4934f5ea383b4e553.png","w":483,"h":179,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/b\/5b05a00e86335bd4934f5ea383b4e553"}

Oh BTW I played your game on Windows, it works perfectly there. I was just curios about this, I wanted to know if it could run out of the box on Linux, I'm interested in doing something like this with my game.

I'm playing E'th right now and its pretty cool. I'm on the level with 4 stars in a diamond and 4 ships around them and I don't have enough fuel to reach both sides. It's really hard to break out of the center with out using fuel or only slingshoting it around a star, but that's hard because of the large centralized gravity well the four stars provide. So far I've bought a better camera and a fuel tank and that's all I could afford.

Screenie :

It was on Bradford mission.

Good game SiegeLord

Oh damn... there's a bug when you reset the mission, all your bonus fuel is gone... I suppose if you're awesome you could do everything on the first try, but this sort of makes fuel upgrades pointless for the rest of us... That said... it is possible to win that mission with just camera upgrades (which are unaffected by the bug).

It's not too bad (I compiled on a Debian Stable VM), but clearly it needs some testing... (it did work on my Ubuntu). I'm not sure why it fails to init the audio addon .

The failure messages take into account the directory where the file was built... same thing happens with debug info.

This is cool! I took care of 'BETH' pretty easily, but can only manage the first level of IRA!

I get this message on windows xp

{"name":"608650","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/b\/0bb2e2015b27f927a02eacaf7f7d93ad.jpg","w":1024,"h":600,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/b\/0bb2e2015b27f927a02eacaf7f7d93ad"}

I got this with the patched 64 bit linux binary

pepsi@fractal:~/EthLinBin 08:29 PM $ eth
eth: error while loading shared libraries: libdumb.so.1: cannot open shared object file: No such file or directory

That's... new to me. I'll investigate.

Need to install DUMB . There should be a package for it in most distributions, and the website for it is here: http://dumb.sourceforge.net/.

Can't be bothered. Another entry requires D, which I won't bother with either. I'm lazy.

You wouldn't be able to compile it without DUMB even if it was in C/C++ .

EDIT: allegro.cc's having trouble with attachments at the moment, so I can't link to it (although try this post's paperclip icon), but I think I have fixed the WinXP issue once and for all.

Arthur, you should consider installing DUMB regardless, as DUMB is awesome.

I get the same audio init error as AMCerasoli (running Debian Stable).

I always turn off in-game music, if possible. It's distracting. OTOH, if I did want to listen to music while playing a game, I'd rather play my own choices with vlc or whatever.

I remember downloading and installing the Quake I shareware demo so many years ago, and Led Zeppelins "Houses of the Holy" was in the cd drive, and I thought "Hot damn this game has some good music in it!" Until I wondered why it was so familiar...

If that's true, then you're missing out! Sometimes--not all the time but sometimes--a soundtrack brings the game to an entirely different level.

I do appreciate the option to turn off in-game music, though, particularly with games that treat their music as an afterthought (as opposed to an integral part of the experience).

Yeah, something's wonky with the audio addon, I think. It really shouldn't be failing... I'll investigate later today.

EDIT: What's happening is that PulseAudio is failing, for some reason. I could enable ALSA, but that introduces massive lag which sort of defeats the purpose of having sound in the first place...

Do other Allegro games/examples work with sound on your systems?

We may have uncovered something, as I don't even have Pulse on my system. A lot of people don't these days. It's unnecessary and has been known to cause all sorts of conflict issues.

The Allegro examples (and other SpeedHack entries with sound, including mine) work fine. I tried ex_audio_simple using sound effects from E'th.

Is there a collection examples specific to the D bindings?

Explain further please.

ALSA should have less lag than PA. Since PA uses ALSA underneath.

That'd explain it, as I only configured my Allegro to have OSS and PA.

I'm just relaying what I observed... maybe when Allegro asks for ALSA on the systems I tested, it instead gets the PA ALSA emulation.

Still, this suggests that on systems without PA ALSA might be tolerable... I've updated the binaries to also have the ALSA backend enabled.

Indeed you did! It works perfectly now. Awesome game! I'm really liking the balance between careful planning and fast-twitch reaction.

Let's see you monkeys beat my 84% fuel record on Bradford 3.

WHAT!?!? How!?

100% pure luck.

Edit: Just got 86%. I'll make a vid tomorrow.

Grrr...man, this is damn addictive. You've done the physics so well that I'm actually getting better, rather than just pure luck each time, which is keeping me hooked, determined to beat IRA!! The last time I was this sucked in by simple elegance was 'Thrust II' on the Amstrad CPC 464! Me and my older brother spent years trying to beat that game....maybe I should send him this!

Great game, so simple but the physics are strangely addictive to me...I love it!

Problem
$ ./eth
>error while loading shared libraries: libdumb.so.1:
>cannot open shared object file: No
>such file or directory

Solution...
$ ldd eth | grep dumb
>libdumb.so.1 => not found

$ whereis libdumb.so
>libdumb: /lib64/libdumb.so /usr/lib64/libdumb.so

$ cp /lib64/libdumb.so where/eth/game/executable/is

$ mv libdumb.so libdumb.so.1

Might I suggest

$ln -s libdumb.so.1 libdumb.so

so the original will still be there.

Linking files... Brilliant! I just learned something new today.

I've been playing this one quite a bit and agree with Dizzy. E'th is a great game, and the physics are strangely addictive! I'll have more thorough impressions later.

I encountered the following error earlier today. Any ideas?

If you know how to reproduce it (and since you're on linux) you could do:

RUST_BACKTRACE=1 ./eth

Or run it in gdb and break on rust_fail.

I don't know how to reproduce it, but I'll have the backtrace if it comes up again.

Ira 4 is a doozy. Who's beaten it?

Nice game! I like the graphics and the idea, and I thought it was particularly fun when I bounced off the outside edge.

There are a couple of things that spoilt it a bit for me:

• The menu resets to BETH every time. It's more likely I'm going to want to try the same game as last time again.

• Once I've started a level, there seems to be no way to go back and choose an upgrade; and I won't know whether I need an upgrade, and which one, until I've gone into the level, by which time it's too late. You could offer a 'go back and buy an upgrade' key at the same time you offer the 'R' key perhaps.

I have a feeling you'd have fixed those things given just slightly more time though!

Some ideas for future versions or extra modes:

• Model conservation of potential and kinetic energy. Judging by some of the slingshots that happened to me, you're definitely not doing this at the moment

• Relativistic phenomena, such as time distortion, or spinning objects with frame dragging... (if you can map that to 2D convincingly)

How do you find Rust?

This is a consequence of the buggy integrator I used (it constantly adds energy into the system at a slow rate) and a bug with how I deal with black holes. Physical simulations are tricky to get right... kind of embarrassed that I didn't .

I'm thinking of maybe working on this game in the future some more, since it didn't come out terribly bad... will definitely get this working perfectly, since it's a solved problem.

It's very much a nanny-state of a language, which implies that you need to play by its rules if you want to get anything done... I've been using it for nearly a year now, so I know what not to do, but there were was some fighting involved during the making of this game. Still, everything around it seems well put together. One big problem with these new languages is their Windows support, but it's good enough here that I basically had no trouble producing the windows binary (with the exception of the WinXP stuff). It does change sort of rapidly, which bit me during this competition... I had to spend some time handling language changes, hah!

That article had me at e191203e613b2c32753a18ea6bfc5696.png

Here's my full review. (I noticed Bruce giving in-depth impressions for everyone. It felt good to get my feedback, so I'm basically just doing the same for as many participants as I can.)

Before saying anything, I just wanted to let SiegeLord know that this year's SpeedHack would not have been as great an experience without him. From offering help with submissions, to providing all those binaries, to giving useful feedback, I can say with confidence that all participants appreciate you having been involved. Thank you.

It therefore seems fitting that E'th implements this year's rules beautifully, thoroughly, and without exception. As a participant, I enjoyed playing a game that took those five parameters we all had to deal with and grew off of them, as opposed to treating them as obligations. This was my first SpeedHack, but E'th set a standard that I hope to aspire to in the next competition. Bravo.

Incidentally, I would enjoy hearing a bit about E'th's conception. How did you deal with the rules initially?

The game's atmosphere is spot-on. The music gets you pumped, and the sound--particularly the death effect--hits with satisfying punch. (I almost never press "R," even when heading toward certain death, just because I want to hear that little planet vaporize like a celestial balloon.)

This satisfying death effect calls to mind Gradius, come to think of it. Thankfully, dying in E'th is more forgiving.

As with a number of entries, the balance between cerebral planning and fast action works well. I originally considered E'th's balance to veer more towards action. After venturing into the later levels, however, planning begins to take center stage. I have yet to beat the game but hope to eventually. To have delivered such a deep experience in such a short development period is remarkable in and of itself.

Upgrade options are well chosen, the basic premise is charming, and the physics are fun.

As for constructive criticism, I echo previous sentiments: The timing of character upgrades may have worked better with some tweaking. Menus are one option. After dying is another. I also wonder how controls would have worked with slightly more power in the planet's thrusters, as there are times when I felt powerless in controlling my little planet's destiny.

Lastly, full-screen mode seems to result in an unstretched window with a black border. It would have been nice to be able to stretch those pixels and sit back in a comfy chair at a distance with a wireless keyboard.

All in all, thank you for sharing such a cool game. I know I had fun.

The original idea was actually to make a multiple-landing spot lander game. The inversion of the planet/lander immediately came to mind, which meant that the original idea involved having your planet land on space stations. The entire game field was to have downward gravity and the bottom of the screen was going to be the sun's surface. I think I moved away from that idea because once you ran of fuel, you were doomed and I imagined that'd make the game too unplayable. Additionally, lander can be a hard enough game with just a single landing spot, performing several landings would have been rough. Lastly, a part of the idea involved picking up packages and delivering them to the different space stations.

At some point, I decided that it might be fun to make something based around gravitational slingshots, which meant that the global downward gravity no longer worked. Then I simplified the goal a bit too, although in the planning process I had some ideas for additional gameplay elements (asteroids also affected by gravity, a death-star that'd blow up your planet). I had to cut them due to time, though. The name of the game is a spoof of Star Trek: The Motion Picture.

The weakest bit about this entry is the experience/upgrades bit. If I were to work on this game more, I'd probably cut them entirely. While they do seem to... encourage a planning element I just don't think they end up working well at all. They forced me to artificially group the levels such that the experience would carry over, and they explicitly preclude you from retrying a particular level, since your starting attributes depend on how well you did in the prior levels. The only way I could think to make them work is if doing well on levels would unlock the upgrades which you could then select before the level began.

The game is pretty challenging as is. Wouldn't taking away upgrades necessitate redesigning some of the levels?

(I'm looking at you, Ira 4.)

I don't get it...

Oh wait, yes I do I was thinking of the whole "Does the new film have a ':' or not" thing, which would of course be "Star Trek[:?] Into Darkness"

I did wonder about the name of the game. It makes total sense, but it's very obscure - I'd be dubious about including it as the game currently is. However, if you were to develop the game, you'd have enough time to insert story elements that refer to the thing in Star Trek, and then it would be great

nm, you got it.