You can only do so much on a calculator and, with my skills, that so much is barely anything at all. So, I've decided to take the next step up and swap to programming in C with Allegro. But what would I make? Obviously, the answer is a Yumé game!

Yumé: The Eternal Dreams
The Eternal Dreams is a combination game. It serves as both a PC rebuild of Yumé and Yumé 2: Rika's Story (the original calc version I am building along side ) and will include all of what was slated to be Yumé 3: Finality. The PC game will have 3 chapters --Nanami Chapter, Rika Chapter, and Finality-- that correspond to each original game.

For those who don't know anything about the Yumé series, here's a brief synopsis: There exists a strange world beyond our reality known only as the Dream World. It is a desolate world devoid of animal life. All who walk its grounds find that an unseen force slowly consumes their life, unrelenting until they perish. In Yumé, a 10 year old girl named Nanami finds herself trapped in this Dream World and must find a way to escape. In Yumé 2, Nanami's friend Rika finds herself trapped as well. In Yumé 3, both girls work together to solve the mysteries of the bizarre realm.

However, this won't be just a straight up PC port. There are several differences between the calc and PC versions:
- Nanami Chapter will have a larger Dream World to explore with more plot and events
- The explorable area of Nanami Chapter will be explorable in Rika Chapter as well
- Instead of "Life Force Orb" pick-ups as the primary healing method, there will be special statues throughout the Dream World that radiate a "sanctuary aura", in which the draining effects of the Dream World do not pervade and your Life Energy will gradually restore on its own
- The addition of "miasmas", regions where the atmosphere is so concentrated, the draining affect decatuples. Mainly, these areas will serve as world boundaries. The world extends on infinitely into miasma but you can't explore it because you'd perish. Miasma will block progress in a few areas as well.
- The addition of a running mechanic. Nanami (and later Rika) can run at a rate of 3x their walking speed. However, running can only be sustained for a handful of seconds and this is governed by a "stamina" stat. Stamina reduces rapidly as you run and restores rapidly when you cease running, so long as you have stamina left over. If you burn it to 0, however, you will lose the ability to run for a short while, after which a quarter of your stamina restores and you regain normal stamina regen.
- More easter eggs


Progress so far:
- movement engine (mostly) complete
- the life energy system works
- makings of a "death" sequence for when life energy extinguishes
- HUD with life energy gauge and a heart icon that reacts to damage and healing.

Below is a rather low quality video demonstrating the HUD, life energy system, movement and running.


I am hoping to finish this by January 2012 at the earliest.
This will be released for both Linux and Windows.

*close enough to 24 hour bump*

[cross post]
Rewrote the movement engine to improve Nanami's walking and running animations. Originally, the animation was "right foot -> left foot" at a constant rate which was, admittedly, rather awkward. The rewritten engine uses 3 sprites and does "right foot -> stand -> left foot -> stand" and cycles faster or slower depending on if you're walking or running, which is much better looking.
[/cross post]

I might take a stab at separate running sprites but I think that'd be pushing it a bit right now. I don't want to go TOO overboard with my very first C game, at least not at the moment.

This is looking great! I'm sure I could easily Google this, but in your own words, what does Allegro offer you? It looks like it probably does most if not all of the graphical manipulation? Also, I'm liking the red/gold hearts as we discussed on IRC, and I definitely agree about more movement sprite frames making the movement more natural. Keep up the good work (and the post updates).

The way I've found it, Allegro is to C what xLIB is to BASIC and then some. It may not be the best or most powerful way to go about creating a game, but it certainly makes it very easy to write a decent enough looking game with very little skill.

Allegro offers simple methods of creating, manipulating, and outputting solid, transparent, and translucent graphics; displaying text in fonts; easy access to keyboard input; easy addition of sound; and probably plenty of other features I'm either unaware of or forgetting

it also comes with a pretty simple tool for compiling all your resources into data files to significantly reduce the amount of external files you need to include with the actual program itself. (I'm actually not sure if it comes with allegro by default or if you need to download it separate, but it exists regardless)

That's great! It sounds like a nice way to remove the complexity of making a game without removing all of the programming knowledge necessary and thus making game-making a total templated cop-out (as opposed to my impression of Game Maker (?) as the latter).

It is indeed. I can demonstrate that by reminding everyone of all the ARGH and BLARGH I do on IRC on a daily basis over code troubles

I haven't used Game Maker but just looking at it I'd have to agree it at least has the air of a templated cop-out. But, you can't really berate anybody for using it because making a game for PC is actually pretty dang hard when you actually try. It just so happens that the general Yumé engine is a cakewalk design

*bump*
Implemented alpha Stamina Gauge. Blue bar part decreases and increases with rise and fall of stamina.

I guess that leaves me to ask what the yellow is, then. Is it a guide to how long the blue bar can get? If so, I might like to see the hello part extend upwards to form a right endcap on the blue bar.

It indeed does govern the length of the blue Stamina bar. However, I've been debating on it. So far, I'm deciding between a couple of options:

1) What you said, and capping the right end of the Stamina bar

2) Replacing the yellow "guide" part with a secondary "recovery" bar. Essentially, this bar would be a visualization of the stamina recovery process when you burn all your stamina up.

3) Sorry, this idea is secret at this time

I don't love the (1) option, as it might be visually clunky. It would definitely be clear, though. I like (2) a lot, though! I want to see (3) before I cast judgment, though.

Implemented option 3. Feel free to speculate.

I assume the top empty part gets filled in with the actual health level? My main concern would be that it might be confusing in terms of looking like two active bars, rather than the one real bar and the one reference bar, but it would probably take a bit of playing to decide if it's ambiguous.

Absolutely wrong
Heck, I don't even understand your speculation `-`

You have a top black bar where the blue bar was, which I assume gets filled in with the blue bar, and the bottom blue bar, which I assume is the reference to show what a full bar looks like. If you don't want people to guess, then explain your ideas rather than teasing screenshots.

1) Stamina != health, don't confuse them
2) The bottom blue bar is the stamina bar. It increases and decreases as you use stamina. It is a functional bar.
3) The top bar is filled with a green bar.

Again, for now, just speculate because I'm not sure if I want to spoil what it's used for yet.

*bump*
Give a big thanks to Geekboy who is one of multiple people willingly helping with the game music.

Here's a taste of some of the music. As of the moment, it's slated for a later portion of the game.

*bump* Neglected to post here due to forgetfulness, so have an enormous theoreticals update in the form of both update posts crossed from Omni:

[Wednesday, 2/16/2011]
The environment is going to consist of three bitmaps --two "environment" bitmaps and the "interaction" bitmap. The "environment" bitmaps are, as their names imply, the environment. The actual object sprites appear on these bitmaps. The "interaction" bitmap is a concealed bitmap beneath the "environment" bitmaps that directs the game as to what it needs to do. Whenever Nanami moves, it is this bitmap that is checked to see what should or shouldn't happen. The currently proposed format is thus:

Red areas represent impassible areas. Nanami/Rika/etc CANNOT move onto areas that are this color on the interaction bitmap.
Blue areas represent event triggers. Walking onto these will trigger game events (e.g. cutscenes).
Green areas represent interaction points. If you press the "action" button (think A button in Zelda 64 games) on one of these, Nanami/Rika will perform a given action (e.g. open a chest or door, read a letter, etc)

Pink areas represent typical, walkable land. The Dream World's typical draining effects happen here.
Purple areas represent miasma areas. They can be walked on, but the 10x draining effect happens here.
Yellow areas represent sanctuary areas. They can be walked on and the recovery effect happens here.

Oh, and note: there are two environment bitmaps because the environment engine integrates with the movement engine like this:
> Environment bitmap 1
> Nanami's bitmap
> Environment bitmap 2

Essentially, it allows Nanami to be in front of or behind given objects.

Edit: to clarify something, the "atmosphere" tiles that govern what happens to your health simply set a variable that determines which drain/restore routine gets used. If you step on a purple one then a green one, you'll still have miasma effect. It takes stepping on a different "atmosphere" tile to change it.

[Monday 2/21/2011]
Ran into an issue with the environment engine and properly displaying things depending on if Nanami is in front of or behind them. Thinking about using the Interaction Map to govern this but I'd have to be constantly checking a shed-tonne of pixels... Also, if I go with this, I will be consolidating the environment bitmaps into one single bitmap as Nanami will be displayed above or below it as necessary.

Also, Nanami Chapter of Yumé: The Eternal Dreams is now officially my class project for my Computer Based Methods and Modeling class (fancy name for "Let's Learn ANSI C, mmkay?"). I only say Nanami Chapter is because I don't know if I can get all the way through Nanami AND Rika Chapter in 2/3 of a semester. I know for a fact I CAN'T finish through Finality Chapter in this time period.

Ok!
/me notes to work on music a bit more diligentaly

Now there is a even bigger reason to make some wahoo!

Thanks for the updates, Keith! These looks very complete and well-thought-out; I look forward to when you implement that color-coded tile system into the engine. I'm not sure how you forget to update, considering you're in the Cemetech IRC channel constantly.

Don't underestimate my incomprehensible stupidity