What, no mention of Joyce yet?

A few light taps upon the pane made him turn to the window. It had begun to snow again. He watched sleepily the flakes, silver and dark, falling obliquely against the lamplight. The time had come for him to set out on his journey westward. Yes, the newspapers were right: snow was general all over Ireland. It was falling on every part of the dark central plain, on the treeless hills, falling softly upon the Bog of Allen and, farther westward, softly falling into the dark mutinous Shannon waves. It was falling, too, upon every part of the lonely churchyard on the hill where Michael Furey lay buried. It lay thickly drifted on the crooked crosses and headstones, on the spears of the little gate, on the barren thorns. His soul swooned slowly as he heard the snow falling faintly through the universe and faintly falling, like the descent of their last end, upon all the living and the dead.

(Full text: http://en.wikisource.org/wiki/The_Dead)
I really liked Dubliners. Haven't tried Ulysses or Finnegans Wake yet, and I'm not anxious to without some serious guidance, but Dubliners is very readable.

And while I'm in my junior-year English mood, The Love Song of J. Alfred Prufrock.

Let us go then, you and I,
When the evening is spread out against the sky
Like a patient etherized upon a table;
Let us go, through certain half-deserted streets,
The muttering retreats
Of restless nights in one-night cheap hotels
And sawdust restaurants with oyster-shells:
Streets that follow like a tedious argument
Of insidious intent
To lead you to an overwhelming question…
Oh, do not ask, "What is it?"
Let us go and make our visit.

I love that poem so much. One of the few I've bothered to memorize, though I forget most of it now.

Of course, neither of these is really that applicable to most games, unless they're going to be seriously narration-heavy. Dialogue (and character development and whatnot) is a whole different ballgame.

"Tako" is Japanese for octopus (as well as for "taco"), so given the art it's more likely "Real Octopus Hunt."

Ohhhh, okay. That makes much more sense. Although I'm tempted to make "Real Taco Hunt" anyway.

Thanks!

Google Translate says that this one

is "True Taco Hunt".

Is that indeed the case?

Lua also has LuaJIT, which is a really damn fast just-in-time machine code compiler for Lua bytecode. It's hardly slower than native code for most tasks.

Code:

___________________________________________
ERROR in
action number 1
of  Step Event
for object player:

Sound does not exist.

I loaded a game at the first save point, hit "a" and got this error. This happens every time I load the save file. Want me to send it to you?

Ben

This looks wonderful. Love the style, love the attention to detail, love the non-focus on combat. I wish I could offer to help code, but the most I'd be able to contribute is a couple hours here or there. Anyway, best of luck, I'm eager to see what comes of this! (And congratulations on finishing exams!)

Actually right now it breaks a crapton of compatibility because the old way of defining/calling methods with colons and an explicit self argument no longer works. Plus self is also a keyword, so that's two. But yeah, it was mainly the period/colon distinction I wanted to get rid of.

Now I'm wondering whether that was a good idea. I was thinking it would be easier to learn if there were only one syntax for accessing variables and methods, but I'm not sure this is easier in the long run.

In fact, it's probably worse exactly because it breaks compatibility with existing Lua. Damn. Oh well, it was still an instructive exercise and I'm proud of it. If I ever have to dig through Lua's internals for whatever reason, having done this will be super useful.

I think if I was just about to start a project then SFML would be for me. All the setting up of Vector classes, sprites, rectangles, maths etc etc etc has been done. Thing is I am now so far into my project that switching from SDL now would have little benefit. Shame. Wish I knew I had taken a serious look at the lib before! Though I would have to compile from source as there is a lot of stuff in the API that I just don't like and wouldn't want hanging around.

If you link it statically, most compilers will kill a lot of stuff with dead code elimination, so don't worry about recompiling it.

Actually, that's another benefit of the license - you can't use DCE with SDL unless you static link it, which requires your program to be (L)GPL. So in practice, SFML may not be much larger if you don't use all that "bloat".

(I suggest we stop piling on kada2k9. Clearly he's at least developed some opinion on SFML, which he stated in his first post, so he had at least some grounds to post. Plus, people have pointed out that said opinion might not be legitimate, nothing's going to come of belaboring it except for hard feelings.)

My main issue with SDL is lack of good OpenGL support. SDL is a relic of the era when OpenGL wasn't as common as it is now, and so it was actually useful to have a blitting graphics engine. But now that OpenGL is on nearly every computer, there's no reason to use the slower, less flexible blitting engine of SDL, making it basically bloat. If you're using SDL OpenGL without blitting, you have no reason to complain about SFML's cruft. (And remember that SFML is way smaller static linked.) Plus SDL gives you jack all to work with if you try to use OpenGL, whereas SFML has the excellent Sprite class to take care of mucky texture business. (Note: for some deranged reason SFML's sprites do not support setting the OpenGL z-coordinate, which means you have to draw them in depth order CPU-side. Next time I use it I'm going to submit a patch, because that's pretty dumb. Other than that, Sprite is way better than anything SDL has to offer.)

Then of course there's language thing. SFML has a much slicker object-oriented interface than SDL, because C++. I myself love objects, but I also hate C++ object semantics, so it's kind of a toss-up. If you can deal C++'s references/pointers/copies/whatever crap, then go for SFML hands-down; it will make your life about an order of magnitude easier (and your code half as long). On the other hand, if you need a language that takes up less brain-space, SDL is written in C, which is easier to understand (to me, at least).

SDL has excellent bindings to other languages. If you need access from a scripting language it might be a safer bet. SFML also has bindings, but fewer (only C, .NET and Python at the current version), and you may have to figure some things out yourself. Of course, the SFML bindings to OO languages are probably much slicker than SDL's.

Feature-wise, SFML wins by a long shot, in my opinion. The main reasons: better OpenGL integration (Sprite object, fonts, ...), better sound support (SDL_mixer ameliorates this, but then you're adding more dependencies and it sometimes lacks bindings), and some niche features like FTP and sound recording.. SFML 2.0 will also include UTF support (for internationalization), which is pretty nice for some people. On the other hand, SDL has CD support, which is fast becoming a niche feature in its own right. With that plus the severely outmoded blitting engine, it's hard for me to say who's ahead in the bloat department -- SDL is smaller, but probably has just as much API bloat. And if you add in SDL_mixer and SDL_net and SDL_ttf (to get up to functionality-par with SFML), you're getting pretty big there.

SDL has been around longer than SFML but personally I haven't noticed any bugs in either of them (except for the crash on exit with ATI cards on dynamic linked SFML, I guess). Also, SDL has been moving very slowly in recent years as the devs don't have as much time as they used to. It *will* work on more platforms if you need to go beyond the Big Three.

There's also the small matter of license. SFML is zlib/libpng, which is more liberal than LGPL - most saliently, you're allowed to static-link it, and not SDL. That could simplify your distribution significantly.

Yeah, I think that covers the main differences between SFML and SDL. Better features, slicker interface, zlib license vs. maturity, platform support and smaller size.

Edit: The ability to static link to SFML with proprietary programs is actually quite useful, because some compilers (GCC for example) can cut down its size quite a bit with dead code elimination. So SFML has more bloat if you link them both dynamically, but if you link statically to SFML you don't have to worry about carrying a bunch of cruft in your exe, whereas you'll always have to lug SDL's CD/blit functions with you.

I just modified Lua to have transparent method-vs-function semantics. So now instead of writing

Code:

t = {}
t.foo = 1
function t:bar() return self.foo end
closure = function() return t:bar() end

you can write

Code:

t = {}
t.foo = 1
method t.bar() return foo end
closure = t.bar()

Yeah, I know, it kind of kills Lua's simplicity, but I'm basically mangling Lua for my own purposes. I'm pretty happy with the modification, personally, since I'd never touched the Lua internals before. Real first-class methods and object lexical scoping! In (probably) <150 lines of C! Yay!

Madk, that leads to inefficiency when you have lots of rapid state transitions. Specifically if the state changes more than once per 8 frames, it will be more efficient not to encode it at all.

I'm going to be radical and suggest that RLE isn't what you want at all. Rather, you should encode the frame number for each button press/release. If you have fewer than 16 buttons, you can spend 4 bits on which button, 16 bits on which frame (as long as you don't go over 1092 seconds at 60 fps -- perfectly reasonable for a Mario style game) and you don't have to spend anything on recording button state -- since it's binary you can just flip the state every time. That's 20 bits per button event or 5 bytes per button press - pretty reasonable in my book.

Actually, even better: spend 8 bits on the time, giving you a total of 12 bits per button press. Every 256 frames (4.2 seconds), start an event with button code 1111, to indicate that the clock has rolled over. Since that button is never used except to indicate a rollover, you don't have to put a time after it. In fact, if you have fewer than 12 buttons, you can just record 11. Hey presto, 3 bytes/button plus <1 bits/second. I think that's superior to RLE in most cases, although some constraints might make RLE or a limited form thereof better (for example, if whether the jump button is still pressed only matters for the first N frames, as is the case in Mario, then you might do better by just attaching the run-length to the button-press record rather than recording button-release separately).


edited because 16 = 2^4, not 2^5. doh.
edited again: apparently I decided not to read the part where other people suggested this idea. I guess if you're interested in the math this is still useful. Just ignore the "I'm going to be radical" part.

To echo other posters, nice look. I'm not digging the aliased Times New Roman as a font, though. I hope you can find something more Greek-looking. And anti-alias it.

[shed]

Okay, why not. I just got back from Greece and took a bunch of photos, so hopefully some of them came out all right. This was basically my first time using a camera, so criticism extremely welcome.

shed




plants




probably Danny




acropolis poppy




tentacles




temple wall




Others here.

What if you turned that around and used the opposite weather from what was currently going on? If it were 120 degrees out I'd much rather enjoy a chilly winter day with my escapism.

You could also steal this idea for a world with a bunch of different cities, mapping each one to a similar real-world city. That would kind of kill the element of "oh it's raining now, something interesting will happen in the game", since your current location might not map onto anything... I guess you could make sure the player's real-life hometown always maps onto their in-game home base, but still.

Neoshaman, I wasn't talking about including all the subtleties of conversation, which is of course a really difficult problem. I was just saying that the act of transforming some computer representation of semantics into human speech is pretty easy. So if you were willing to "cheat" on the step where the semantics are generated - for example, using IF-style commands rather than natural language parsing, or just mixing together a large number of pre-generated sections of computer-representation-of-semantics instead of inventing new ones, or letting NPCs ignore conversation subtleties for the most part - I think you could create a pretty good illusion of procedural speech.

@mcc: That looks like exactly what I was looking for! I'll definitely check it out. Thanks for the tip!

@Mikademus: Somehow I noticed that. But I don't fancy decompiling it to see how it's done, or bothering Tarn Adams who undoubtedly has better things to do than explain to me how weather works. I don't suppose you know where Tarn Adams got DF's model from?

Something about this game screws with my depth perception. I think edges of blocks need more definition maybe? Also, would it be possible for you to draw blocks that are between the player and camera slightly transparent, or provide some other way to see him when stuff is in the camera's way?

Also, I'm entirely unclear on how digging works. Clarify? And it still crashes when I jump off cliffs.

Well, if turn based stuff is what you're going for, I still advise that you make the camera less jerky. And yous should make everything turn-based, then, as Bood_War suggested.

Also, once you have rivers, waterfalls. Everything's better with waterfalls, especially through space.

That's a good point, moonmagic and gunmaggot and neoshaman, there can be "good" emotional overwroughtness if it's used intentionally for comedic effect. Are there any instances where emotional overwroughtness is used for actual emotional effect on a sort of meta-level, though? I'm tempted to say Tengen Toppa Gurren Lagann falls into that category, but I'm not quite sure if it counts as overwrought.

Mewse: small reply to avoid thread derailment with slightly irrelevant argument.
TFD's actual wording was "melodramatic", rather than "melodrama". You might be interested to know that most of those dictionaries give a broader definition for the latter, including "overly dramatic at the expense of characterization". So, you are correct: it is technically imprecise to use "melodrama" to mean the noun form of "melodramatic" rather than just the 18th-century art form. However, I believe that in this context the distinction between "melodramaticness" and "melodrama" is reasonably obvious. I am sorry if my tone offended you. It was not my intent to come across as aggressive or arrogant. On a related note, your sarcasm is slightly hackle-raising, but I'm going to assume that I'm just taking unnecessary offense there. Anyway, I've settled on "emotional overwroughtness" as a substitute for now; I hope you're OK with that. Even if it wasn't TFD's intent, the topic of emotional overwroughtness in video game writing is certainly an interesting one and worth pursuing - as is the use of music to accentuate emotions. So if you'd like to talk about that, by all means bring it up.

So it crashed as soon as I hit Enter to chose a place to start. At the time it crashed I could see a close-up view and the little orange block guy who I assume is Orange. I'm using 64-bit Windows 7 and would be glad to run some kind of debug build if you have one.

I tried running it in XP compatibility mode and got a little further; this time it crashed a while after I jumped off a cliff.

Anyway, looks really pretty, interesting concept. I hope you plan on adding more detail to the different plates though, they all looked pretty much the same from the world map. Also, I'm not digging the jerky movement or the jump mechanics, or the way the camera jumps in discrete intervals. I think it would be much easier to play if camera and player movement were continuous.