I'm no expert in 3D Audio, but some possible things to check:

Have you set your Listener's location and orientation vectors?
It sounds like you're properly setting the sounds location, but are you setting a velocity for the sound(even if it's all zeros)?

andrew-101 could be onto a potential problem, as well...OpenAL requires an audio file to be single channel in order for it to be attenuated.

I just wanted to say best of luck with the project! Sounds a bit like something I've been mulling over for a long time.

Lua is super easy to integrate, but code quality really starts to suffer once script complexity increases and folks wish for a statically typed language and a decent native debugger. And profiler for those garbage collection spikes! :D

Visual scripting on the other hand helps with the static checking and garbage collection, but large scripts soon become spaghetti. But at least it's all visible spaghetti.

Yeah, those were some of my thoughts, as well.

My ideal world would be visual scripting plus native game DLL loading, but clean support for multiple platforms, that's quite a task.

Better yet, full open source with a clear distinction between Engine and Game layers =)

And this [DXT] compression goes all the way into video memory on supported hardware, which is over 94% of gamers according to Wolfire's report: http://feedback.wildfiregames.com/report/opengl/feature/GL_EXT_texture_compression_s3tc

Even for platforms that do not support it, you can uncompress it on the fly on software.

But I'm not sure this is a must... for 2d games. Sprites often need to be pixel perfect

That's absolutely true, we actually have a DXT1 and DXT5 backup path that decompresses it on the CPU.  I have also noted the compression artifacts may be an issue for some games, so the Editor will also support importing uncompressed textures.

[Xienen]

Xienen: Why DirectX? You will have to rewrite the code for Linux support if you use DirectX. In my case, I'm using OpenGL.

I am using OpenGL.  The only DirectX I am currently planning on writing is for XBox360 support.

You seem very confident about support for Android, iOS and Wii, did you have already programmed for all these platforms?

I have previously developed a complete game for iOS(Break Blocks Touch!) and demos/examples on both Android and Wii(soft modded Wii running Homebrew).  I'm not going to pretend like supporting all of these platforms is going to be simple, but I do believe I can make it happen.

Glad to hear someone else has been successfully as crazy as I am =)

What's the name of your engine?

I have found that FRAPS is worth every penny, if you have a speedy machine.  I'm able to record 1080p with no issues on my Corei7, GeForce 480, and my 2x 3TB Deskstar drives in Raid 0.  When recording RAW video(like FRAPS does), the most important factor is hard drive speed, as long as your CPU and/or GPU aren't fully taxed by the game you're recording.

I echo motorherp and Klaim's response: C++

I'll also emphasize Klaim's final sentence by stating that C++ is not the easiest language to jump into and learn, but it will truly teach you the lowest common denominator amongst modern programming languages.  If you're more interested in jumping in quickly, C# would be a decent alternative because it would free you from having to worry about memory management(mostly) and still has similar syntax to most modern languages(C/C++, Java, UnrealScript, etc.)

Why C? Portability or just your preference?

Definitely just my preference.  In fact, it's quite a hindrance for portability in terms of amount of work required to port it.  If I truly did it all my way, the whole thing would be pure C, but the reason the C++ Game Layer exists on top of the C Engine Layer is to allow game developers to feel more at home in the engine(I know the verbose nature of C is not a commonly adored trait ).

You mentioned visual scripting, what about regular scripting? Any plans to implement a custom scripting API?

I've definitely debated this, but ultimately decided that if a developer really wanted it, they could implement it rather easily.  Even better, one might implement it and release it to the community as an optional addition.  If I was selling the engine, I'd probably end up adding a scripting language just for competitive reasons, but with it being freely open source, I don't feel that it's an up front requirement.

Sounds good.  Good luck to you mate, its gonna take a hell of a lot of work to get all these featues and 2 games written in the next couple of years.

Thanks, motor.  It absolutely is going to take a hell of a lot of work, but I've been working on it 30-40 hours a week for a while now. If I can keep this roughly this pace going, I'll definitely manage to pull it off, but doing that on top of working 40+ hours a week at a day job is gonna be tough to do for that long.  We'll see  

[Paper Engine 2]

First off, pardon me if this isn't the correct location to post this.

Next, let me emphasize that this engine isn't anywhere near ready, in fact, it's not much of anything yet except a core framework.  So, why am I posting this so early?  Two reasons: I'd love to get any feedback available as early as possible and I also want those interested in multithreaded OpenGL cross-platform programmable pipeline development(without GLUT, GLEW, etc.) to be able to see the barebones.

Finally, let me assure you all that this will not be a project that dies off before it gets off the ground.  Greater Good Games will be publishing at least 2 games using this new technology in the next couple of years(regardless of how poorly our first game sold on our old technology ).

Paper Engine 2 on Sourceforge: https://sourceforge.net/projects/paperengine2/

Existing Features:

• Cross Platform support: Windows, Mac, and Linux(with PS3 and XBox 360 coming soon; plus iOS, Android, and Wii support planned for the future)
• Automatic asset updating system. No need to open the Editor every time you change an shader, texture, etc.; just run the game and it will automatically update the respective objects in the Cache.
• DDS Compressed texture support, specifically DXT1 and DXT5 support. DXT1 offers 6 to 1 compression for color-only textures(compared to flat 24-bit bitmap) and DXT5 offers 4 to 1 compression for alpha textures(compared to flat 32-bit bitmap). And this compression goes all the way into video memory on supported hardware, which is over 94% of gamers according to Wolfire's report: http://feedback.wildfiregames.com/report/opengl/feature/GL_EXT_texture_compression_s3tc
• Global Unique ID(GUID) system for linking assets together. Never spend time relinking assets together just because you changed a filename. Simply update the GUID Cache in the Editor to point to your renamed file.
• Asynchronous threaded loading system.

Planned Features:

• Full Editor to create levels and create/manage assets per platform. Meaning that iOS specific assets, for example, can be marked as such directly in the Editor.
• Keystroke toggle between Game and Editor(when running non-Final-Release binary). No need to jump back and forth between Editor and Game executables, just tap a key(or two) and you're ready to edit or test.
• Optimized file cache system with simple package and release availability. Simply select your binary with corresponding continuously updating cache directory and you're ready to release your game.
• Visual scripting system(as seen in UDK and CryEngine) to allow maximum diversity within levels without requiring a programmer.
• Visual GUI builder with resolution scaling support. No more laying out GUI windows with a text editor.

Licensing:

• Paper Engine 2 has been released using the Mozilla Public License 2.0(http://www.mozilla.org/MPL/2.0/).
• TL;DR version: The engine can be freely used in a commercial project without any licensing fees nor profit sharing systems, but any enhancements done to the engine itself must be released as open source.
• Does this mean that you have to release source code for that cool feature you created for your game?  Probably not.  But if you manage to make the whole engine run 50% faster or you modify the rendering system to run the latest and greatest tech, we really hope that you'll consider giving back to the community instead of selfishly keeping your genius to yourself.

Our experience with Break Blocks has shown us that a game that can't inspire its target market to try the game is going to fair just as well on mobile as it does on the PC(Mac version included).  They are both very tough markets to stand out in, but generally, simplistic mobile games can sometimes reach critical mass, while that same simplistic game on PC may not appeal to nearly as many people.  Conversely, I think complex games have a slightly smaller market in the mobile space than they do on PC.

Our problem was that we were a complex game with a simplistic facade, so our target market thought the game was too simple for their liking, while the people looking for a casual/simple game were quickly frustrated by the game mechanics.  Live and learn =)

This is where my engine creates a distinction between Static and Dynamic sprites.  Static sprites will be grouped together to reduce draw calls(meaning they just have to move together all the time...not that they can't move at all), while dynamic sprites will generally be kept as a single quad(or group of quads) which means it's own draw call.  If you're drawing all Dynamic sprites that can't possibly transform together, though, then the above suggestions are definitely the correct route.

There are basically 2 high-level factors in render pipeline speed, as I know it, which are drawing speed(vertex count, texture size, shader complexity, etc.) and draw count(in your case, the number of calls to glDrawArrays).  Of course there can be a "devil in the details" scenario, but basically these are the 2 main categories.  In 2D rendering, drawing speed is pretty much never a problem, but draw count can quickly become a crippling factor.  Someone else may have some other ideas for you, but the way that I intend on getting around this limitation in my engine implementation is grouping quads together(either statically or possibly dynamically) by putting multiple sets of vertices into a single Vertex Buffer and combining the textures into a single, larger texture sheet(and/or using a complex shader that samples from the proper bound texture index for each quad(though I haven't worked out the full details on how I'd really accomplish that...maybe using UV coordinates over 1.0 to denote which texture to use?).

As for the line rendering issue, it's definitely best to combine those into a single vertex buffer and use GL_LINE_STRIP.  Note, though, that rendering lines is definitely a slow function on a lot of modern hardware(because it's basically deprecated functionality that's essentially emulated). Also, on one of my machines in the past, I didn't have the latest Drivers(had recently switched cards from NVIDIA to ATI) and it was running at 1/100th of its potential.

I don't know where the 32 byte recommendation comes from...is it due to a 256 bit BUS in most graphics architecture or something?  So, are you keeping all 32 * 32 of those chunks in VRAM?  Are you not able to create a limited number of Vertex Buffers and buffer data in/out of each of them as needed?

At present, I'm binding uniforms and attributes based on an object type.  If I need to use a different shader for an existing type, I simply subclass that type and override the uniform/attrib bindings.  The actual values for the uniforms come from values held in the objects, obviously, while the attribute values come from the vertex data in the vertex buffer.  I believe this will allow maximum flexibility without making it tooo difficult to setup a new shader.  I could be wrong, though, since I'm not that far into my engine's development, yet, much less the game's development.

I obviously don't know what you game is, chubigans, but my guess is that's the new standard "not a good fit" e-mail from Steam.  As in, "we don't want to say yes, so we'll just tell you to try your luck later, on Greenlight".  Just a possibility 

From what I've read, a couple of better alternatives to GLUT are FreeGLUT and GLFW.  I haven't used any of them, but I've seen them recommended in place of old school GLUT.

With Break Blocks, we targeted OpenGL 2.0 using ARB assembly shaders and almost never ran into an issue with deploying it.  Any machine that did have an issue simply needed to install a newer driver for their video card. Even a wide number of integrated graphics chips manufactured in the past 6 years seemed to just need a driver to get away from the default OpenGL 1.1 standard driver.

If you don't need Shaders nor Vertex Buffers, then I agree entirely with targeting OpenGL 1.3. If, however, you could use shaders to even slightly improve things(including performance-wise), I think targetting 2.0 is pretty safe...I mean, every GeForce 6+ series, Radeon 9000+ series, Intel GMA X3000+ chipset supports it.  Which appears to be about 98% of the market according to Wildfire Game's feedback system.

Sources:
http://feedback.wildfiregames.com/report/opengl/feature/GL_ARB_vertex_program
http://en.wikipedia.org/wiki/Intel_Extreme_Graphics#Graphics_Media_Accelerator_X

In all honesty, it'd be pretty easy to write this tool from scratch(especially if you already have a renderer and image loader).  I'd suggest create a new "mode" for your engine(which could be flipped on via the command line: edithitboxes ./path/to/file.jpg) and then just catching the mouse click/drag to draw a box.  For bonus points, you could catch the mouse wheel to get a little zoom going.  Everytime a box is drawn, output some static XML file(possibly named HitBox.xml).

I would also suggest posting some more details on your physics model:

Are you using "proper" physics with velocity, acceleration, centrifugal force, and friction coefficients? Or are you attempting to fudge it together? Or somewhere in between?

Are you running physics on the 4 tires separately or are you just treating the whole car as a single entity?