Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 18 Oct 2007
Offline Last Active Yesterday, 10:07 PM

Posts I've Made

In Topic: Insurmountable limits on a touchscreen interface?

17 April 2015 - 04:16 PM

Only real way to know is to test it, make prototypes.

I've seen quite a few in development games(early access) that try to do new styles of gameplay using traditional mouse and keyboard, and it ends up extremely awkward simply because their idea of a control scheme doesn't match up with what the game wants you to be doing.

It isn't necessarily a point of "is this control type good enough for games of this style" it is more "can I pick a game design and control scheme that will feel good and workable on these platforms." I've tried shooters with touch screen and although it worked it does not in any way "feel good" in my opinion, things like that.

Take into consideration the limitations said above and think of how you can make it work.

In Topic: Seemed easy, is really hard, How do you program bullets?

17 April 2015 - 04:09 PM

Do you have any general info on the object pool technique? I feel like I should know this.

This is a good pattern of design to use to help in memory management.  Game Programming Patterns by Robert Nystrom goes into several really good patterns that you might also find helpful.

In general you'll find the word "cache" or "pool" used a lot in game dev, almost of buzzword quality simply to refer to the idea of a design that favors keeping objects in memory vs destroying and recreating them on demand.

You technically could create and destroy each bullet as needed, and it would work, the only real negative to that is that things like bullets usually are an obvious candidate for pooling.

In Topic: What's a good 2D game engine to learn after C++/SDL?

31 March 2015 - 04:52 AM

Hello all!

I've made a simple game with C++ using SDL, and I will probably make a couple more games in the future using SDL. However, I really want to learn how to use a game engine, because then I can produce more advanced games in less time. 
I will start with 2D then make my way into 3D. What game engine should I learn that's good for 2D game dev (and eventually, 3D?). I would like to stick to C++.

I thought I would learn Unreal Engine 4, but people said it was overkill for a beginner and it didn't have good 2D capabilities.

I would like to point out the dichotomy here. Generally engines of any large size and productive merit like Unity are going to isolate you from the code, you're unlikely to be doing much C++. Unity is nothing like SFML or SDL, most big engines like that are centered around suites of content creation tools and scripting.

If there is a good middleground for a simple 2d C++ engine you can just whip out and modify, I have yet to see it. These days in particular you're gonna be split on the issue. Do you care more about practicing your C++ or finishing a game? Modifying a big engine at the source level is usually a quite advanced undertaking and you probably won't be doing it.

In Topic: 8 bit sprite animation

31 March 2015 - 04:43 AM

Interesting comments, the kind of 8 bit style I wanna make is like Pitfall, or a bit of more resolution (just a bit):
Should I do all the draw manually? Or may I use a 3d software to generate sprites?

Using 3d software to make sprites like that is kind of like taking a priceless greek statue and then whacking it with a hammer until it is a roughly statue shaped block of stone.

I shouldn't really need to say that art like that should just be a bitmap.

In Topic: How best to represent data required for static and animated sprites?

31 March 2015 - 04:34 AM

Thanks for the advice chaps.

Separate the concepts of sprites and animations.

I've coded up a prototype in this vein and it definitely looks like the way to go. My sprites are now completely dumb, whilst all animations are managed by a dedicated animation system. This will allow me to do more complex things like chain animations together, cancel running animations etc, so cheers for that!

Probably one of the most effective things to learn for game development is to think of the different aspects of a game as being independant. In theory your game should be able to "play" without ever displaying anything, without ever playing sound, any of that. The moment you start making game logic rely on visuals is when things start getting taped together into a spider web. It also makes it much more difficult to change things.

In a way you can kind of think as visuals as a sort of peripheral, like you should be able to "unhook" them and even swap them out for some other pieces easily. You can technically think of it like model-view-controller but in reality it is more a design facet that the seperate systems of the game don't have much reason to be physically glued together, if anything they should just process relevant information.