I don't agree that showing in words is just as effective as showing graphically.

Extending this idea, games can speak in many "languages".  Gameplay is one, visuals are another, music, sound, text and symbolism are still others.  I see a great deal of elegance in making careful choices about which is used to make a given communication, and in knowing what they say when taken together.

A more comprehensive but less natural solution would be dragging per-axis, a la Unity's object positioning tool.  You're probably better off having a key swap between XY and XZ, though.

Well-spoken, d.  Well-spoken.


So here's my story:

I had a narrative I had designed, based on a dream, and begun writing as a short story.  The idea grew and I decided to make it a game instead.  I did this because I wanted to do the story justice with my best skills, but I was also aware of a great conflict that created.  You can't simply move something from one medium to another.  It is deeply changed.

I spent some time pondering this conflict and what ultimately shook me out of my indecision was a Jon Blow talk about mechanics.  (I can't remember which one, exactly.)  I conceived a system of game mechanics that would uphold the story, in which every atomic action taken by the player is a meaningful action taken by the character in the narrative.  A system that is explorative in nature, suiting my favorite type of play.  The story has developed greatly since that decision, and the game design alongside it.  It's become a somewhat co-dependent relationship.

I've waited and delayed and fiddled with a lot of technical ambitions and now I'm making headway.  I don't know if I'm doing things right, or if my story and game will be as cohesive as I expect, but I feel a warmth on the horizon.  I'm writing this game because I'm excited to step into this world I've been dreaming of and meet its people.

It sounds silly, but I write for games because I want to bring that dream to the waking world.

yo yo supa cool yo I used asciitable and I'm sort of proud of myself for figuring that out but if I was a real programmer I wouldn't need asciitable and

I'm excited for PEGjam.

Just a note:  Let's not let this tangent into a discussion on linear vs. nonlinear storytelling.

The points made so far are interesting and I agree with them -- even a linear, seemingly non-interactive story can be made compelling by gameplay.  But in what ways do the interactive aspects add to storytelling independent of changing the story?  How do they arm us to tell stories better?

I'm inclined towards my "exploration" answer -- that we can take things at our own pace -- but it's maybe a bit skewed.  Exploration is my whole paradigm for looking at games and tends to be how I evaluate them.

[It's my skillset.]

"If you want to tell a story, don't make a game.  Write a book.  Shoot a movie."

This is a statement I disagree with, but I'm a little challenged to articulate why.  I'm interested to hear responses from the game-narrative-writers here.


Here's my attempt at explaining why the combination of narrative and game, rather than those things taken on their own, is important to me:

It's my skillset.  I'm an excellent programmer, a good game designer and of at least amateur competence in other relevant disciplines.  My prose-writing experience is limited.

Immersion and exploration.  I cannot quite name the visceral feelings I have when given an opportunity to navigate an unfamiliar space with a body which is not my own.  When I project myself into that situation and begin to explore with the mobility available to me, a depth of experience is something I treasure profoundly.

(When the space being explored is not only physical but narrative, more tangible thoughts and emotions can be built upon that basis -- but is this an afterthought?)

Agency in narrative.  Games let us make decisions, which adds to the emotional and mental situations we can create for our audience.  Unique to our palette are regret, reward, indecision, confusion, frustration, attachment, protectiveness, malice, playfulness and numerous others.  If we use them artfully they can be powerful colors for painting a story which no other medium can.

As an expert C++ programmer, you don't need to be an expert C++ programmer to make your stuff.  Know your goals, choose the right tool for the job, and make a beeline towards taking that thing in your head and putting it into the world.  If that tool is Game Maker (and for many of my friends it is) then that is totally fine.  As a former GM expert I can say there's a hell of a lot you can do with it.

Being a super-coder mostly just makes you want to set crazy technical goals that slow down your creating anyway.  Case in point the kinematics engine I'm programming right now.  

Cellulose here, demanding more forty-five degree pixel art.  Hello, evil twin.

Code:

//An affliction caused by hypersaturation of air in the blood.
typedef std::vector<Bend> Bends;

I was writing a kinematics system and I surfaced a little too quick. 

We're having an impromptu Iowa game jam with the theme of "work on your crap".  I'm taking the opportunity to do some research and development on kinematics systems.  If I had a giant pile of money I'd license IKinema, but alas...

I drew a shaman connecting to the spirit world:

Fucking cool.

I got my ticket yesterday, so add me to the Iowa list; I'll be carpooling with Mike B.  See you there grrl.  <3

I feel like the original question is a little over-broad, like asking "how do I program graphics?"

What kind of AI behaviors are you specifically after?

I've had this happen too.  Journalists are human like everyone else; they don't always finish what they start.

Performing a five-minute song without mistakes is difficult!  Here's my entry, played live and a little imperfectly:
http://evanbalster.com/wreath/tulisah-take19.ogg
https://vimeo.com/56609449 (video)

The protagonist of my game grew up in a forest, "Tuli-Sah", and the song has sort of a homesickness/nostalgia theme.  Gameplay involves traveling through the character's memories so the "overworld" concept is taken a little loosely here.

Lyrics:

TULI-SAH

____________________ In the trees... I am at home, and my mind is, at ease... Rustling leaves... a haven, here, twixt earth and sky, and sea... It's a place, I know, where I was meant to be. Chorus: This place, I will not forget I will not forget Even if I Walk a thousand paths I will not forget Even if I'm Never coming back I will not forget This place is my home

____________________ Do you see... The autumn's red is dancing graceful- ly... Do you hear... A whispering wind that stirs the countless trees... And my heart, it stirs as soundly as the leaves... [chorus]

____________________ Memories of long ago are coming back to me... Family... Who gave me life and all the words I speak. We went far from here to find the peace we seek. [instrumental]

____________________ Things have changed... This place is not the place it used to be... And yet still I stand here filled with reve- rie.. And my heart, it stirs as soundly as the leaves... [chorus]

Man, where did today go?  

An interest in lucid dreaming and a talk on it which I attended were what led me to discover this method.  I would characterize it as a lesser cousin of proper lucid dreams, which I haven't had much luck with.  Though I could stand to experiment some more.  I'll check out the videos.

My song is now fully composed, just need to perform and record it.  =_=

Two days remain...

For future reference this is more of an art forum question.

What I was saying is that if your library already have it's internal thread, I shouldn't have to have another specific thread just to give it commands.

I could easily have written the library so it wouldn't be a problem, but I had a specific goal: syncing the audio timeslices to an external framerate which is generally expected to be the rate for game logic, thus facilitating consistent time deltas between subsequent visual and aural events.  It's very rare for game logic to be split into multiple threads without creating a point in time where all logic is complete and a final step is taken -- if there is such a final step, then it's perfectly possible to use the audio engine.

If you did satisfy that requirement, you would need to ensure each audio stream's front-end (settings) is controlled by only one game logic thread, and that none of those threads are at risk of manipulating those settings during the "final step" at which point you make the call to Audio::update().  This function "sends" the settings to the callback thread, so it's reading all of them.  You also want to ensure all calls to Audio's interface happen from only one thread, which you could make less of a pain by giving each of your controlling threads a separate Mixer attached to the master to play their own sounds on.

Or if you can't make any guarantees whatsoever, just make multiple copies of the audio engine.  

Klaim:  Tell me about the threading scheme in your game engine.  I'm interested in use cases.  Also, how do you handle your graphics?  I know OpenGL never multithreads well; does DirectX?

Overkill:  Got the audio working.  Whoever talked about logspam earlier wasn't kidding -- printing stuff to the console from the audio thread is baaad, that's why the audio engine is misbehaving so badly.  Sorry for shipping the temp code like that.  Sounded fine otherwise.