Nairou

To expand on Telastyn's response: std::string, std::map, std::vector, etc. absolutely are part of the language (see section 21 for the Strings library, section 23 for the Containers library, etc.). They just aren't primitive data types.

As for "STL"... The "Standard Template Library" was written before C++ was ever actually standardized, and is different from the C++ Standard Library. When C++ was finally standardized in 1998, it incorporated parts (but not the whole thing!) of the popular STL into the standard itself (and the C++ standard defines what we call the "standard library"). The STL is not, however, fully incorporated into the standard library (for example, the STL's rope never made it into the standard library), and there are some differences between the STL and the standard library (aside from the fact that the standard library adds more than was originally in the STL). Instead of saying "the STL is the standard library," we should say "the STL influenced the creation of the standard library." Unless you're specifically referring to the Standard Template Library that was written by Alexander Stepanov and Meng Lee before C++ was ever standardized, you probably mean (and should say) the C++ Standard Library

Very interesting!

The point I was trying to make is that, being part of the standard library and not a core part of the language itself, they are optional. You can use a std::string if you want, with it's pro's and con's, or you can use a char*. The latter is a direct part of the language, and is very explicit and simple, while the former is part of a library and can have side effects (i.e. dynamic memory allocation behind the scenes). Once you understand how std::string works, it isn't a big deal. It's memory allocation is just a part of it's pros/cons list. But it's something to be learned.

Likewise, as someone who doesn't know Go very well, I was curious about which parts of the Go language have these sorts of memory allocation side effects. While std::string is an optional library component in C++, it appears to be a core part of the language in Go (you don't need to import anything to use a string). This makes it harder, on the surface, to know where these side effects are.

(And to those who think I'm being obsessive, read this.)

What I mean is, things like strings and maps, which are variable in size. They don't have a fixed memory footprint at compile time.

Unlike C++, which uses no strings or maps or variable size structures in non-trivial programs...

Well in C++ those are just part of STL, not build into the language. You can choose to use a std::string, or you can just use a char array. You aren't forced to use a string, because it isn't actually part of the language. In Go, you just have a string, and it's a part of the language, so they expect you to use it. Which is fine, I just want to understand what's going on behind the scenes.

Also, GC is not a memory leak panacea. Our newer client software at work which is written in C#, "leaks" far worse than the older C++ client.

Exactly. I have more memory leaks in my C# applications than I do in my C++ applications. I want to have some level of control over memory management, especially in a game. I just don't know enough about Go yet to know if it gives that level of control.

Currently, in my game, I use XML for most of my data files. Not because I particularly like XML, but because the library I'm using (PugiXML) is particularly friendly. However, because the files are XML, they feel rather unwieldy to edit.

In the past I tried switching to JSON. Ignoring the fact that I couldn't find a C++ JSON parsing library that didn't spit out tons of compiler warnings, I found JSON to be just as annoying to use as XML. My primary interest in JSON was that it was a simpler format, and seemed to have less extraneous text required to be a valid and easily-readable file. However, after using it, I found that to not be the case.

• The entire contents of the file has to be surrounded in curly braces. Not a big deal, but bothers me as it feels unnecessary. I don't care about it being parseable by Javascript, I just want it to hold some data from my game, that only my game will look at. I can't just dive in, create a new file, I first have to start with the curly braces to make it valid.
• All variable names have to be surrounded by quotes. If the file is a decent size, pretty soon all you see is a big sea of quotes. They add noise and extra work to what should otherwise be a simple layout.
• JSON is very strict about commas. If you create an array of items, every item must end with a comma, EXCEPT for the very last item, which must NOT end with a comma. It is very common fro me to get parse errors because I added or removed something from an array, and didn't notice that the commas were wrong.

I recently found this blog post which gives pretty much the same list, and shows an example of an alternative layout. I think the result he comes up with is pretty good. If there was a library to parse that format, I'd use it.

But I think it could be taken even further. Considering that this is for storing data for a game to use, I don't remotely care about any features that exist for the sake of Javascript or the web. All I need is a list of key-value pairs, where the value could be a single value or an array. Something like this (as a random example):

name "Test model"			// Simple key-value pair
version 1.0				// Numeric values are allowed
geometry {				// Value is an array
	vertices {
		0, 0, 0			// Array of values. No key given, so accessible by index position
		1, 0, 0			// Another array of values, also accessible by index
		1, 1, 0			// ...
		0, 1, 0			// ...
	}
	indices 0, 1, 2, 2, 3, 0	// Value is an array. Array values are inline, so don't need curly braces.
}

To me (and I know this is personal opinion), this format looks great. Simple, no extra characters, easy to understand and write.

So, I guess I'm wondering:

• Why do most people seem to be using XML or JSON for their data files? In the context of writing a game, where you don't need to communicate with an external piece of software, it seems like overkill.
• Does there already exist a file format (and accompanying library) that is extremely simple, like what I've written here? If not, I may have to write it myself, but no sense rewriting something that already exists.

5 months later... has anything changed? Or are these (Fmod, OpenAL, SDL, PortAudio) still the only decent options available? All of them have downsides, there's no clear choice here...

Admittedly not for very strong reasons. Mostly because it prevents me from static linking the library. I don't know if there are other restrictions, the LGPL license is rather cryptic.

I'm ready to start adding sound effects to my game, so I've been looking at audio libraries. My requirements are that the library be cross-platform, free for commercial use, and under a friendly license (not GPL/LGPL).

The three main options I see right now are Fmod, OpenAL, and PortAudio. However, each one has both pros and cons to them.

Everyone knows Fmod, its used in tons of game, has all sorts of tools to make it easy. There is a free version of it, but I eventually plan to sell my game, so I can't go with a free license. However, I also can't afford to spend $500 on an audio library.

OpenAL seemed to be the next logical choice. Not so simple, not as much documentation, but free to use. However, in looking into it again recently, it appears that development has gone proprietary, and only the old 1.1 version is still freely available. Choosing an old abandoned library to learn to use for the first time doesn't sound like all that great an idea.

And then there is PortAudio. Also free, and very much in active development. However, it is also extremely low level, more targeted towards professional audio applications than games. It seems to be little more than an abstraction of the audio hardware, so everything on top of that (file decoding, volume adjustment, effects, etc.) I would have to do myself (or find another library to sit on top of it). On one hand, it could be really useful when it comes to generating abstract sounds rather than just playing pre-recorded files (something I plan to do eventually to some degree), but for everything else it sounds like it will be a huge undertaking.

None of them seem to be ideal, but I haven't had much luck finding another audio library that fits my requirements. Are there other options that people know of? Something I'm overlooking?

Essentially, I'm curious what methods people use (whether they be tools, processes, etc.) for speeding up development when working on a game.

I am currently working on a game, which I have been working on in my spare time for the past 2 years. Granted, I have learned a lot in those 2 years, but I don't feel that the game "looks" 2 years old, if that makes sense. It still has very much of a "tech demo" feel to it, with large portions of both the gameplay and underlying framework unfinished.

But beyond that, I feel like I am just really slow at making progress. As an example (and not the target of this post), I recently got a portion of the game working, allowing the player to instruct units to construct particular types of buildings (this is sort of an RTS game). I had been working on implementing this portion of the game for the better part of a month (in my spare time), working out the interactions between the UI and the game state.

Now that it was playable, we were able to see some of the issues with the way it was designed, and made changes to the design, requiring me to go back and make some significant changes to the code I had already written. I've been at it for a week now, and feel that I am little more than half done with the changes. And this is just for this one piece of the game.

By comparison, I see people on these forums throwing together prototypes on a matter of days (I don't even understand how you can prototype a game, with all of the underlying framework that is required). People participate in the Ludum Dare competition, creating full games in under 48 hours. And full released games on Steam, like Terraria, which were developed in only 6 months.

So what are they doing that I'm not? How do other game developers throw together a functioning game in hours or days, and I struggle for weeks trying to implement a tiny portion of my own game?

Only thing I've though of is maybe changing the way I write game code so that it is a bit more modular, rather than writing out all of the client and server bits by hand wherever they are needed. But I'm not even very clear on how I would do that, and at this point it would be (again) rewriting existing code rather than finishing the game.

How do you develop features for your game at a decent pace? I would appreciate any opinions and ideas at this point. Thanks.

People please help me
I can't find nothing
I'm 100% sure that people use cg for shaders

Some people use Cg for shaders. Other people use HLSL for shaders, and still others use GLSL for their shaders. There are many ways to create shaders.

Also, shaders are not like regular programs. You can't just create a shader and run it. Shaders are designed to be used by another program for a particular purpose. If you want to learn how to write programs that can use shaders, try here or here. If you just want to play around with shaders in a simulated environment without doing any other programming, then you probably want something like this.

After spending some time playing with existing GUI libraries for my game, I've decided to look into rolling my own. My needs are fairly simple, but more dynamic than the libraries I tested seem to be designed for. Until now, I assume that this would involve rendering lots of quads to textures (one texture per panel or window in the UI), and then rendering these textures on quads onto the screen.

However, after searching around for other ways to implement this, I came across this post, where swiftcoder suggests composing the UI on the CPU rather than the GPU, and then just blitting the resulting texture to a screen quad from there. I had never considered this method before, but I'm intrigued.

Has anyone else done this? What were your experiences with it? It seems like you would have more freedom in designing the UI since you're not having to send each piece as geometry to the GPU, but on the other hand I don't have much idea how to edit textures on the CPU either. Would uploading final textures each frame to the GPU really be faster than sending the individual quads to the GPU?

Swiftcoder mentioned two libraries for composing UIs on the CPU, Skia and Cairo. Has anyone used these for games? Are there others like this? I'm more inclined to do it myself rather than use a library, but I'm curious what all is out there, and haven't managed to find others from my own searching.

For OpenGL, I would start here. It's the site I used when learning OpenGL 3.x.