It's not Windows that should provide it but the driver implementers, like NVidia and ATI. I remember that there are profiling tools available but I don't remeber their names.

Imagine: Fashion Designer (2007)

I've worked on this one!

By the way, those games are made by little companies that are not related and sometimes (like for this one) don't start as an Imagine game but get rebranded by the editor. This one isn't even called that in France...

Funny, my biggest game have similarities in concept (replace cards/spells with virus softwares...) and I'm still thinking about different ways of selling it.

For example, I think that the Magic model works only because the hardware cards does still exists and have a value. That makes easier for players of that game to continue their habs to buy cards online. Well... here I'm guessing because the problem I see is that it's not a fair system.
Maybe I'm wrong : the massive ammount of cards allow for even more massive amount of valid strategies that, in the end, depends a lot on the context of the battle (what both have).

I'd like to reproduce that but clearly I'm not in position to provide hundreds of different games units...yet.


I've thought of several more or less fair ways to sell the game and it's content, but I don't have to decide yet. The technical side is flexible enough to allow a lot of different strategies, but the way you sell it might impact a lot some technical aspect of your game.

It's awesome for simple projects.


Add multiple (required by the domain) dependencies and sub projects and it can become hell.


But it's manageable.


But it don't (really) provide relative paths (AND THAT IS NECESSARY.).

I want to create an efficient and generic input system

That obviously already exists (in C++) :

http://sourceforge.net/projects/wgois/

Wait, you want an input mapping (binding) system right?
Then people using OIS are working on one : http://code.google.com/p/oisb/

 

I do, but mostly because the game design impose MVC (because the views can change while playing). MVC (or variants) should be used when the cost of implenting it don't outweight it's use in the game.

Last time I wanted to make a simple bullet-hell, I didn't use MVC.

That said...


Component-based systems are implicitely MVC. So I guess a lot of indie games does use MVC without knowing it.

MVC is a glorified name for saying that different aspects of the same "model" are separate from it. Like separatng things and perception of things. You shouldn't, for example, really implement a "controller" just because it's in the name of the pattern. Just keep the idea of separation thing/perception, and exploit it if your game can benefit from it.

Otherwise there is no other point than flexibility.

And lot of indie games do need flexibility to achieve excellence or create new ways of playing.

About any (meta-)build configuration tool (CMake, Autotool, Premake, Scons, etc.)

It should be used if:

 1. you have time to use it (aka not in game jams)
 2. you master basics of it (aka not just when you discover it : use experimentation projects first with those)
 3. you need to be cross-platform (aka most of the time those days, but you might want to not bother on windows for example, making visual studio projects easier to use anyway)
 4. you don't mind separating project definition from your favorite IDE (aka you don't mind having to add new files paths to an external text file not managed by your IDE).

If you're in those cases, then go for it. Just check wich tool you're most confortable with.

For example, I'm using CMake for a gui tool project, mostly becasue it allows simple integration of Qt. But I hate some CMake features so I'm not sure if I would use it for a game, even if it's the most complete tool for builds.

I'm planning to try Premake because it seems to be a good tool in case of games. Not mature yet they say, but very flexible and uses lua to define everything.

So it sounds like your game relies on pixel-art?

Not at all.
It imply symbols in 3D space, making them unreadable at short distance if the resolution is to low, because of the 3D space transformations relative to the camera.

Did you play DeadSpace? See the interface? It's a bit like that, but in more intensive use.

I could go that way, and that would mean doubling the resources. I mean : the game is ALL about symbolism! (and other things).

But my goal currently is to make it playable in 1024x768 and I think it will be find. Just not the best experience.

Yes but that's precisely what is hard : in some low resolution, texts and symbols, depending on how they are rendered (for example, on a texture on a 3D surface) becomes a bunch of unrelated pixels.

So that really depends on a lot of game-related things. On most of the games I've worked on, it wasn't a problem.

I was planning to use both a company name and my pseudo, a bit like Positech and Cliffski.

Seems good too, no? What da ya think?

But if they can't, because of a slow computer or and old monitor, you've just forbidden a whole chunk of players from being able to play your game.

That's the naive thing that most people say because they don't understand that there are other constrains than resolution.
For example:

 - displaying text : the minimal resolution impact the readability of text. If you need some kind of text or other symbols to be clear but abondant in the game (for whatever reason), you need high resolution.
 - the "wide" experience : sometimes you need the player to see things in a way that means he have a large point of view. If your game interface gets in the way but you still need it to be available at any moment, it becomes frustating to not be able to fix the minimal resolution at, say 1280*1024.

Some say that the second point means "there is something wrong in your game interface" but let me juste say that they can't even have the possibility to say that and be credible because it requires knowing what the game is about and why I get there exactly.

And never forget, creative people :


THERE IS NO RULE.

1. Something(rules, actions, etc) need to modify the model
2. on modification, the model "notify the world" that a specific event occured <=>send an event
3. somewhere, something listen to this event and react by producing output for the user... or more actions.

Trigerring sound is simply listening to the events that are notifications of model change or occurence of game events, and produce output when it get that event/change.


Is it more clear now?

For naming the class, use common sense, avoid contextual confusing naming. In your case, I suggest SoundEventListener (pun intended) 


Second, if you are in a really pure MVC pattern, your graphical informations should be separate from your model (the Actor). They should communicate but not be one into the other.

You have to think your output (visual, audio, other) as a totally separate layer, even a totally separate application that only receive events from the model (the controller thing is not really a specific concept...).

The only exception is visual interraction like gui that requieres your "view" layer to also be an "input" layer that feeds the controller of the game (that manipulate the model if necessary, by "following the rules").

Is it more clear?

I've twittered about aspect ratio and resolution some weeks ago and the feedbacks were that I shouldn't force any resolution (aspect ratio is another matter).


But why was I asking myself this question at first?

It was because I thought it could enhance the experience to force at least a nice high definition resolution.

Someone pointed that it would point a problem in your game interface if it required high resolution.

That's right... for most games.

The thing is, I have a lot of elements, sorted by colors to help the user see what's important.
But most important : I have text displayed on 3D textures. And that's one of the most important feature of the game.

So I'm still not sure if I'll force a minimal high resolution for this game, maybe I'll just keep 1024x768 as minimal and force wide screen display in some ways. But that might be a bad experience for some visually appealing games that really should be played in high resolution (even if you don't have a bleeding edge graphic card, that's fine).

That's not an obvious choice for every game.

My 2 cents.

Errr....



std::basic_string destructor isn't virtual...right?


You might have surprises if you add member objects.


Although, weren't free functions enough to manipulate those strings?