The Game Engine Dating Guide: How to Pick up an Engine for Single Developers | Hacker News Reader

The Game Engine Dating Guide: How to Pick up an Engine for Single Developers

learn-cocos2d.com

39 pointsukdm21 comments

> 99% of all game engines are reasonably fast

Not true in web development land. Especially for canvas-based engines, implementation matters a lot. At work we recently had to switch some player drawing back to DOM elements + CSS transforms, after hitting some hugely inefficient code paths in the canvas framework we chose.

Interesting. Can you please name the framework you left behind?

Also, why did it seem to be more time-efficient to ditch canvas altogether and rewire the rendering part?

I'd also like to know more, I have just been rolling my own stuff so far and have been surprised by how well the canvas is handling everything I throw at it.

Tablets / Phones is a little different, but the desktop much faster than I expected.

That was OCanvas (ocanvas.org). It's perfectly fine for vector stuff, but our game is very bitmap heavy. We started getting FPS rates as low as 10 with only 5-10 characters on screen (using animated/scaled Sprite objects). Using DOM + transforms we can get up to 500 chars on screen without any lag whatsoever.

We didn't ditch canvas altogether though, we render all the scenes in a background canvas and use DOM only for the moving chars. I suspect it's possible to get much better performance by pre-rendering all scaled objects, but haven't had the time to try it. CAAT performs incredibly well with bitmaps on canvas: http://labs.hyperandroid.com/static/caat/

I don't even think it's true anywhere. There's a laundry list of tricks you have to pull to get decent performance out of Unity, and it's a good engine.

A more truthful restatement might be something like, 80% of game engines can be reasonably fast, if you learn their quirks and optimize your game accordingly.

> Performance is not a feature!

100% disagree. We develop Construct 2 (http://www.scirra.com) which is an HTML5 game engine and we take every care to make the engine as well performing as possible.

An example:

We've written about Garbage Collection in JS: http://www.scirra.com/blog/76/how-to-write-low-garbage-real-...

Garbage collection pauses can make games unplayable for HTML5 games and some of our competitors engines suffer from GC pauses which their user bases complain about.

Games made with our engine don't suffer from GC pauses as much because we've taken care to make Construct 2 as well performing as possible, this is a good feature of our engine.

I also disagree. I'm working with some friends on a Python port of a small multiplayer game, which is quite heavy on image transformations. Because of this, we can't use some popular Python libraries like Pygame since they aren't hardware-accelerated [for transformations], and hence run too slow.

The author writes from the "native Apps" point of view.

Even for that it is not true. I call the phenomenon the "FPS wall". You cram features into the game, and the engine performs slower and slower. At some point you reach a certain low FPS (something like <20 FPS) and there is no way then to get back to better performance. That also means that you cannot put any new features in, because you would just make the game unplayable. And since the engine is flawed in itself, there is no way to optimize away the slowness.

I don't agree with the author at all. Its much better to have an open source engine. You can customize it to your own needs by stripping out parts you don't need. Thus get performance by dropping features you don't need at all, and thus saving development time by not having to optimize parts you do need, but which take more time than they would be worth.

If you don't care about tailoring the engine to the game you are writing, then the engine will show its restrictions on the game. And that is the road to mediocrity. Its not just the glitter, but engines tend to limit the gameplay too, if you let them.

> Open Source is not a feature

Most of time games developed with a particular engine look similar. Sharp eyed gamers notice this and other don't. But they definitely perceive the lack of freshness when they play.

Successful games producers often extend their game engines in innovative ways. Though plugins can be written to closed engines, open source engines give unlimited flexibility. In such cases, open source is certainly a feature.

Most licensed game engines are licensed with source code to allow modifications. Unreal is not open source, but most developers who use it will get a source code license so they can modify the source themselves. It is very common for game developers to re-write entire sections of the code.

This is mostly because the Game Developers don't understand how to create a unique visual style, using default options for more than 80% of the rendering.

Custom shaders can go a long way towards making a game look unique.

I've just gone through that same evaluation process. I actually had the exact opposite criterion: I wanted a game engine with source. I considered commercial engines but they almost never come with source or have exorbitant licensing or cost conditions to get it. Based on that, I've been trying out the Moai SDK.

It's OSS and uses Lua for scripting. It's primarily 2D focused (though it runs on OpenGL and there are underpinnings of 3D in the code) and runs on iOS, Android, Mac, and Windows. So if you're a Windows developer wanting to do iOS, it's a great option. You still need to do final build/QA/deploy from a Mac, though.

The engine appears to be well-written, if idiosyncratic. These guys obviously know what they're doing. Their tagline right now is that it's an OSS game engine for professional game developers.

The huge caveat is that the documentation is really lacking. I know it's something they plan on addressing soon, but it's an issue right now. If you want to give it a go, expect to consult the source quite a bit.

Here's how I evaluate game engines:

- First, will my target audience be able to play it? May seem obvious but I've seen people fall in love with an engine for technical or business reasons and overlook this.

- Choose a few hypothetical tasks (e.g. I want to add a laser beam effect, or I want a character with dual-wield weapons). Look at the docs and see if I can figure out roughly how to do this. For me, browsing docs doesn't tell me that much unless you have a particular problem in mind. At this point I still haven't even downloaded the engine yet.

- Play some other games written with the engine. If there's no games using it yet, I'm cautious about being someone's beta tester.

- Ok, now take a weekend or so and try to develop a mini-game with it. That's the only way to really get a good sense of what working with the engine is like.

> Open source engines are typically more difficult to work with since any source code can generate compile errors and updating the game engine’s source code is prone to generating such errors.

I can understand where the author is coming from with most of his points about open source, but really?

Interesting, I was thinking of playing around with game engines at some point (I did a bit of Java 3D and DirectX years ago at college).

I am sort of torn between looking at Unity , XNA Framework (not technically an engine I suppose) or seeing what can be done with WebGL/Canvas etc.

Unity looks like it has a huge following and plenty of games and the cross platform stuff is a big plus. The only thing I worry about with that it is possibly the flexibility. It reminds me a bit of the "game creator" programs that were popular in the 90s in that perhaps it is aimed at building "me too" type games?

If I wanted to build something with some entirely new gameplay mechanic would I find that it got in the way?

The scripting in Unity is built on Mono, so you can pretty much do whatever you please. The Scripting API is expansive and while there are a few nooks where you can find yourself limited, that's usually the exception. I give free Unity consulting on Fridays and I'd be happy to give you a kick-start into Unity: http://yilmazkiymaz.com/fucf

Just FYI, You can use Unity with XNA.

There's a totally free version of Unity. I think if you download it and try it out for awhile, you'll discover that it would be extremely easy to build any kind of unique game mechanic you might want in it. Probably easier in unity than anything else simply because unity will still take care of a lot of stuff for you.

I wouldn't say Unity forces you into any assumptions about your game. (for instance, many people think of it as a 3D engine, but famous 2D games were built on it, and the developers gave it the capability to do 2D right.)

Here's a shorter answer:

Have money or want to make money? Buy Unity 3D. No money, non-commercial: Free Unity 3D. Refuse to use anything closed source? Then go open source (and in that realm there are too many choices for me to recommend one.)

Unity 3D is a really good product, and it bridges the gap of being easy to get started with while simultaneously capable of professional AA title work. Your art will still be a lot of work, but Unity has the engine side of things covered . The programming paradigms are perfect for game development too.

Really worth checking out.

(I'm assuming you're building stand alone executables or mobile games, Unity is usable in the browser with the Unity plugin, which a surprisingly large number of people have installed.)

Unity3d is a second class citizen for 2D in my mind.

Reply on news.ycombinator.com