Only redrawing objects that have moved doesn't really work because the entire screen gets cleared. But if we didn't clear the screen, then the old renderings would still be present. How can we get rid of everything that shouldn't be on-screen any more, while retaining everything that doesn't need to be redrawn, and redrawing everything that does?

2. In 3D games, how does character customisation work? For example, say the game starts with a basic model and then applies things like facial hair, eye colour, and sliders that modify the size of parts of the model like the height or weight.

Feel free to ask your own questions, answer others', post helpful articles* or just update us on your game development projects.

1. Isn't this a bit of an archaic optimization? I think implementing it now with modern hardware would actually be slower, except in specialized cases where everything occupies grid locations and you can easily redraw a grid tile over the previous location.

1. How does one go about only updating those parts of the screen that require it?

This is not necessary any more (and hasn't been for 13+ years). Modern graphics hardware is expected to completely redraw the scene every frame.

Only redrawing objects that have moved doesn't really work because the entire screen gets cleared. But if we didn't clear the screen, then the old renderings would still be present.

Not only that... but if data is double-buffered (which it usually is -- you would not want to render directly to the display or you get horrible graphical artifacts)... then the image left on the buffer you're drawing to may not be from last frame, but from 2 (or more) frames ago.

2. In 3D games, how does character customisation work? For example, say the game starts with a basic model and then applies things like facial hair, eye colour, and sliders that modify the size of parts of the model like the height or weight.

The model used in-game is just a collection of points in 3D space. If your pre-defined model specifies a lower/upper bound for those points, then a slider can just interpolate between them.

Things like facial hair, would just be adding more polygons to the model. Eye color would just be changing the color and/or texture, etc.

2. In 3D games, how does character customisation work? For example, say the game starts with a basic model and then applies things like facial hair, eye colour, and sliders that modify the size of parts of the model like the height or weight.

I'm facing this problem right now.

I was just thinking to make seperate models for shirts and such (Works just fine for a small indie game like mine).

If you're using skeletal animation (Looking into it myself), simply just rig up the clothes to the skeleton.

Disch explained the rest pretty well.

==============For that drawing I'd personally rewrite that code completely, but that's just me.

well if you are using sfml then it will redraw the entire window every time so you don't need to worry about localized redraws but why would you want to do that anyways?

Since the game loop is looking for events and has to cycle through the code first anyways, it makes since to just update variables and then redraw all. Spot update would make things overly complicated IMO, because then it would just have to perform additional checks to see which areas have been affected and need alterings and which do not.

General questions here for gamedev people: In a large RPG how do you store data on disk? Obviously many game objects make reference to other game objects, so how do you make that association in data on disk? Do you use object ID's? And how about maps and map entities? Do you make entities part of the map structure or give entities a map ID for their current location, or something else?

1. You will actually have a chance of losing performance if you do it that way and have much more complicated drawing code.

The reason is because you will have so much work tracking very single object in you game that needs to be drawn that it might be more expensive even though you are drawing less. Also modern hardware like others have said are more optimized towards clearing the screen (Or buffer usually) first then just redrawing the scene.

So I would recommend staying just with clearing the buffer and redrawing everything. The thing with games is usually you shouldn't worry to much about optimizations until your game is ready for them (Not to be read as you can write sloppy code). You will usually know when it is time to start looking at optimizing your game. I usually just run a profiler on the game to see where the performance bottlenecks. I then take somewhere around the bottom 5%- 10% performers and start to work on optimizing them.

At start up, the game loads all the textures, shaders and sound effects for the section the player is in. The textures all get loaded into video memory. At the same time, though, it loads everything for the adjacent sections into system memory. When the player moves to the next section all the game engine has to do is move textures from system memory into video memory. Then it will free any resources that are no longer needed (e.g. if the player starts in section 35 and moves to section 36, it frees everything for section 34), and start loading sections that are adjacent now but weren't before.

INI isn't "bad". It's pathetically easy to parse, but the downside is that it's not very expandable.

XML is typically preferred because it's extremely expandable and its hierarchical design fits in well with OOP... but parsing it is significantly more difficult (premade libs are typically used to parse it).

So it's a tradeoff. If he doesn't need the expansive capabilities of XML, then INI will work just fine.

@Lumpkin
The format is project dependant. You pick formats according to what you need.

My experience is that the tilesheet is loaded, then the map is simply read in from text files with special format names instead of '.txt'. For example, a friend of mine who made a game used level001.map, but it was simply a text file with the map layout.

Reading the file in would be a vector to store the map and draw it to screen. Some load their map code into a separate .cpp/.hpp file and pull it from there. You could use static arrays if you have a set width.

There are tons of ways of doing it, just depends on your needs and what you prefer.

I have a few general questions I would like to ask other game developers just to see how they go about it and to see if I am missing anything or if I am doing it completely wrong. Feel free to pick and choose any that you have knowledge on.

1) How do you go about doing your testing for your games? This is the main thing I have been wondering about. I have a few specific and general tests that I always run but was wondering what everyone else did.

a) What kind of unit tests do you usually run or set (For those who do TDD)? I know this question is broad and not all tests apply to all scenarios but if you have specific examples that would be great.

b) Do you go through the work of creating in game testing tools? For example in one of the games I am working on I have implemented a in game console which I can then input commands to execute certain things I want to test (Lets say I want to fine tune a certain power-up on a shooter, I would then just enter a command to get that power-up instead of having to go through the motions to get it in game).

c) If you do go through the work of creating in game testing tools what are the types of tools that you usually develop (or use if they are a 3rd party tool)?

2) State management how do you implement it? This is something I have been digging into lately and I was surprised that there is a bunch of different ways people do this. I always just figured that everyone used FSM (Finite State Machine) but I was wrong.

So what do you generally prefer? I have been generally sticking to FSM (For my last game I created a State Stack where when you want to change global state you just pop the old state off the stack and then push the new on it, or if you want the old state to stay alive but not active (Like for a pause screen) just push the new one on it) but am curious how things like behavioral trees can be used.

3) This next question is more specific. If you have ever implemented Quad Tree Collision how did you go about it? I am curious because I recently did this and was curious if I went about it right. If possible could you provide a example of your implementation (Or the implementation itself?).

@LB, Disch
Well, I used INI as an example. I may use XML or JSON instead, but I've not decided yet. I have a simple INI parser already written so I'll probably use that in the mean time.

@Lumpkin
I'm developing a 2D side scroller with a single, continuous map (i.e. no levels or hubs) split into sections so all I need are the configuration files and the textures and such.

@Zereo
1. I don't do unit tests, really. I've never learned to. I keep telling myself I'll get around to it but I never do. To test the game, I literally just build and run it and see what happens. Once it gets to a working state I try it on emulated machines and on my laptop, and then after that I'll send it to friends to playtest, but really, I don't test any of my programs "properly". I also never properly design anything. I am a bad person.
2. I use the exact same system you use and I was also under the impression that this was pretty much ubiquitous.