NEXUSKill

There are two big considerations to have when optimizing render systems, my knowledge is PC based but for all I know mobile devices are subject to the same bottlenecks.

 

First is graphics device states, the configurations of how the graphics card should do things, changing these settings, such as Wireframe vs Solid fill mode, or which shader to use is expensive on its own, but also kills pipelining, in case you don't know what that is, think of it as assembly line process, as long as a buch of objects require the same processes, you don't need to wait for one object to finish completely before sending the next one, if the process has 5 steps, you can have 5 objects going through the pipeline at the same time, which saves A LOT of time.

So with that in mind, objects should be grouped toghether based on how similar their rendering process is, Textures are important, specially the large ones, but in my experience shaders and render states are more important.

The other thing to keep in mind is that while the graphics card will skip content that it resolves not to be within the drawing area on its own, the objects need to be in the graphics card for that to be evaluated and that is already a lot of wasted time, it is your responsibility to give the graphics card the least possible number of out of scope objects, this is whats called Potentially Visible Set optimization, and Space Partitioning structures are the fastest way to do it (as far as I know), you should read up on that. Doing it object by object in the CPU is almost as wastefull as letting the GPU do it.

A third thing you might want to be carefull about is clipping, when an object is only partially visible, that is, a part of it is within the view cube, the graphics device must cut the mesh to include only what is within the cube and ignore the rest, this is because if it didn't do so, the pixel shader would likely go through a hell of a lot of pixels that aren't visible anyway. Small objects are not a problem, since they are likely to fit within the view or be completely outside of it most of the time, but large objects, as say a mountain cliff, are likely to be partially visible a LOT, sometimes its better to make these meshes in such a way its easy to discard most of them. I haven't really dug into this concern myself, but you might want to read up on it, I think Polygon Clipping or Trimming are good search terms.

A component should be something that is self sufficient, the collision body structure, the graphic representation, the inventory... and so on.

They should be able to do what they do without needing to know what other components the entity has.

For the comunication between them, for adding them toghether to make something grater than the sum of its parts is the entity, the base implementation of which is a dumb component container.

The entity through inheritance can then become an actor, which combines its collision, controller and inventory system to pick something up from the floor and put it in a backpack, or perhaps that is even more specific, like character, which inherits from actor. The actor knows that it has a volume that contains it well for visibility purposes, a different volume (or structure of volumes) that represents it best for collision purposes and submits each of them to the corresponding system when it is initialized.
The properties of the actor, that make it either an archer or a knight, come from its content only, and may add specific functionality to it through behavior components.

 

Components are usefull but going full force with them is like trying to make something entirely out of sugar, sugar is great, surely, but without flour and other ingredients there is only so much you can do with it.
Systems are great, components are great, inheritance and composition are great, object oriented and data oriented designs are great and they should all work toghether to make a great game. Don't go evangelic on any new trend like ECS.

I once found this in a c++ long method while searching for optimizable loops and unnecessary processes, it was a rendering update for a skeletal animated actor, the method itself was a good 150 lines long total and in the midst of its implementation there was this while loop:

 

//The following block of code should not be executed anymore, keeping it around for fallback reasons
while(0)
{
    ... do about 20 lines of stuff...
}

 

Seeing this actually hung my brain for about a minute before I yelled "Who the F* doesn't know how to comment a block of code on C++?" to the whole office.

The perpetrator was no longer working for the company and was responsible for many ridiculous pieces of code of which this was one of the last that didn't get deleted and fell through the cracks.

Granted, the code didn't actually get executed and the compiler likely did away with the whole loop, but it was still blasphemous.

Right now the consensus seems to be that XNA is finally dying, in its place we are left with Mono, on which Unity is built, and which is built upon SharpDX if I'm not mistaken, that would be the chain to follow depending on the level of abstraction you want to work with.
If you like low level take SharpDX, if you want some wrapping and multi platform support but don't want a high level abstraction use mono, and if you are fine with taking only gameplay logic within a highly abstracted framework, Unity is a very comfortable engine to use.

Depth 1 means no useful pruning, if the depth is 1, all objects will be checked for visibility, so there is no point, the only benefit of a depth 1 scenegraph is having a clean interface to manage objects

The benefit of a scene graph is having a nice hierarchy to manage your scene objects relative to each other. If everything is only 1 deep, then you might as well just have a list of objects and not worry about the graph.

Go over the list, do visibility checks, and if they pass, add them to the render list. You don't need a graph to have different rendering functionality.

He might not as well; the scene graph, packing things together in common boundaries may save him visibility checks.
... Or am i missing something?

It will work, but it may be overkill, if you already have one implemented you might as well go ahead and use it, but if you have to write one I would skip it.
Implementing different rendering behaviors does not require a scene graph pattern, only a good design class in which you have a generic graphic object with all the basics and a specialized class for each different type of graphic to render, you can also turn the design upside down and have the graphic object own the rendering behavior as a property instead of implementing it in a specialized class.

In the end its a balancing problem, if your objective is just to get things working, use what you have or know how to do, even if its not the best, if your objective is to do things right, use only the appropriate tools to best fit the needs of the project.

Are you using any particular engine? sounds like only the visuals are being affected by the resize, you need to either update the UI hit areas or scale the mouse position to a standard resolution before checking collisions.

There are different ways a UI can adapt to stretching and they are all useful in their own cases, such as:
Remain unchanged, no scale or position alteration.
Maintain position relative to an anchor, a screen corner, center or side.
Fully scale with screen.
Probably others I'm not thinking of.

This one is actually a very good resource that describe different approaches for this, you should take a look:
http://www.gamedev.net/page/resources/_/technical/game-programming/the-guide-to-implementing-2d-platformers-r2936

Personally I found that if the engine provides a framework in which every game object or objects of a specific system are centrally managed its easier to keep track of allocated memory and avoid leaks.
For instance, I have a render system (abstracted from any other functionality of the engine, it just knows how to render stuff) that you register all your graphic objects to, when the system is requested to shutdown or clear its contents (to change scenes or something like that) it will take the responsibility of deleting any graphic content registered to it.


The biggest advantage of smartpointers in my opinion is that you are guaranteed not to leave invalid pointers around when you do delete the object. If the likelyhood of that is very high for certain objects, smartpointers are a worthwhile solution.
Most of these problems however are avoided by being clean and organized when designing code (something that sometimes and for the peril of the programmers is skipped altogether) and having well defined interfaces to steer the users of a given code towards the right behavior.

The thing about the unforgiving crash, is that it can hinder progress on large teams, you use function A developed by programmer 1 which processes data introduced by scriptwriter or game designer X who uploaded a last minute change who then went to his dentist appointment and forgot his cellphone... you just lost a whole afternoon in the task you were doing because of someone else's mistake and there is nothing to do about it.

That is, after it happened, you can do things to minimize the impact of this situations, which in a 10+ team, tend to happen often, even in AAA development.
What you can do is having builds with different error tolerance:
The development build would be most permissive, trying to keep on going as much as possible and returning placeholder data or content whenever the real thing cannot be delivered.
The debug build can be the one that provides the most data, and is the least forgiving of all, crashing as soon as an error is detected and performing extra sanity checks (conditioned by pre processor code not to be part of the release).
Then the release build would lean towards speed (if we are speaking of videogames this is crucial) and resort to try catch code with error reporting support.

This way, if an error is introduced you can still keep on working without wasting your time, perhaps your progress would not be in a deliverable state due to the broken data on debug and release, but at least you will be able to make progress.

First off, forget about the code and its specifics entirely, think of the game's design (at concept level), try to think of it as a non programmer, what are its parts? what parts have stuff in common and what? if you have an orc and a human, are they the same think logically speaking and simply have different content and values?

Yes, a generic Character or Actor class is usually a good start, in complex games it may even bee too specific already, Entity would be the most basic object, with just the minimum data to put a static thing up there in your world and have it go through all your systems properly (render, collision, audio, rtc.)

The best code design (IMHO) is the one that provides clear processses and easy ways of adding new stuff, take for instance the character, you start your development and want your character to be able to move and to have a melee punch hability, so you make the character class and implement those habilities into it.
A month later into development yo decide the character needs a secondary ranged attack you didn't plan for originally, spaguetti code enters!
Instead if at design time you acknowledge characters will have an undetermined number of skills, and that different characters will have completely different skills, you'll realize that what your character actually needs from the code is to have a dynamical skill system which you can add from script or some other simpler source like config files.

Different languages have different properties, advantages and disadvantages, the goal is to use the right tool for the right job, if your game is rather small and you are most familiar with C++ and already have an engine up and running, don't try to bring in a second language, unless you need to or unless you are just aiming at a learning experience rather than a finished product.

Another combination that wasn't mentioned comes in when games use databases, you'll have to integrate SQL.

Lets say you are aiming at a learning experience and go back to the script purpose usage of light languages (C#, LUA, python, AS) combined with C++ for performance.
What you want with a script language is a way to change the stuff that is most likely to change by design quickly and if possible on the fly, without having to close the app and compile and so on.

Take collision detection for instance, finding out if two boxes are overlapping is a rather rigid algorithm, you'll write it once and as long as it works ok you'll probably won't touch it again except perhaps to optimize some of the math. What you do when the collision happens on the other hand, is a design decision, for instance, object Bullet collided with object Avatar, C++ will tell you that happened, then you go to script, lets suppose its LUA and call the function AvatarGotHit, there you will take out HP points from him, the game designer then wants to add a shield, that protects from damage, then he wants the shield to be useless if the avatar was jumping at that moment....

You get the idea, the most efficient use of a scripting language is to use it to interpret a certain event that can be highly circumstantial and decide what to do about it, the actual doing of that will usually be best done back on C++
It is also, as has been mentioned, very useful to the balancing process, you have the "Jump" function in C++, how high the player can jump would be a number to be read from the Scripting language, that way the game designer himself can take the player, jump, change the jump height and try again until he likes it without bothering a programmer once.

While the approach infectedbrain suggested is exponentially inefficient, there are a few questions that need answering before throwing him to the mess that can be a space partitioning algorithm.

How many objects would your current project have? if you know the answer, chances are you won't be needing any kind of optimization, if the answer is in the thousands or undefined, then we are in business.
As a general rule, unless you are making an educational proyect, unnecessary optimizations are undesirable. If you already have the optimization algorithm at hand you might as well use it, if you want to learn it, do it, otherwise you may be headed into one of the biggest time wastes in development.

If you need to optimize your collision detection you'll probably need to apply a couple of techniques, as others said, tree like structures are one of the most popular methods, they are different ways of applying the same technique, which is space partitioning, breaking down a large, possibly unlimited space into smaller parts where you can fit stuff in to get a certain knowledge of proximity.
If your game had rooms for example, it would be pointless to test for collision between two objects that you know are in to different rooms. That is a space partitioning, you define that rooms are separate spaces and objects cannot be in two of them at the same time.

Another good optimization is avoid checking collisions between static objects, since they usually make up for most of the population of a world. If two objects are truly static, even if they are in collision from the beginning, that is likely as designed by the level editor. If objects are subject to a physics engine, but do not move on their own, its good to flag them as being in static condition when they have found a resting spot. If your objects are mobile those are the ones you need to check all the time.

You can always dig deeper and there is no "best" optimization, they are all good for some cases and bad for others, and as I mentioned before, the cost of research and implementation HAS to be taken into consideration, even if it is the BEST optimization ever.

I've been in the industry for over 5 years, I got into it by following a GD career in a private institute, not that the institute itself means anything, It just allowed me to meet people already in the industry, work with and demonstrate my capacity and worth, so they recommended me.
In my experience most people get in that way. Its very rare to BE a professional game programmer before working at it, the work makes you a professional, not the other way around.

A lot other people get in by starting with an entry level position, QA being the most usual, and then demonstrating you have other skills.
Finally, whenever you have an interview the best way to prove you can make stuff, is having stuff made that you can take on a laptop and execute in front of the guy interviewing you, having an executable game (and the open code to back up that you made that, is half the battle, then you'll probably be queried on the tech and language of interest for whatever position they are looking for.

Make games, pick up a tech that gives you a head start and make something that works with it, Unity and game maker are good choices, if you want to go more heavy on programming, take XNA or AS.

Boy am I gonna be yelled at...

Are you adamant you will only have one logger?
Being so it should be available from pretty much everywhere?
Passing around references seems pointless?

So... why not static?

I think you should avoid to overdesign, the simplest solution is usually the best one, if it gets the job done and doesn't impact your development speed, go for it.