The system I have developed for my 2D platformer doesn't deal with square collisions object, but polygon collision objects, which are split up into triangles to check for perfect collision within these triangular shapes.

I obviously have quite simple collision polygons, but they still give more precision and look nicer than just square collision blocks, and as the collision polygons are obviously invisible, and all that's visible are the tiles and the sprites, which gives you a pretty good illusion of an almost pixel perfect collision system.

This also allows for slopes of all angles very easily.

To make sure that I don't blow out the RAM just to check for collisions, I make sure to have as few block objects as possible, and I make sure that as few blocks as possible are checked at the same time. For this system to work, it is important that I add the blocks in the right order, from the beginning of the level to the end of it.

To make sure that I have as few blocks as possible, I simply allow every block object to have a repetition parameter, so that the same block can actually be as many blocks as I want to. The reason I do this is because the collision algorithm works much better when using several small blocks than huge ones.

To check for collisions, there is a for loop that goes through all the blocks of the course, but it breaks itself if the next block it checks is out of range, so that it doesn't have to check more blocks than necessary, and there is a variable to keep track of how far you are into the level, so that you do not loop through any blocks behind you either. So, mostly, thanks to the repetition parameter, mostly just one block or two is in the loop at the moment. Then there is, of course, another for loop within this one to loop through the repetitions, but like I said, this only happens for one block and then the loop will break, so it isn't slow either.

My workplace<3

For the sake of poo, look at the full size: http://i375.photobucket.com/albums/oo191/Skomakarn/skerm.png?t=1265935207

3360x1050.

No, Microsoft's stuff will not do what you want.
Visual Studio and its compiler doesn't work with standard C++, and you will get crap, and also get laughed at.

If you're on Windows, I suggest programming in Code::Blocks. It had code completion and a lot of other features, such as creating little or large macros of your own. For example, I've made one to generate my header and source files' main structure as long as the files are named according to the classes and the project is correctly named, as well as the date of the creation of the file.

The IDE isn't the most important part, though. You might as well code in Notepad (but obviously, you shouldn't). The important part is the compiler, and on Windows you should use MinGW, which is a Windows adaption of the standard GNU C++ Compiler, which you would use on Linux or Mac. You can get it bundled with Code::Blocks from the Code::Blocks website.

I don't really like developing in Windows, though. I prefer programming on Linux (although as far as I know, you can use the real G++ on Mac as well, but I can't afford one at the moment). Some stuff is just a real pain on Windows at the moment, but I still always program portably, and you should too. Having to port later on is not enjoyable.

I guess I would be open for coöperation with anybody who's interested. Sounds like fun. Would be great if you fancy my ideas, which I've been working on and thinking about for quite a while now (although, like I said, I just started over, to actually make an engine of my own, instead of a wrapper).

My new attempt is using SDL 1.3 for the window and events and threads, and the GL3 library (the OpenGL context uses OpenGL 3.2), but I'm obviously wrapping this up. If somebody could create a set of portable threads, portably check for input, as well as create portable windows with support for OpenGL 3.2, I'd be happy to use that, though.

My event system is based around event receivers, which are objects of classes inherited from abstract superclasses, such as WindowEventReceiver, and ultimately from EventReceiver. Some objects can take one type of event receiver, and some can take several, but no matter what, objects that accept event receivers allow you to add just as many as you like, using the member function addEventReceiver(), inherited from EventSender, which takes a pointer to an EventReceiver object. Thus there is some polymorphism going on.

It's multithreaded. Events are handled in single threads, and graphics are drawn in a single thread as well. The main idea is to have to write very little code, while still being in as much control as you need to be. You only need to create the window, and it will automatically appear, and keep drawing graphics and stay running as long as you have a loop that keeps the program running, because without a program loop that you maintain yourself, you're losing too much control in my opinion.

To further utilize this philosophy, the 2D and 3D concepts are based around nodes, interfaces, scenes and animators. A node is basically an object with a position, rotation and scale and the possibility to accept animators. These nodes can then be modified equally, and polymorphism is the main idea here.

2D nodes are put into interfaces, and 3D nodes are put into scenes, but those are pretty much alike, and the main difference is the third dimension. Only one scene/interface is allowed as the main one at a time, but they can contain subscenes/subinterfaces. New nodes are automatically added to the current interface/scene, and are automatically drawn as long as that scene/interface is the main one, or belongs to the main one as a subscene/subinterface, but can be set hidden.

Animators can be added to nodes to perform FPS independent transformations, such as moving them around, rotating them and scaling them over time. Animators update the attributes they are modifying automatically, but they have to be started, and can also be paused and stopped.

You're doing too much! D:

Remember when you initialize an array that it's counter starts at zero!

Doing, for instance

Code:

int array[30];

Actually gives you the value range at and between 0 and 29.

So if you tried something like this(which seems to be a somewhat-typical beginner error)

Code:

for(int i = 0; i <= 30; ++i)
{
    array[i] = 10;
}

You're bound to run into issues.(which is why I doubly recommend the != operator for for loops. i != 30 would work perfectly fine.)

I usually stick to the < operator (and I usually use vectors [and I don't like iterators]).

Yeah. Even if you're learning through a tutorial, a complete API documentation is always handy if you want to look up stuff on your own, and find out about every detail that's not covered in the tutorial.

Also make sure you write Doxygen comments all the way from the beginning, so that you won't have to do that later. That way, you can easily generate an HTML documentation for your library.

In addition to this, remember that a generated documentation is not a replacement for a proper hand-written documentation.

Of course not, but that way you at least have the opportunity to quickly and easily generate a good HTML documentation.

I don't think you have to complement it with another documentation, though, but rather with some good tutorials to get the users to understand how the engine and the library works.

I recently started working on an engine, and what I find very important is portability. Portability makes the engine all that more attractive to work with.

I don't know what you're shooting for, but it's common in many engines to define a lot of basic things of their own, such as string classes, instead of using the std::string. My engine has its own string class and a lot of other basic things of its own.

Just make sure it's well-structured. You're using C++, so make use of classes and generics. They are your primary tools for writing well-structured libraries. Give comprehensive names to the classes.

Also, make sure that any file can be loaded individually. You shouldn't have to load the entire library if you don't even want to use half of it. Also make sure you write Doxygen comments all the way from the beginning, so that you won't have to do that later. That way, you can easily generate an HTML documentation for your library.

Sounds cool! I haven't checked this thread in a while cause I've been swamped lately.

Also Unreal and Unity3D are now "free". (or at least, more accessible and reasonably priced than they were)

But I guess if I think about it long enough, there could still be room for a 2D game engine of this type.

I'm starting to lean more towards rewriting it from the ground up though. hmm...

I don't know anything about Unity3D, but Unreal is Windows only, and the free version doesn't allow you to work with it in C++.

A free, platform independent C++ library would definitely still be something (I know there already are some, but you obviously knew too before starting on this, and they're fun to write, and if they're good enough, there will always be somebody using it).

Like I said, my library also contains its own basic classes, and for example, its own string class is used for everything within it, so that it's really easy to work with strings, and you're safe to use that class too, without any struggle, since everything in the library supports it and it has implicit conversion to const char *.

I've also written my own file stream class, together with a file class, for example, and they both use code only from the standard C I/O library, so that you don't have to include anything additional to work with them.

Then there's also a date/time class, some timers, stacks, maps and so on, among the basic stuff. Some of this will be rewritten for my new attempt, too.

I'm basing it all on SDL 1.3 for windows and threads, and on OpenGL 3.2 for the graphics, so I guess it would be easiest to simply include these along with the library, so that you get it all at once.

I guess it would be fun to coöperate, too, if you're starting over, which I too did just a week or so ago. I'm currently implementing the window part of the event system.

I'm working on a C++ library/engine. I don't only create classes that are specifically fit for games, but also my own String, Vector and stuff like that. If you're interested in borrowing these (kept in the vatn namespace, which is the name of my library) or looking at them for inspiration, just tell me. I'm currently rewriting the String and Vector classes, though.

Object/component/node management is obviously a big and important part of game programming, but containers and strings are obviously also things you will have to deal a lot with, and for that purpose, I have made my own classes for this, since I simply don't think the standard classes suit my needs (and I don't like their naming convention xD).

I haven't really looked at what you are doing yet. Just the first post in the pseudocode thread. I don't really fancy the Microsoft style naming convention, using capitals to begin function names, but consistency is obviously of the most importance. This is still way better than the STL.
I will look at what you are doing some more. If you want to exchange ideas and find out how I solve things in my library, it would be fun to have a chat.

We are working out a lot of ideas at the moment, and we are trying to make a design document, and we have taken your comments and suggestions into considerations, so we will hopefully have a little update in a while now.

Oh, yeah, I guess that's something worth stating as well, I guess.

I am using (actually currently working on) a library of my own, which is a wrapper for Irrlicht (2D and 3D graphics), irrKlang (sound) and SDL (threads).

I might be adding networking functionality later on, using SDL_Net.

I checked C/C++, C# and Other, but I really only use C++ at the moment, but when games eventually should be ported for 360, C# will have to be used.
By Other, I meant Objective-C. I don't use it at the moment either, but we have plans on developing for the iPhone, which forces us to use at least a little of that.

For a game with such a mock-Japanese title, you could go with a more appropriate aesthetic, as well; the serious Egyptian background and textbook fonts make it look like some game a Macbook would come packaged with - very sterile and ancient. If this had a more vibrant, humor-based aesthetic, I would totally buy it.

Take a closer look at the statue in the sand. ;3

I force thee you give it an Icelandic name. I named our last cat Eldur (male name meaning fire, because he is red as a... fire).
Name him Jökull.

Hah, that's so weird. At one point we were singing Patapon music when we were working.

Oh, hi. I'm the lazy composer mentioned in the first post btw.

Haha, yeah. Our voices blend so well together.
Singing Sloprano is probably what helped us finish the desert level.

Woah, I would never give up after spending three entire years on something. Never.

Yeah, but I mean, they don't look like failed attempts. They look like they would have turned out great, if he had only finished them.

I only watched the video, but I understand the concept.
Seems like a fun idea, but the game looked a little too slow at times.

This is definitely something that could be fun at first, but I think you will have to change the concept a bit over time if you want to keep the players hooked, and also increase the speed of the bubbles. Not necessarily from the beginning, but at least make them a bit faster over time.

Great concept, but it will need variation after a while.