I haven't got any sound at all!  D:

Physical realism isn't always the goal.  We programmers have a habit of forgetting this.

Judging by the little planet under his avatar, I'd wager http://www.youngwebbuilder.com/

[EDIT:]

Nice!  :D

There's an easy and practical workaround for the lack of a master effect pipeline now -- just create another Mixer, pass its output through a bunch of effects, and route the output to the master mixer.  Even if I do add a master effect chain that will generally be the better way to do things since you might want alerts or something that aren't affected.

An _awesome_ trick if you're going to do this is to waver the pitch shift up and down about one semitone with a ~1-2 hz sine wave.  It'll make your game sound like a crappy VHS tape.

Checking out Maximum Yak Maniac now...

EDIT:  How I downloaded github folder?  ;_;

Yeah, that's another problem.  When I think about my game, the "front end" is the part of the game the user interacts with, and the "back end" is the interior logic of the game and the engine it's written on.  When I think about my engine, the "front end" is the set of classes users of the library work with directly (the public API) and the "back end" is the implementation of that API and the swappable hidden classes which implement basic functionality like interfacing with the OS' graphics, audio and filesystem.

So you might do well to more carefully explain your structure.


...Ah, you replied while I was typing.

Maybe what you describe is the right approach then... my motivation is simply based on the assumption that I feel confident about being the right person to produce the back-end and the core functionality, but feel that the front-end may be handled better by others.

Discomfort about API design isn't a great reason to make a huge architectural change.  Just get some advice on API design or copy the style of another API.  My first game's "engine" mimicked the conventions of the SDL API, and my present one uses a style I came up with myself based on my experiences with that.  The basic gist is to make programming with the engine as easy as possible without sacrificing functionality.  For a sampling, check out the audio library linked in my signature.

Also, I had a vague thought in the back of my head about dwarf fortress style supplementary utilities running alongside the back-end and the front-end... but if the TCP/IP thing is going to be too much of a pain, that's not necessarily a reasonable trade-off.

Would it be though?  Because by my thinking, it's only a rather limited set of data that would be passed back-and-forth.  Keystrokes from the front-end, and screen-sized tile-arrays (or, maybe just tile-array deltas) from the back-end.  Almost like the front-end is little more than a thin-client...

You don't need TCP/IP at all for this.  A lot of people don't understand how DLLs work -- they're pieces of code that run separately from executables and can interface with more than one program at a time.  If multiple programs use a DLL, the DLL still exists as a single instance with two clients.  Thus they can act as a way to communicate between two executables using native calling conventions.

Still, I wouldn't bother supporting this until such time as you or someone else is making such an external program.  Otherwise you risk doing a bunch of work that might never yield any useful result.  Life is too short to bother with that stuff.


...and you replied again.  Okay, now THAT makes a little more sense.  In this case your game is the back-end and your interface (what I would generally call a "game engine") is your front end.  That involves a lot less data being sent around, since game logic usually doesn't involve as much memory as low-level functionality.  Still, it's usually best to do things the easy way first and make things more complex only when it becomes necessary.  I'd start off just writing a plain old program.

That sounds like a nightmarish amount of work for a game engine that would have terrible performance.  You'd be serializing and deserializing data for every operation that most systems copy at a low level or pass by reference, which is crazy amounts of work for both you and the machine.

What is your motivation for this architecture?  I have an engine with an extensive front-end API which is fixed and back-end implementation layers that can be changed out to facilitate running the engine on different platforms.  (Different games can be written on the engine easily, even compiled into a single binary.)  But you seem to be doing the opposite; creating a single implementation layer which can be accessed by an arbitrary number of APIs?  Allowing the construction of multiple middlewares for accessing the same pool of functionality?  This sounds like madness to me.

I might not understand your specific goals, but I smell a mistake in the making.  If your goal is to make a game, don't bog yourself down with architectural goals.  Plenty of major games are programmed in ways that would make a software engineer cringe -- the point is they were finished.

Ref is not especially thread-safe, no.  It's expected that audio will be controlled from a single thread.  The multithreading and resource management between the control thread and the audio thread is safe as long as this is the case.

Why can't I choose both? The whole point of good code is to have easily maintainable things.

Good code means easily maintainable code.  A certain level of code tidiness is a necessity for a healthy project, but over-dedication to elegant code tends to make for a less prolific developer.  My game engine has gaping holes in its functionality because I have yet to create things that require the missing things.  As I make those, I add the facilities to the engine.  Yet I have written an engine with the mentality that it will be generally useful within its basic constraints.  I am caught between the priorities I suggest, and though I produce quite a lot as a programmer I have thus far completed very little.

Cave Story's source code is a cryptic labyrinth which challenged my notions of proper programming.  It is difficult to extend, inflexibly architected and in many places makes use of uncouth, clever hacks which could be carelessly broken.  It is elegant in none of the ways I was familiar with, but elegant still, for an entirely different reason:  it is nothing it does not have to be.  It follows the shortest, simplest path to its goal.  And in the end, it is a compact, simple machine with no flaws to be seen but for the ones I've added in in Cave Story+.

My motivation, articulated more carefully:

Action, not words, is the native language of visual games.
I wish mine to speak articulately.

I wrote a gigantic reply, but I was afraid it would derail the thread so I made it separate:
http://forums.tigsource.com/index.php?topic=30623.0

[Half-Dreams 101]

[This was originally composed as a reply to a thread asking for advice on how to start writing for games.  It has been made into its own thread to avoid a massive derail there.]


The following is a very powerful creative technique that requires some patience and an open mind.  It's the best advice I can give on how to be creative on-demand but can be difficult to apply.  It's also rather a personal thing for me to talk about so uh, be aware the shields are down..?

Half-Dreams 101

In the afternoon or early evening, well before you'd normally go to bed, clear your mind.  If you drink tea, a cup of herbal is appropriate here.  Otherwise calm yourself down with whatever sort of ritual you have for that purpose.  Go to your room away from distractions, turn off the lights, lay down in your bed and close your eyes.  I prefer to lay on my right side.

(You may play music, though my luck with this has been mixed; it works best when the music has a consistent and creatively relevant mood, no lyrics, and is conducive to relaxing.  If you use headphones they must not interfere with your comfort.)

Your goal is not to sleep.  (Sleep is failure.)  It is, however, to have a sort of dream.  If you have a story idea you'd like to develop, think about it as you relax.  Otherwise let your mind wander.  Avoid guiding them or formulating expectations about the "dream" you will have beyond a basic premise.  Attend to your comfort and try to shift your focus away from your body; if it begins to feel a little alien that's a good sign.  Avoid trains of thought about your life and worries as much as you can.  As your thoughts take their course, try to visualize them.  Do not force this; your best-case scenario is that your thoughts "run away" and the things you see follow suit.

Let a place take form; one you did not anticipate is best.  Let characters come into existence, if appropriate, and give yourself a persona; these should suit the setting in some sense.  Allow events to transpire autonomously; do not exert too much of your will.  As your character, act, but resist the temptation to fly up into the air or alter the world unless these are capabilities your character has (for narrative reasons) or you wish to move on to a different space.

Good tricks for improving and maintaining your immersion are to generate sensations on your character's body and imagine them -- rub your hands together, blow on them, touch your face, count your fingers.  Take a sharp breath in the world; try not to be distracted by the sensation when your real lungs follow suit.

If you make it this far, and it can be hard, you are experiencing what I call a half-dream.  It will not seem real, and you will not have a convincing impression of "seeing", "feeling" or "hearing" any of the things you visualize at any point, at least if your experience is like mine.  Your memory of the events that transpire, however, will be as crisp as that of a real dream.  The mechanisms of this memory are similar to those applying to dreams as well -- the topics of a conversation will be memorable, for instance, but the ordering and wording will be more difficult.  Visuals and sounds will be most vivid.  Writing things down within a day helps.  Do NOT fall asleep from within the half-dream or you will forget everything.

At this point you can enjoy the benefits of being in an altered mental state which connects you with your intuitive capacities.  For our purposes here, you are accessing your creativity for storywriting purposes.

A wonderful trick for drawing new and unexpected things from your creative mind once in a stable half-dream is to imagine something mysterious -- a door is a prime example -- and approach it without formulating an expectation about what lies beyond or within it.  When you open it, the thing that lies behind will be a surprise which generally relates to the setting.  This can lead to interesting and unexpected narratives.

If you have a more specific narrative idea you wish to explore, setting the scene and letting the characters act works wonderfully.  If you want to think about a place, put yourself there and explore.  It's all very open-ended.

Lastly, this state lets you confront your demons and consult with your heart.  This isn't directly relevant to writing, but personal growth and writing are deeply intertwined.  These are matters psycho-spiritual and I won't ramble about them unless asked to. 


Footnotes:

- Powerful as this trick may be, it may be more difficult than the old-fashioned alternative of mind-altering drugs.  I haven't experimented with those, so I wouldn't know. 

- At one point I spoke to a Buddhist monk who described a similar process and called it visual meditation.  Unfortunately we didn't talk at length and I haven't really researched the topic further.

- Carl Jung apparently gained much of his insight into the human mind from experiments like these conducted on himself and others.  I didn't learn about him until after my initial semi-accidental forays into the technique, and it was a bit startling to see how well his description of the "archetypes" fit my own experiences.

[Ref safety]

Ref safety:  All the audio classes derive from RefCounted and contain their own reference count, allowing multiple Ref<T> to be instantiated safely from their pointers.  The new code in 0.2.0 splits Ref<T> into Ref<T> (for RefCounted types) and the less-safe AutoRef<T> which works with anything, requires explicit construction and has safety warnings all over it.  The latter isn't used anywhere in the engine and is provided to retain compatibility with arbitrary types.

C++11:  Portability is a big goal with this audio engine and sadly support for C++11 is still far from universal.  I'm going to hold off until I feel assured all major target platforms for games (including closed ones like consoles) are safe.  

Object copies:  Nope, just ref-counted pointers.

Code:

typedef Ref<AudioStream> Sound;

Sound and Signal are both safe to copy.  It's an encapsulation scheme I use all over the larger game engine and allows me to treat many of my C++ classes like C#-style reference objects.  Copying any actual audio object (derived from AudioStream) is illegal and will not compile.

[Non-interleaved buffers]

Hello!  No shortage of familiar faces today.

Non-interleaved buffers:  Just to explain my motivation for this, it's *really nice* to be able to generalize audio effects like pitch/amp/bandpass to an arbitrary number of channels.  So it's a mercy towards writers of audio streams that makes life a touch harder for implementation and codec writers.

Codecs:  I'll be very interested to see what you make.  Note that I've already written a conformant ogg codec; it's macro'd out in the stb_vorbis codec and you could make a converted copy.  If your wav codec is pure C++ I'll also be very interested to see that.

Performance with many streams:  Streaming sounds straight from the disk is can be costly; layering more than a handful of streams can cause disk lag with severity proportional to disk bandwidth.  The solution is loading them into memory with AudioClip, which is unfortunately extremely dangerous to use in the current version of the library.  The workaround is to instantiate a "headless" audio module and pass it to AudioClip's load function when you use it.  This will be fixed in 0.2.0

Distortion with many streams:  Probably you just need to amp them down a bit.  In the future, I'll be adding a Limiter class and maybe an "effect chain" mechanism which could be used to place one between the master mixer and audio output.  I might even make it so a Limiter is in there by default...

std::cout:  Good point, I can have a look at that.  Notably, though, portaudio's debug lib spits a bunch of data to stdout.

I would be interested in seeing what you've made; mail or message me if you like.

[Pan]

Yes!  Some feedback for once!  Thank you.  <3


Pan:  I will make that change immediately.  The scheme was bugging me but I didn't really think it over much.

Decibels:  Ah!  Thank you for setting me straight there; I'll fix it straightaway.

Resampling:  I'm well-acquainted with the pink elephant paper (see my bookmarks) and I really like it.  I've been pretty satisfied with four-point resampling in terms of sound and speed.

Cutoffs:  I don't use floats.  My audio engine was originally going to support multiple sample formats, but writing every processor for all those different formats was a pain.  In the end I decided on 24-bit fixed-point sound stored in 32-bit signed integers.  This is fast, permits a huge dynamic range and facilitates safe overflow that can be managed with limiters.  I also don't have to write clipping logic into every little thing like I did with 16-bit...

I'm thinking I should also add some higher-order lowpass/highpass filters.  I'd like to make Bandpass use Butterworth filtering of user-defined order but haven't been able to find a good code reference for that.


Status:  I've been working on extensive documentation covering the next version (sneak peek) and fixing the major bugs I mentioned previously.  I was hoping to have a version 0.2.0 out for Christmas (because Christmas) but the new year is perhaps a more viable goal.  After that release I'll try to do patches on a more nitpicky, frequent basis.

Until the end.  Until the beginning.

Exteeeeend...  EXTENNNNDD?! 

Err towards simplicity, and add complexity only when the former is tested and shown to be ineffective.

Choose a priority:  To write good code, or to create good things.  Remember your choice and stand by it.

Ludum Dare?

Game Maker is pretty damned great.

I was in love with the idea of no language barriers, maybe more than anything.

I did a little experiment last night, though, and I'm realizing total avoidance of language probably isn't forward thinking with what I want to do.  I'd need to use symbolic representations a lot.  It would be extremely difficult to animate it all, and a bit forced.  A slightly more realistic goal would be extremely minimal use of language -- simple vocabulary applied with extreme terseness.  This would permit the conveyance of simple concepts which would act as a sort of "scaffold" on which to build more complex, unspoken ideas.

The time I've spent thinking about the game having no language has been insightful though -- Robin Arnott uses the term "temporary belief system" to describe this sort of thing.  I've found myself paying much greater attention to body language and facial expressions in film and animation and thinking about systems of mannerisms I could construct and convey.

The little script I've written details the mental/emotional state and consequent body language of two characters as they exchange five lines of dialogue.  There's a lot going on behind the words said -- white lies, feelings, motives -- which motivates eye movements, postures, et cetera.  A lot to work with, when I pair a great deal of subtext with a bare minimum of speech.

At this point I'm toying with the idea of having the game's text read like a crude translation of a foreign film, or a children's book.  That's a reasonably "low" language barrier, and more than enough for me to convey complex ideas.  I also feel as though words will have greater weight if few and far between.


As an example:

The protagonist stands at the base of a great tree, wearing a satchel on his back.  Another like it sits against the trunk.  Him arms are crossed, and he is looking upwards into its high branches.  He shifts his weight from one leg to the other.

A leaf flutters into view from above and drifts to the ground beside him.  Giving it no notice, he breathes deeply, and sighs.

Onscreen narration:

"To those who do not know her,

perhaps she does not seem frail."


The unspoken ideas here (which I expect I am entirely redundant in recounting) are that the protagonist is traveling with someone he is protective toward, she has elected to climb into the tree, and he is quietly worried and impatient for her to come back down.