Young Merlin did this, although the story was quite simple and they kind of cheated with speech bubbles containing icons depicting what the characters talked about.

If you make it a part of the story that the characters can't actually communicate verbally, that in itself could make the story more compelling (see ICO), so I don't think you'd risk dumbing down the story - but you might be better off avoiding certain topics (like complex politics) that require some detail explanation. Over a large timelapse, wordless communication seems to be more about actions and habits, while for singular scenes it is more about visual design and animation.

How to practically solve this for events that are out of the player's scope depends a lot on how you want to tell the story; you could do obvious clues in the environment telling a story about what happened, show characters' memories and imagination visually in some way or simply design the narrative in such a way that the player will always be present (in some sense) when important things occur. For example.

Also, check out this thread; http://forums.tigsource.com/index.php?topic=7405.0

Code:

...

A singleton is almost always an implementation detail.  Put it where it belongs, keep it private.

Ah, yes, but that doesn't really solve the issue with the data you need for a D3D renderer being vastly different from the data you need for a GL renderer. You could of course have a separate struct for each renderer type and only create the one you need, but that would just be a singleton that you are wrapping by having the interface in a namespace instead of a class (which is essentially just a namespace with a pointer attached anyway). In fact, you are more or less doing this already.

To be honest, though, if you choose to do this or just implement a traditional singleton and address this directly does not affect the code architecture or performance in any meaningful way, so it is just a question of how you want to work with your code. I prefer to have a more uniform way of accessing data myself and thus like to wrap it in classes even if they are only going to be instanced once, but to each his own.

I've been saying this for years.  The singleton was designed for pure object oriented languages like Smalltalk where ordinary functions and free standing data don't exist.  A singleton lets you simulate them.  In languages like C++ a class is supposed to be a data type.  What the hell good is a data type that only allows a single instance?  Use a namespace instead.

The thing about singletons is that it essentially creates a global variable that resolves one of the big issues with global variables; namely control of creation and deletion. You can only have one at a time, sure, but you can also have none at all - and you can decide when it is created and destroyed. Also, you can use inheritance on singletons, say for example you only want one globally-accessible renderer in your application but that renderer could at runtime be created as D3D or OpenGL.

I do agree that there is a tendency among some to view singletons as a good alternative to using "nasty" globals, though, and that it is definitely not. It just solves one of the problems with them.

Hmm... off the top of my head, in no particular order;

Aquaria
Iji
World of Goo
Gish
Karoshi 2.0
Dyson
Warning Forever

I ran across this thread and was wondering if there is still an interest in a basic beginner's tutorial for making music. It's something I might be interested in doing to help others and to help solidify certain knowledge in my mind and explore other things I may not know much about. My initial idea is a beginning article discussing tools, techniques, and inspiration for creating music. The inclusion of a bunch of links to other resources would also be part of it. I know that there are some of you who are very good at music and probably even more qualified than me to do something like this but I'll give it a shot if there is interest.

If there is interest do you have any specific requests as to topics to be covered? I'm thinking basic overviews to tools such as trackers, sequencers, vst's and the like. Basic theory, form, and ingredients to music (very basic). And then ways to work with creativity such as motifs and using what you've written to generate more material, keeping your music interesting by not repeating yourself and other things such as that.

Any takers?

Yes, please =)

All of what you said, really. For starters, it would be really good to have a tutorial giving some overview, about the things you mentioned and also maybe something about different genres and the basics of how to create music in them. Not so much to make you a competent musician, rather providing a basic understanding of it so you know what is interesting to look further into and how you should do it.

Well, the obvious reasons are that you are cluttering up the global namespace, which is bad when several people are working on a project, and you are locking up memory - if you have global objects, you have little control of when they are created and freed which can be a bad thing.

The other reasons are more related to how you structure your code, and about dividing responsibilities. Using a lot of global variables, it is easy to get stuck in a pattern where you avoid doing things on a local level and simply depend on the global state - this in turn creates a lot of dependencies on these global state variables and can lead to a lot of maintenance issues when their behavior is changed, as well as making it hard to remove or insert pieces of code. It is also quite bad for cache-coherency.

The first set of reasons can be worked around (namespaces, singletons etc) so it more or less comes down to what kind of code you want to write. If you are writing a small project that you have a complete plan of and you know for sure will never be extended, do as you like - however, if your plans are more fuzzy than that it's better to keep the code as modular as possible. I would say it's not a question of when you can use globals, it's a question of trying to design a system where the components are as autonomous as possible and won't need so many global variables.

V for Vendetta? ... The critique is directed at fascism, though, and if you include critique against nazi and communist governments you'd be sure to find a lot of movies.

On topic, I am hoping they make a movie out of Jennifer Government and keep the social commentary intact. That would be interesting.

Yes.

Saint has an awesome hat.

Haha, thanks.

Problem was the heat - the hat added would make your head (or at least my head) look broken. So in a way, it was a cursed hat - once equipped, it could not easily be removed.

Did you post your game(s?) anywhere, by the way?

It was awesome, though.

Speaking of Teeworlds, why not just use their source? it's free and available for download on their site.

A game where the world is set on the inside of a sphere and gravity pushes you outwards, rather than the world on the outside where gravity pushes you inwards.

I would like to say Terranigma here as the very concept was actually an important part of the story, but then again it didn't have any effect on the actual gameplay - only some weird inverted Mode 7 effects.

I'm not sure about this. Team Fortess 2 and various multiplayer FPS games allow you to expand the screen with a widescreen monitor, and to even wider amounts with multiple monitors. Yet those games seem to remain balanced, or at least I think they do.

Well, yeah, it *can* be a problem, but isn't necessarily one if the amount of things you see on the screen doesn't have a big impact on the game. It is a point worth bringing up, though.

Teeworlds, for example, handles widescreen by extending the screen and zooming in, meaning you see roughly the same sized area but distributed in another way.

I would say; if you can design your game/ui so that showing more of the screen won't be a problem, do that. Making sure that people feel privileged with the equipment they have got is a bonus, and in the long run having a game that can be played on a multitude of aspect ratios/resolutions will help you out further.

You will change the amount of screen the player will be able to see, though, which can be a problem for multiplayer games (balancing) and games that rely on fixed resolution - for these cases I would recommend black bars - warping looks ugly and the black bars show that you have done something about the problem, IMO the amount of special cases a game handles goes a long way in making it look more professional. But do make this optional.

New version!

Drop thing fixed, you now can use any result on the board and the visual feedback should be vastly improved.

I tried to tweak the speed somewhat, though too much and it becomes impossible to read all the numbers in time, so I simply put in the option to start at any level you want.

Getting random combinations correctly when you have enough blocks on screen is starting to be a problem, but then again proper planning of blocks you cannot use is part of the game. Still not too sure about the concept but it should be better now, at least.

Thanks for trying it out =)

The speeds are poorly tweaked, that is very true, but I hadn't thought about wanting to avoid doing it because it messes up the following block... I should probably fix it so that you'll need to press down again in order to drop the next block.

You are supposed to work the numbers from top to bottom (or in the case of elimination games, you can pick any), it is mentioned in the tutorial but the feedback for this is poor - especially since the number is popped the moment you complete the operation and not when it actually disappears. I might allow the player to use any of the numbers in the list in order to allow for more options and counter the problem of waiting for specific blocks, and try and make the feedback more obvious.

And about the operation in the screenshot, it follows standard operator precedence and is thus always 43, but as I mentioned the result gets removed from the list when the operation is created and not when the blocks disappear.

The game has really poor production values since I threw it together in a day to try out the concept, and the reason I'm posting it here is because I'm not sure if it is worth working more on or not. Again, thank you for your feedback 

Yeah, so I made this game a couple of weeks back...



http://www.ekermo.se/proj/by_numbers.zip
Windows XP and beyond. As I am too lazy to make a gimped version of my engine, it requires GLSL 1.1 (essentially SM2). Sorry about the terrible format for such a concept 

... As you can see in the image, it is a tetris-like puzzle game where the main point is to use arithmetic operations in order to produce certain results.

I am not quite happy with how it turned out, the set of operations that can be used to produce certain results is sometimes too small, leading to the player having to drop blocks in the least harmful place in order to just get the singular one that works. Also, the block frequency or speed increase haven't been tweaked at all. There may be some value in it though, I found it quite fun to build complex operations in elimination mode... Anyhow, I humbly submit it to whoever wants to have a go =)

Incidentally, this collides with the Develop Conference, and it did last year too.

In all honesty though, disregarding a couple of exceptional speakers the best part of last year's conference was the Chicken and the booze, so I'm not that sad to miss it.

I loved the setting in the Mortal Engines series of books by Philip Reeve, it has a very nice Postapocalyptic-Steampunk world. Essentially there was a nuclear war and in order to keep on living the remaining humans built giant moving cities that traveled the lands, surviving by eating each other.

The cover art gives you some idea;
http://www.mortalengines.co.uk/old_tech_page

That said, you probably want to avoid framerate-dependent motion...  And it might be easier to avoid that than to wrangle code that was originally not threadsafe into being threadsafe.

This.

The typical solution to doing fixed-framerate simulation in a dynamic framerate setting is to collect the time spent into a cache and just run fixed-timestep simulation steps as there is enough time, like so;

For each frame in the physics simulation (where TTotal is global and initialized to 0.0 at startup);
1. Get the time taken since last frame, TF, and add it to TTotal
2. Get the wanted time for a single frame of physics simulation, TP
3. if TTotal < TP, leave this and do something else
4. TTotal -= TP
5. Do a single frame of physics simulation (TP time)
6. Goto 3

... You'll get a slight offset but it shouldn't be noticeable if your timestep is small enough.

Well, if you warp the mouse to the center of the screen and do this *every frame* you can just call SDL_GetMouseState and your delta movement is the offset from the wanted position, like so:

Code:

//Somewhere in the gameloop
int MouseX,MouseY;
SDL_GetMouseState(&MouseX,&MouseY);
int DeltaX = MouseX - HalfScreenX;
int DeltaY = MouseY - HalfScreenY;
SDL_WarpMouse(HalfScreenX,HalfScreenY);