Out of curiosity; what did you write your game in?
If you wrote it as a web app, cool enough. Cross platform.
If you wrote it in ObjC and then wrote it for PC (Or the other way around),
how come you take time to port everything and still feel that you need to ask here?
Or maybe you're using an ObjC compiler for win or 'nix?
(Your earlier post included, it sounds like you're ready to publish to PS3 or PSV, Xbox360, PC, IOS and perhaps even Android)
Either way I'd love to know what language and tools you're using.
I agree that an IDE can make things seem more complicated than they are/should be, but with the right guidance an IDE is fine.
If you take some time to read about the different parts of Eclipse or Netbeans, and how their UI's are laid out, you'll be fine, perhaps even better off than without using an IDE.
It won't be long before you'll encounter an error, or before you'll want to add a break to a line, enbaling you to step through every statement in your code - and that's much more complicated without an IDE, IMO.
The things you need to focus on from the beginning, regardless what IDE you'll be using, is (1) The code view (that main area that you can type into) like mainstream text editors, it allows a tab for every open source file.
(2) The project explorer (that bit showing your project, the contained packages and the source files as a tree structure)
(3) Basic project settings, where you can add some jars to extend your project with. This will be more important later on, but it's essential for setting up a project in the first go.
The rest will in my experience both as a TA and a developer come gradually.
Of course, for the very first steps it may be easier for some to go without an IDE, like Nercury says. Check Oracle's first lesson on the topic. But again, I wouldn't call it a gamebreaker if you start with an IDE.
Ah, alright. I was wondering because I didn't see how that would keep it from appearing in your original post.
Thus i thought you meant when you started your latest project or something along those lines.
Your original post mentions nothing in regards to the time of original release.
I don't think I heard of Tetris until sometime in the 90's so during the first 10 years I was programming it never occured to me to rewrite tetris as I had no knowledge of it. After I heard of it for whatever reason, I still have had no interest in writing it. I know I've seen many rewrites of it but it doesn't pop into my INTP brain as a commonly written game. That's why I'm asking y'all to find out what I've missed!
Ok, i get it now. I also reread your first post how you intended it to be read. Until now, I thought you wanted us to list game types that we see written over and over again,
but I get now that it's about game types that we revisit and write ourselves, over and over again. Gotcha, Mr. Old-school.
As iMalc said about the self-playing tetris game, -that's actually quite fun to watch. Give it some rules for how frequently it can "tap the keys" and watch as it plays.
A good excersise on everything from a very basic AI to a very advanced one. Plenty of room for AI next to a relatively small game in terms of lines.
How about a chapter on LOD and other mainstream approaches to gain tradeoff in perfomance by faking or deferring items otherwise rendered at full detail/resolution, every frame or by recycling stuff used elsewhere? It's deep and could touch instancing and impostors without digging too deep.
I can see how just organizing the chapters could be a challenge...
I've learned some C++, I've learned some SDL, and am now understanding DirectX 11. But I know I can't possible learn it ALL.....
When I think of the pro's, the experienced, the people who use their incredible skills of math and programming to make video games, I sometimes wonder, just how did they make it there? And knowing how they've made it there, just how good are they? These questions I hope will give me an idea to just how smart I should get in order to become a more sucsessull programmer in the future! So hbu? How much do you know?
Sounds very glorifying for professional programmers. Many pros are in my experience very flawed. (Myself included)
They can often be arrogant and cynical. Our code also tends to be sloppily written at times. We may be doing something too fast,
and as I often respond when someone points out a bug I introduced; "Well, the more you do, the more errors you do."
The developers who go home and "work" there as well, are the ones who are willing learn more. They're hungry for it, otherwise they'd go home and watch TV.
I think this is basically what makes some people stand out. But a lot of developers are passionate about their craft.
And the trees do of course, not grow to the sky. Some are better and some are worse. But there's far between the superhuman dev cyborgs you see hacking away in movies.
Just find something you like developing and stick with that. -Then expand your horizon and never stop doing so.
so you mean that every game made is made with opengl or direct3d ?
No. He said that games could be using
C: Your own drivers and custom API
D: The drawing API provided by the OSes of choice.
Naturally you can also create 3D games using C and D. Take a look at Quake, for instance.
That's software rasterized polygons. Simple 2D raycasting can be used to create games like Wolfenstein 3D (and Doom, if you're clever)
You can access much in cross-platform drawing through the use of browsers. It's easily the most cross-platform way to create games, and doesn't necessarily depend on OpenGL (That's the browser that decides on rendering.)
So there's no rules as of what to use where.
Only it's probably more common to use existing API's for Hardware acceleration when developing 3D applications (As Olof said, most modern 3D games use them)
Naturally, higher level frameworks and libraries such as SDL allow even more abstraction than basic DirectX and OpenGL.
But in 2D intersections (being points) don't have areas... at least, normally they don't...
This looks like a 2D question, though. And it's a nice drawing. Is it a puzzle?
Would you like to determine the number of intersections between the rectangles?
Are all other rectangles overlapping rectangle #1?
If you want to find the coords at the intersections of "overlapping" rectangles,
you could use a parametric test between a point and all rectangles that the point does not belong to, and contain the point.
If you're going for the total area, and you know that every bit of the outermost rectangle will be filled,
cozzie, on 28 Jan 2013 - 12:50, said: for(materials=0;materials<nrMaterials++materials)
The for condition is invalid AFAIK.
cozzie, on 28 Jan 2013 - 12:50, said: for(meshes=0;mesh<nrMeshes;++meshes)
There's no mesh mentioned earlier in your pseudocode.
cozzie, on 28 Jan 2013 - 12:50, said: if(materials[material].index[meshes].uses = false) continue;
The = is an assignment, not an equality operator There's no material mentioned earlier in your pseudocode. materials is not an array
Please, even when posting pseudocode, be consistent. We cannot see what the problem is if you obscure it in typos. Also, when it's a small snippet of code which has flow errors, it's probably better just to post the code.
You're running on Windows Vista, 7 or 8, right? - Open up the classic "Computer Properties" dialog by right clicking Computer and selecting properties, or launch "System" from Control Panel. - From here you select "Advanced System Settings" -> (Pick the "Advanced" tab if it isn't already selected) - Click the "Environment Variables..." -button. - Find the Path variable under "System Variables" (Or user variables if no other user would need it) - Edit it and inserrt "c:\mingw\bin;" at the beginning of the line, without the quotes. (Assuming c:\mingw\bin contains the compilers you'll be using...)
@supervga, I wish I was using a scenegraph at this point. I decided i want to try something fancier. The game has a simple array of game objects it loops trough for updates. Each object has a transform that has a parent, which makes up my "scene graph". After all the game objects are updated they recalculate their world position, resolve any collisions and are then rendered.
Rendering is done trough a render component, when one is attached to an object it registers with the render manager. After collisions are resolved, the camera determines which objects in render manager are visible. Each visible object gets its mesh data and world matrix passed to opengl to be rendered.
Is this design too convoluted? What might be a better way to manage these entities and still not be dependant on a scene graph when updating an object?
I too think it seems like a fair number of updates (on every object) if you have a low amount of objects.
The peculiar thing with your set up is, that you perform transforms upwards (or, at least, on every item you consider the parent and so forth)
Where you'll find it more straightforward to start from a root node.
I can fully understand if you don't want this; if all your objects are dynamic and independent of oneanother, there's no reason to bind them in a transformation tree.
But this doesn't mean you cannot use optimizations for updates and collisions.
You can also optimize by having
1) a resting flag that is raised when the kinetic energy in the object has run out. (Object stops moving seconds after hitting the ground, etc.)
2) Creating a grid of sectors that each contain a list of references to their contents.
When computing collisions, you can prune objects that are x sectors away from the current object (based on how large objects and sectors are)
If you want to take it a little further, or have a lot of objects, you should look into using Quadtrees (Random, seemingly interesting quadtree article here)
It sounds like you're using a scenegraph, so can't you push transformation matrices when you visit the children?
With for instance glPushMatrix() (I don't know if you're using opengl), you can render the children at their relative coordinates.
If you're going for collisions, you might have to at least do world space bounding boxes...