Need Software and Engine Recs

[Kyanbu The Legend]

Okay a few questions.

1. Does anyone know any good animation software? Perferably something cheap/free that isn't pirated.

2. Does anyone know any good engines that I could use for a side scrolling 2D game? And one for a shooter game?

3. Any good tuts on how to code areas and sprites?


I'm trying to get back into studing programing and game design again. So I wanna mess around with a few things.

[Ryong]

For game making, I'm going to suggest you to use Stencyl. Dunno 'bout the others.

[rpgdemon]

Well, what do you mean by an engine? It sounds like you want something that's got most of the work done, and you can just drag and drop assets into, which isn't the right way to go about thinking about things.

[Kyanbu The Legend]

Tutorials on build game engines will help too.

[rpgdemon]

Look into the XNA framework. It's a library of stuff for C# that's free from Microsoft, that is meant to ease game development for both the 360 and PC. It's well documented, and a quick google search should be enough to get you started.

I've been part of development for two game engines using the XNA framework (After doing one, we found a lot of things we wanted to handle better, and started the second), and can say that it's pretty solidly competent. C# is, despite many complaints against it, actually a really good language, as long as you're not looking to do a lot of low-level work, which you will not be doing.

How much programming experience do you have? A lot of what I'd suggest depends on what you know. Like, if you know nothing of object oriented design, learn at least the basics of classes, objects, interfaces, and then come back to game development. If you know the basics, you can probably get away with that, working with XNA. It's very well documented, and there are many tutorials and examples of code, so that is my suggestion.

[rpgdemon]

Also, on building an engine: I'm on the fence about whether or not I'd suggest doing that, or to what extent I would suggest doing it.

On the one hand, it means you get exactly what you need, handled how you want. On the other, there are many engines already available, that you don't need to worry about the complexities of how they work. There are varying definitions of what makes an engine to take into account, as well. As such, I'll be suggesting libraries that can very nearly be called an engine, if they are not already called one.

One such option is Flixel. Flixel is an open source library for game making in Flash, and it's pretty sweet. I've played around with it a little bit, and it's a very solid piece of work, in the best way possible. Flixel was what we originally modeled our first XNA game engine after, because it was so well designed. If you do not have a problem with developing for Flash, definitely give Flixel a look.

To get set up with Flixel, you'll need FlashDevelop, which is free. Install it with the Flex SDK, or else you'll also need to download that. Flixel can be found here.

[rpgdemon]

If you want to use XNA (Which I would call harder than Flixel, because less is given directly to you), it can be found here. The getting started ought to have everything you need there. You will need Microsoft Visual Studios, which you can get the Express version of for free. The express version is limited in what it does, but you will likely never run into those limits. (It doesn't allow internally for any sort of hookup to an online code repository/version control, as an example of those limits)

[rpgdemon]

Re: Animation software: 2D animation doesn't really need it. You can just string together still images that are developed in GIMP or Inkscape or Paint.net. For 3D animation, I can ask people, if you're interested in that, but a lot of the stuff I know requires monetary investment.

Re: Coding areas and sprites: Wut? If you can clarify what you mean, I can help you here.

[Kyanbu The Legend]

The animation software is just for trying out and practicing animation. (may lead to the making animated cut scenes in the late future).

As for coding Areas and Sprites I meant doing it so that my sprites don't walk through a floor. (I had that happen when I attempted 3D platforming in my Intro to Programing course back in good old Camden County College before they kicked me out for being poor.)

If it helps any, I have an understanding of programing. So I'm at entry level.

[rpgdemon]

Sprites... In a 3D environment?

I'm going to talk 2D collision detection, because it's easier, and it somewhat can be extended to 3D objects, by doing the detection across multiple planes. By far the simplest 2D collision is plain old hitboxes.

The basic idea behind hitboxes is this: You have a box that approximates the shape of each object that you want to test collision for. You then check if those boxes are overlapping, and if they are, the objects have hit eachother.

The way that we set it up in our own engine is that we had a separate function to test for collisions, which would be fed in two Sprite objects and returns a boolean True or False, though you could easily have it as a method within the Sprite class, which gets in another Sprite, and this might be a better method if you do not have an always available class to work within. The reason that we did it our way was because we were caching image data for per pixel collision in said State class, and it made the most sense to have all collision detection handled within State.

So, the babble about how we set up our engine aside, here is how you go about testing for collision between two rectangles:

                if (((rect2_left >= rect1_left && rect2_left < rect1_right) ||
                    (rect2_right >= rect1_left && rect2_right < rect1_right)) &&
                    ((rect2_top >= rect1_top && rect2_top < rect1_bottom) ||
                    (rect2_bottom <= rect1_bottom && rect2_bottom > rect1_top)))
                {
                    return true;
                }

                else if (((rect1_left >= rect2_left && rect1_left < rect2_right) ||
                      (rect1_right >= rect2_left && rect1_right < rect2_right)) &&
                      ((rect1_top >= rect2_top && rect1_top < rect2_bottom) ||
                      (rect1_bottom <= rect2_bottom && rect1_bottom > rect2_top)))
                {
                    return true;
                }

In this example, rect1 and rect2 are the two rectangles. rect_left is the X coordinate of the left side of the rectangle, and rect_right is the X coordinate of the right side of the rectangle. Likewise, rect_top is the Y coordinate of the top side of the rectangle, and rect_bottom is the Y coordinate of the bottom side of the rectangle.

So, this is collision between two rectangles. If you want to do more complex shapes, it can get to be more annoying, so I'll leave it at that. Per pixel collision, which I mentioned above, is somewhat contingent on implementation details, but I can give a rough idea of how it works:

First, find out if the rectangles of the two images overlap. This is an important step for a few reasons, because per-pixel collision can be taxing to do, and if you don't have to do it, you don't want to.

If the two rectangles DO overlap, you find the resultant rectangle, and test each pixel within that overlap region to see if they are both set to what you consider to be visible. This is where the implementation details get in the way, because how you get the data of the pixels can vary. If two pixels that overlap are both set to be visible, you return true, and are done. If not, you return false.

You can use per-pixel collision detection to create a collision mask, as well as test if the two images collide. If you wanted a really oddly shaped hit area, that didn't correspond directly to the image you were testing, you can use a second, black and white, bitmap to represent the areas that you want to be collidible, and test that bitmap against both hit boxes and other pixel data.

But I have gotten off track. Does this answer any questions?