Posted by NEXUSKill
on 14 February 2014 - 02:40 PM
Well there are a few factors to take into account, mainly the nature of the software and the target audience/consummer.
If the consumer is likely to be tech savy, they'll want to be given a certain degree of control, if not, they'll likely expect you to do everything for them.
Personally I hate resident processes, such as the google updater or the adobe auto updater, I hate a program being there running consuming my computer's resources while I'm not even thinking about their software, adobe reader is probably the worst example of this, you open it what, once every coule of months? meanwhile adobe has a resident software active on your computer full time, why? why does that need to be there? Steam on the other hand, can be set so it doesn't start at bootup and will only update when you start the program.
Thats another issue for me, unless the update is absolutely required for the software to function, when I open the program I want to use it, making me wait for an update is an inconvenience, if the update is optional, I would prefer to delay it to when I close the application and no longer care about it. Thats the way I handle windows updates, I apply them once I decide to shutdown the computer, not when I want to use it.
Taking the user to a website is pretty old school and annoying, its not even necessary, you can trigger the update download and instalation without going anywhere, do that.
Levels are not game states, levels are content of a game state, specifically, gameplay, Game states are used to sepparate contexts of your application that have radically different logics, a menu is very different than gameplay, and maybe you have other states, like a world map and a battle stage, the logic in each of them is very different to the others and there is a connection between them, look up state machines. Between different levels, the logic of the gameplay itself is likely to be more or less the same.
As for levels, if your game is linear you could have a simple array, if the array is too big it might be more clear and efficient to hold a link to the next level within the current level itself, maybe in the exit, so if you have multiple exits you can use a different link in each one. As for the transition from one level to the next, you just initialize the Gameplay state with a new level as content, maybe put in a loading screen if it takes a while.
Posted by NEXUSKill
on 22 November 2013 - 10:00 AM
I'm thinking of putting together an article for flocking and steering behaviors, the working code I have now I cannot share due to contractual obligations but I can make something on the outside and get a working demo of the technique.
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.
UPDATE: I've asked around with some engine developers, apparently the biggest bottleneck in consoles and PC right now, is texture size and count, however states may still be a big deal on mobile platforms.
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
... 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.
Posted by NEXUSKill
on 06 November 2012 - 07:48 AM
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.
Posted by NEXUSKill
on 02 November 2012 - 10:39 AM
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?
Posted by NEXUSKill
on 02 November 2012 - 09:36 AM
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.
Posted by NEXUSKill
on 01 November 2012 - 12:55 PM
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.
Posted by NEXUSKill
on 26 September 2012 - 12:23 PM
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.