Categories
games design MMOG development programming

Entity Systems for Objective-C (iPhone)…prologue

I’ve just started a new game project for iPad which I hope will end up with a commercial release. At Red Glasses, we’ve got comparitively few projects for the next couple of months. If anything comes in, I’m expecting one of the other coders can pick it up, and I can concentrate on this in-house iPad game.

Schedule: 1. Prototype; 2. Refine

I wrote the first prototype this weekend – it looks like a very basic Flight Control right now (the game design is trying to do something novel with FC mechanics – I like that control system, but I think we can do a lot more with it than people have done so far).

Now it’s time to implement some of the novel mechanics, and prototyping our core game design. This will mean creating a lot of game-logic, lots of behaviours, etc. And so … I’d really like to use an Entity System.

Objective-C: the bad bits of C … without the good bits of C

The thought of building an ES without templating makes me weep.

Unfortunately, Obj-C continues to show it’s age/mediocrity/general-lack-of-usefulness: it’s finally (this year!) acquired an implementation of closures, but it still doesn’t have generic classes.

NB: *I believe* it doesn’t have generics; it might have, but I’ve not noticed them in any ObjC projects, code, libraries, etc. A quick google came up with nothing.

ES without generic classes is like OOP in Perl: techically possible, but liable to contain a lot of painful bugs which a compiler would have spotted for you … and contain a *lot* of boiler-plate code you really shouldn’t need to write in this day and age.

I could fix all this with C++ – it has probably the world’s best implementation of generic classes. It’s not perfect, but IME it’s the best overall balance of functionality.

Unfortunately, unlike C, Obj-C is incompatible with C++.

What next?

Ideas and suggestions are *very* welcome…

Assuming I can get an ES to work on iPhone, I’ll be blogging it. I’ll aim to open-source the ES I build.

I’ve had a quick look at using C++ classes and objects in ObjC. Using the objects has a lot of boilerplate code from Apple, that looks pretty good (but painfully verbose :( ).

…but using the *classes* appears pretty horrific. Since ObjC doesn’t have any kind of generics (that’s how we got to this point :)), it can’t handle those parts of C++ in a meaningful way.

Then again, since Obj-C is *very* dynamic as a language, I might be able to do something cunning with passing around NSClass instances / references. Combine that with runtime method dispatch / message-passing, and *maybe* I can code a decent C++ ES … while using ObjC to write logic that acts on the data from that ES, without having to write so many extra lines of code that the “saving” is lost.

As I said … ideas welcomed!

19 replies on “Entity Systems for Objective-C (iPhone)…prologue”

Agreed with Harald.

All of your game logic still perfectly fits in C++. And when it comes to rendering/playing some sound, there is an OpenGL and OpenAL for you, so you don’t need to mess with interfacing C++ ES iOS API a lot. Just wrap in ObjC window creation, input handling (redirect it to C++) and other stuff like that.

Waiting for next articles on ES, gl.

Hmm. A few people have suggested this, and it’s a reasonable idea, but it shows I wasn’t clear enough up front: I’m not interested in writing an entire game in C++. If I were going to do that, I wouldn’t write it in pure C++ anyway – I’d use at least one scripting language (lua? python? something, anyway…). IMHO writing indie / small / non-console games in C++ is a foolish waste of time and money.

So. It’s not about “how do I interface a C++ game to the bits of Cocoa that are *required* by Apple’s OS”, it’s about “how do I get scripting *and* juicy C++ templates in the same app” — *preferably* (massively preferably) using ObjC as the scripting language.

(mainly because: nearly all iPhone programmers know ObjC. If I’m going to open-source this for use in iPhone/iPad games, ObjC is a much better choice of scripting language than any other)

Mixing ObjC and C++ templates? Don’t know how to do that. And it’s depends on what exactly do you need from them.

I don’t even think that ObjC++ layer intended for something more than “just reuse for me this bit of code so I won’t reimplement it whole plzkthx”.

There is always a way to do everything. But using templates only and trying to interop ’em with ObjC? I’d better stick in pure ObjC (there is a thread, suggesting ObjC is very good on implementing something ES-like: http://forums.tigsource.com/index.php?topic=10112.0). Otherwise, I’ll stuck in details of how even ObjC and C++ layer works at all and what limitations it have. Or shall start things like POD C structures with extern C funcs.

So I think, you need to learn ObjC a liitle more. Maybe there is many “ObjC way to do X”. And keeping in mind ObjC dynamic nature out of the box, it may fit in some scripting language even better than C++.

@nobody

I read the link you referenced; it say nothing about ObjC ES’s. (if I’ve missed the page/reply where it was described, please point it out – I read the whole thing, but found nothing)

It has a lot of people (who appear NOT to be ObjC programmers) saying “I think you should do this in ObjC”, while failing to provide *any* concrete examples or reasons for doing so, beyond random theory.

Meanwhile, it has a lot of people (who clearly use C++) saying “C++ templates are the best way to do this”.

So … it pretty much comes back to square one: can we use C++ templates in ObjC, because ObjC is nowhere near good enough to do this otherwise?

(incidentally, I’ve been coding in ObjC for about 3 years now, with my first launched ObjC app almost 2 years ago. I doubt that I “need to learn ObjC a little more”.

I’ve done some really obscure stuff (e.g. runtime method swizzling), and used it in launched products. There’s only a few places I haven’t delved, and I’m fairly sure they don’t contain a hidden generics/templating alternative.

C++ integration is one of those I’ve tested but not done anything significant with)

Okay. :)

And sorry, there was only a few abstract posts on that thread, saying “It would be cool to use ObjC, such that I’ll no longer care about static part of ES/CS/whatever and just call everything by dynamic thingie”.

Anyway, I don’t get it. But where I’m definitely sure, is that you gonna buried under thousands lines of boilerplate undocumented crap (first and the only one official article I’ve found: http://developer.apple.com/library/ios/#documentation/cocoa/Conceptual/ObjectiveC/Articles/ocCPlusPlus.html, “you can’t do that, not allowed to do this”. yeah right, so what I’m allowed to? *silence is the answer* try and pray). So this is why I’ve suggested you to use either pure ObjC, or thin ObjC part powered by C++. And moreover, this will be crossplatform (which is by my believes very important, because I really hate platform-dependent-only solutions).

>> It has a lot of people (who appear NOT to be ObjC programmers) saying …
True. But I’m not one of them. And this statement is pretty common for any language out there. Just fanatics, which do exist for everything, where X vs. Y dilemma can occur.

>> can we use C++ templates in ObjC
Yes-s we can. We can always throw a pointers between languages; wrap data in structures; write some helper procedures to identify, for example, if “this ObjC object instanceOf(other one C++ object)”; maybe even declare template class side-by-side with ObjC class, or inline it in each other…

>> and I’m fairly sure they don’t contain a hidden generics/templating alternative
There are definitely none of any, yeah.

No offence, really. Just blah-blah’ing here. :)

Oh, I just re-read your comment:
>> using ObjC as the scripting language
Makes more sense now.

Well, don’t know anything about ObjC exact scripting capabilities, but this returns us to the beginning: most part of an interesting and heavy stuff still happens in C++, while scripted entities (not as in ES) may communicate with something here and there, maybe each other — this doesn’t require templates.

Something like that:
Templated systems and components, holding somewhere native ObjC objects. When it comes to call object’s logic on something, dereferencing native ObjC thing, passing context/arguments to it and executing.

Also, just thought about it. It is possibly easier to interop with ObjC _from_ C++, not otherwise (cpp.objcrt.call(“mahCoolMethod”)). Because ObjC runtime API/internals is more open and simpler than C++.

And one more thing ™. According to last changes on iP* developers agreement, you can use any scripting language you want absolutely safely. Except you can’t extend you app by downloading this scripts from outside (“extensions store”) and JIT’ing.

“possibly easier to interop with ObjC _from_ C++, not otherwise”

…that’s an interesting idea. Could be some good mileage in that.

STOPSPAMMING!

That would be neat:
Func foo = objcrt.gimme(“fooMethod”);
double bar = foo(1337);

Nah, brackets again.
Func < double, int > foo = objcrt.gimme(“fooMethod”);
double bar = foo(1337);

I’m done.

(yes, sorry about the very basic tag stripping – out-of-the-box WordPress. The few comment plugins I tried all added as many problems as they solved. I might try Discus again soon, but it doesn’t work with android phones, which I need)

Hi adam…

I’ve read all your previous posts explaining the Entity Systems (great read) but I’m still trying to put all the pieces together in my head and have a couple of questions.
1. How do you model relations between entities? A car for example would consist of 4 wheel entities and one body entity. How can you represent the relation between the wheels and the body for the purpose of physic simulation for example?
2. How would you use the entity system to represent say blocks in Tetris game? There are a bunch of different types of them and I would suppose that the small pieces that blocks are made of should be entities, but in this case what an actual block is?

Tetris blocks – the actual block could be one entity, and as soon as it is in place, you delete it and replace it with 4 smaller entities, one for each piece in the original block.

It’s all just data – there’s no reason why a conceptual in-game-item has to *always* be represented by the same entity(s)…

Thanks! It looks like I’m still stuck in the OOP paradigm a bit.

How about a car example? My best idea so far is to have a car with “Has 4 wheels component” that contains 4 entity IDs for wheels. I don’t like the idea of “Has 4 wheels component” because I need a new component for my imaginary 5 wheel car…

Why do you need To store that “has a” relatiOnship?

That’s a very weird thing to do; complicated paradigms like OOP force you to do so (it’s a feature – part of their encapsulation etc), but that doesn’t mean you have to do so now.

In practice, you rarely care about relationships.

With physics, the common approach is that you need to know which objects are connected to each other, which is fundamentally a tree structure, and ideally is something you’d keep out of the ES, because trees are pathologically bad for an ES (try putting a tree inside an SQL table, and you’ll see the same problems).

I’ve not been following physics engine best practice recently, so I don’t know what workarounds there are, but the ideal thing would be a phys engine that uses some flatter strucutre (in which case include it in your ES), or … Keep the physics data in the physics system, a parallel data dlstructure (which brings it’s own risks, but is possibly the easiest starting point)

Comments are closed.