7 replies to this topic

[Smiley]

Hey there!

Could you recommend me some (free) 2D game engine that has fast and reliable network code suitable for twitch gaming, source code and good documentation. Level, animation and sound editor wouldn't harm. Programming language isn't so important, it's more about getting game done for Windows.

Just to mention; I did some attempt building my own "engine" using OpenGL, but programming was time consuming and not really entertaining, looks like I'm not the person who likes reinventing the wheel.

[starstutter]

Uhhh... sorry, don't have a specific answer for your question, but you might want to reconsider some things...

Quote

Programming language isn't so important, it's more about getting game done for Windows.

So should we give you one written in Visual Basic that can do looping math at half the speed of smell? Should we give you one with a language you've never even heard of? Should we give you one with a poorly constructed, obscure language with no support or decent tutorials?

If you didn't mean that how I interperated it, you may want to look at this thread:
http://www.devmaster...ead.php?t=11869

Quote

Just to mention; I did some attempt building my own "engine" using OpenGL, but programming was time consuming and not really entertaining,

Well it is pretty important that you mention that, and if this is how you feel you should probably consider a different hobby. Programming isn't really meant to be entertaining (well for some people it is), but the results you get out of it usually are. Making *any* game (reguardless of genre, language or engine) takes indescribable loads of hard work, and most people don't consider hard work entertaining.

Quote

looks like I'm not the person who likes reinventing the wheel.

Programming and reinventing the wheel aren't really that related. Yes, using an engine does keep you from writing repeticuous code, but it doesn't lighten your work load at all. Why? Because you have to learn to use the engine first. And by "use" I don't mean moving around the screen and dropping objects were you want. If you want even a mediocre quality game, you have to customize with your own code and custom work, there's just not much way around it.

Really though, I tink you've got the wrong idea of what an "engine" is. Engines really do not save people nearly as much work as they would expect, and the bigger and more capable the engine, the harder it is to use.

Sorry I'm not giving you the answer you asked for (I know that pisses people off) but understand that what you're trying to obtain here is probably not going to do you much good.

[alphadog]

Starstutter, you may have misunderstood the OP. I think he meant reinventing a "game engine wheel" is not his gig, not programming in general. I could be wrong...

To the OP, exactly what kind of game do you want to make? What's a "twitch" game and does it involve nervous conditions somehow?

[starstutter]

Well yeah I considered that possiblity, but I was also pointing out that sometimes re-inventing the wheel is somewhat necessary to understand it. Whatever happened to Matt? He was an expert on this stuff.

As for what he means, I've heard games like Counter-Strike referred to as a "twitch" game. Just gameplay that relies on fast reflexes.

[fireside]

The only 2d engine I know about that uses Opengl is Agen, but I don't think it has networking. When you start making requests as specific as that with level editors, etc, it's asking quite a bit. It's not reinventing the wheel so much as finding the right pieces to put together. Raknet is a good networking engine but you would need a c++ type game to use it. Also, Opengl really isn't too bad when using it for 2d purposes. It's mostly just putting some textures on some quads. I think there might be some around, though, but that kind of thing is better off done with a google search. I don't think you could find one engine that did all those things, but maybe there is one around somewhere. It's a lot easier to find a 3d engine that does those things, unfortunately.

[Smiley]

alphadog said:

I think he meant reinventing a "game engine wheel" is not his gig, not programming in general.

Yup, something like that. I just don't enjoy writing stuff that is very repetitive in general and could be found on every corner, also known as boilerplate code.
But surprisingly I have to admit, that I started to feel pretty comfortable in SDL + OpenGL combo, even if I had to write my own texture loader, maybe I'm going to survive this "wheel reinventing", at least I have a challenge and I'll gain understanding what happens behind the scenes.

Quote

To the OP, exactly what kind of game do you want to make? What's a "twitch" game and does it involve nervous conditions somehow? :)

Well I'm building a 2d multiplayer side shooter game and with twitch I mean fast-paced game, which is usually networked with fast UDP protocol.Yes, I think that counter-strike is good example.

[alphadog]

This is one of the few places Starstutter and I disagree. "Re-inventing the wheel" is only good for knowing how to reinvent the wheel, or maybe to invent a better wheel.

However, you don't have to know how the wheel was originally invented to build a car. You are operating at a different level. (In fact, if you reinvent the wheel far enough, knowing the original wheel is not deeply useful.)

I understand a fair number of people think you must "understand the parts to understand the whole", but I think that's a fallacy. It's like saying you need to learn assembly or C to write a program in Python. Makes no sense to me.

As for the OP, if you are coding up a fast-paced 2D side-scroller and want as much provided to you as possible, then Torque is probably the strongest consideration, given that they have the toolset and a strong networking library.

Other 2D solutions: Haaf's and PTK. And, SDL has been around so long that you may be able to piece together a toolset that fits from the intertubes.

[starstutter]

alphadog said:

"Re-inventing the wheel" is only good for knowing how to reinvent the wheel, or maybe to invent a better wheel.

Well I think in this instance we may be seeing "re-inventing" as 2 different things. I did word it a little wierd (I was in a hurry while typing, so I didn't go into a whole lot of detail) but what I meant was that to really understand something, it's best to do it yourself at least once.

Quote

However, you don't have to know how the wheel was originally invented to build a car. You are operating at a different level. (In fact, if you reinvent the wheel far enough, knowing the original wheel is not deeply useful.)

Yes, that I totally agree with. Just like the whole thing going on in the other post about explaining normalization. Personally I think throwing the concept of euclidian metric into the explaination was just a needless addition that makes it twice as confusing to the person asking for help. *Yes* it's mathematically correct, but it won't help him understand the core concept any better. That's like trying to teach someone how the components of an engine work when they don't even know what a engine is in the first place.
Srry, I'm getting off topic :)

Quote

I understand a fair number of people think you must "understand the parts to understand the whole", but I think that's a fallacy. It's like saying you need to learn assembly or C to write a program in Python. Makes no sense to me.

Yes, in this sense you are right, but it's a double sided story. Understanding the whole helps you understand the parts, but understanding the parts can help you better create the whole (or at least debug). I was thinking of debugging specificly when I made my post, and speaking from experience, once I learned the little details of how things worked, debugging became almost x10 faster for me.

So, I'll give the answer I normally do. For a small, messing around project, do use an engine without worrying about code too much, personally I was just thinking more long term. I have to remind myself not everyone is that into it ;)