Think on what you most like. (theme, ambient, climax, style, etc.)
Think on what is there that you generally like to play, think on why you like it, think on why those arent enough for your satisfaction anymore.
Think on something that would fulfill what those things already there arent fulfilling. Somethink youd like to play but doesnt exist.
Elaborate on that. Create mockupts, than prototypes. Dont lie to yourself, youre the one who will play it, do you really want to play it?
If fail, start again (think on why it sucks, compare to existing things, than think in another thing), if its going great, keep improving.
The problem you can face is only being able to think on projects that are too big (next gen mmo). This is a problem, if you cant see the charm of small but really charming and stylish projects, I dont know how youd go about it.
"Think on what you most like. (theme, ambient, climax, style, etc.)" -> try to apply those on small scale projects, maybe think on retro or gameboyish style games.
If theres isnt anything like youre imagining out there, good! Youre about to go original ;). Its hard, cause theres no references, but than remember to not lie to yourself ("do you want to play it?")
I play fallout new vegas in nightmare mode, where even the ammunition weights, and I say it contributes to immersion a lot. Theres no currency, you can trade every junk for..junk (cause bottle caps are the money), and even pre war money are just like more junk.. Killing animals will just give you (not allways) his pieces, like wings, poison gland or skin, I love that game <3.
What you carry is a major gameplay element, you have to make clever choices, and even your character stats goes in there. You need to resolve between food, money and distance between your next destiny.
You need to think what works better for the game your doing, not for a general golden rule. If your games have that survival aspect focus than having a snake dropping money will kill immersion IMO.
I recommend getting into a game jam to forcefully push you in the 'productive' mind set, its really a revealing experience: no time for over thinking, only for vomiting working code as fast as you can ( you do with what you got, your current experience level, instead of thinking in the best way possible you do in the best way you can). Its good to show yourself how much you can pull of.
The scary part is that that "method", at least in my experience, is faster for progressing than the "over thinking till you got the handsome solution". I find that you learn more by trying more in short times with lots of mistakes and redoing than spending too much time trying doing it perfect in the first try. Its really a mind set thing, generally in the over thinking mindset you go slow, stop, analyse, you dont give another step before be sure, etc..
In the "vomiting way", you make shit work, than you realise what makes it shit, clean it, still working, figure out some bugs, redo it..its more experience, faster. And its more rewarding cause you actually get something to toy with (cause its already working even when its shit)
UVs are necessary for "sampling" (grabbing texture pixels on shaders) textures on both direct3D and openGL.
Theres no way around it, its not to save memory, its for accessing the texture pixels (more correctly, texels, as pixels are on the screen).
So if the software/lib you used where using one of those apis, they are handling this for you.
Note that theres no "2D" concept on those apis, GPUs are rasterizers that read vertex data to shaders, shaders will work on that data and output to render targets (textures displayed on the screen).
The "3D" or "2D" is all on the api users responsibility, its all about transforming points with matrices. Those points are rasterized to the screen accordingly with the topology specified on the api (lines, triangles lists, etc.).
So, if theyr necessary for 2D game programming depends on what level* you are, if you using those apis directly you certainly need it. If not, dont worry, its being handle for you.
(*level as in low-level / high-level, not as in beginner / advanced )
Now, to draw things without those apis these days, I dont know if its even possible..Even windows GDI uses direcX underlying. So I dont know...Im curious, how Flash applications are drawn?? o.o anyone knows? Where are the vectors translated to pixels?
Also, what do you mean by atlas? Do you mean a map?
UVs are the texture coordinates, from 0.0 (top left) to 1.1 (bottom right). Is how you get a portion of the texture.
An uv is specified for each vertex of the mesh you want to draw. Is how you map a texture to a mesh.
In the case of a sprite, you have a quad (or 2 triangles), means 4 points, so you have 4 points and 4 uv coords.
A texture atlas is a texture inception ;D. When you take a lots of texture and merge into a single texture (like a tileset or sprite sheet). This is good for performance as changing texture is expensive, so if you manage to have all images possible into a single texture, you will never remove the texture from the GPU memory, win \o/.
The second one arent even rects, its insane, as each sprite would need to be a different mesh.
I have my own texture tool where I can pack a bunch of sprites into a single atlas, it saves each 'frame' uv rect to a file. So the order they show up are random.
Note that for animated sprites theres a problem with trimming transparent spaces, as you need to keep the frames from a single animation relative, so if in a frame the character is with arms opened and in the other closed, the frame would bounce as the position of the character wouldnt change, but the frames have different sizes. (generally ppl let transparent areas untouched, with no trimming. In my engine each animation frame have an offset to compensate, so my texture tool do the trimming and computes this offset needed to keep the animation correct, based on the amount removed from each side).
Players dont know what its good for them, designers do..supposedly.
Designers should design theyr game with the reward thing in mind, The entire pacing and levels of the game should be based on that, depending on the game its more or less important.
If I put a text file on the games folder where the player can simple change the start level, the game is ruined ( or not, but depending on the game, certainly). Making the argue that "its player choice" to me is simply bullshit, as in the end, it could ruin the experience and even screw the game sales, as the game would became less rewarding (anyone could just check out all the levels, without even figuring out theyr just screwed all the intended fun the designers planned, and spread bad mouths about the game).
Giving all the juice to the player for free will never be a good design choice.
If you want to give that power to your player or not, is still the developers choice. But its certainly NOT the case that it should always be allowed.
For my game, I have this idea that after he beats the game I do give lots of juice to them, like the frame by frame ability I use on debug mode, etc.. But just after beating the game, if he finds out how to do that since from the beggining, hes not having the experience I planned, it may change his entire view on my game, in a very bad way..its his fault, but who cares, it cant turns against me.
In my engine, systems work on single components. When a system traverse a pool of its component type, after each component update it sends an event to the object owner of the component, interested components (attached to the same object) will receive the event and update its data accordingly.
For example, my Transform system traverse all transform components, updates its final matrix and send a transform event to its object.
Right now I have 2 components that register to transform components, the collider and the sprite component.
The collider will update its pos by getting the trafo received and adding its own offset.
The sprite will update its "renderWorld" matrix. (its more complicate than that, I actually need to see if the render and current differ, and than interpolate, since its a fixed time step loop. This happens on the sprite system loop, not on the event receiving.)
As you can see, I need to update systems in order, this order is decided when I add the system to the game.
With this event technique I dont need to care if the object have or not components that need to be informed, I could have pointers on components pointing to interested components, but that would be a pain in the ass to manage. The object can change in real time and it keeps working, no need to change anything.
The bad thing is that when I create a new component class, I need to be aware of all components and make the appropriate eve registration on the VOnAttach method.
Say I want to create a rigidBody compo, I will probably want the transform component to register for rigidbody update events, and make sure the rigidybody sys updates before the transform sys. The good thing is that if I want to create a component that need to receive transform events, I just need to register, no fancy interaction.
When it comes to entity talks around 'google', theres always a mention about hacking the gameobject by putting pointers to most used components, to speed up things. For a specific games where you know your objects will always have components x, y, z, you could just create a special case game object that speed up interaction between x, y and z.. (You can see that in Unity, you cant take out the transform component.)
I dont believe much in the "no game object actualy needed", making it just an abstract concept. It just introduces lots of complications, and Ive never seem anything like it other than chit chat (by ppl who actually never implemented it).
Each component have a factory, the factories are the ones holding the pools. The systems grab a reference to the pools on construction.
A factory need a createCompo method that can create an un-initialized compo and one that receives a "gfig" by param. gfigs is something like a parsed xml file that I invented.
Theres a object factory that have access to all compo factories and it can build entire game objects from a single gfig file.
Ok, the problem was the copy ctor, that didnt exist, so I basically create a cpy ctor that doesnt copy anything (act just like a normal ctor).
The rule of tree is quite annoying, having to implement all those methods every time a new class is born? not knowing if you will or will not ever use it...whats the policy for this? do it fanatically no matter what?
I wish I could spot this kind of issue ahead of time and do it just when necessary like in this case.
Hmmm.. I think will create a macro that create private empty "rule of tree" methods and put that on every new class, so things like that will popup sooner, and then I can implement on demand..
So you can have a materialDifuseCoefficient and a materialAmbientCoefficient (and a specular..), both affecting the unique material color, or split in two colors already(a difuse and an ambient (and specular), but this is less intuitive).
id like to document my code without having to adhere to something ugly like doxygen formatting..something like a built in functionality on your ide that reads your code, creates a template and let you select and tag any comments to make it appear correctly on the documentation.