Hi there I would like to start a discussion with other people who are building their own engines, rather than using existing ones. When I came to iOS development, I already had a large personal library of code that took little modification to get working. I have a very basic, bare bones objective C front end, with a few hooks to my C++ library. I come from a PC background and have a very old Mac, so my system is fully cross platform. I do 95% of my development on PC. Anyone else chosen a similar path? What kind of architecture do you have? I am eager to discuss and share ideas/strategies/optimisations/code snippets with people. Examples: - Maths library: vectors matrices, quaternions, etc - OpenGLES wrapper - Texture/Audio/Input managers - Sprites, particle systems, tiled backgrounds, etc - UI components And anything else you can think of. I am enjoying building my engine almost as much as I am enjoying making games that use it. What are your thoughts? I'd love to hear from you. Cheers
What I do is kind of similar. I enjoy making game engines too I've started from scratch numerous times, learning a bit more each time.. my first proper attempts were with the BlitzMax language on PC, then later C and C++. My iOS game engine started as a Win/OSX thing. It's basically wrappers for graphics and sound handling. On Win/OSX I was using SFML for those, then when I made the iOS version of the engine I changed it to GLES and OpenAL, of course. Aside from that it's mainly a bunch of sprite/particle systems. I haven't used any physics or maths libs yet, or any scripting stuff.. my games so far are pretty simple. In my first iOS game the engine is really complicated.. I was learning C++ and trying to be all clever.. everything is super generic, all types of object inheriting from one base class. All object behaviours are in small modular plugin-like functions which can be added to any given object.. These behaviours can themselves load new behaviours, or swap between different sets of behaviours etc. Or an object could swap its behaviours with those of another object, or choose a random behaviour. Very flexible and kind of cool (well I think so, but I've never used any professionally made game engines, this sort of thing is probably bog standard ) but in the end it's just over complicated I think - my game doesn't even use half the features of it! So my second game I stripped all that out and just have a very simple sprite class with each type of object having its behaviours coded in specifically. Nowhere near as flexible, but since I'm not actually *using* that flexibility for anything this doesn't matter. In the Win/OSX version of my engine I made a full GUI system with moveable windows, buttons, list boxes, text fields etc.. and a kind of complex tilemap system with built in map/object editor (was going to make a platformer at the time)... I haven't put any of that in my iOS engine because I haven't needed it. So my engine isn't properly multi platform, the computer and iThing versions are out of sync... I'd like to get back to that eventually and fix it all up though. As it is now the two versions of the engine are pretty easy to port stuff between. It took me about 15 minutes to get simple Win/OSX versions of my iOS games up and running. As for optimisations, I don't have that much experience to share.. my games could definitely be optimised much more, but I don't know how yet.. luckily they're simple 2D pixelly affairs so it's not that important. I did spend a lot of time trying to get the openGL drawing to be nice and fast though, so I could chuck around lots of sprites. The biggest improvement I made to that was when I learnt how to add every quad to a list and draw them all with a single call - instead of drawing each one individually. FPS went from ~40 to 60.. sorted! ~ I think doing all this engine coding is lots of fun, and a great way to learn... but tends to mean it's a looong time before you get up to actually making games. But, thinking about it now, I'm starting to get the urge to start a new game engine from scratch again, with all the new stuff I've learnt since last time... eek! Cool thread idea btw Charybdis, looking forward to reading more replies!
I would like to ask - how does one make an engine? How do you start? Making it a framework, or a bunch of files like the great cocos2d?
Well, I started just by having a load of files that I imported for each project. But eventually it got to cumbersome and I made a framework. I am very new to Mac and XCode, so I learned the bare minimum to get it working. As I said, I work mainly with Visual Studio. I really like the way a workspace can have multiple projects. I haven't yet been able to do that under XCode, but I keep on trying. I also have a master 'shell' project. Whenever I start a new project I just copy it and it has all basic stuff done.
Nyarla, thaks for the great response. Your engine sounds pretty cool. Mine is still fairly immature, but it's developing day by day. I agree with you, it is easy to start getting over complicated, throwing lots of clever OO programming at it. But at the end of the day, simple is best. I try to keep my stuff clean, but dirty hack do find there way in during the development process. I will probably need to sit down and do a complete refactor/overhaul at some point.
If anyone is interested, I made a very minimal 2D vector class. The one I use in my engine is a bit more advance, with const correctness and a bit of template goodness, but if you need something simple to slap into your own engine, feel free to use it. Let me know if you find any bugs or better ways of doing it. You can read the blog post about it here. Code: /* * v2.h * Minimal 2D vector class * by Dale Thomas * Copyright (C) 2011 Scylla Games * www.scyllagames.com */ #ifndef __SCYLLAGAMES_V2_H__ #define __SCYLLAGAMES_V2_H__ #include <math.h> class v2 { private: float data[2]; public: v2() { data[0] = 0.f; data[1] = 0.f; } v2(float _XValue, float _YValue) { data[0] = _XValue; data[1] = _YValue; } float& operator[](int _Index) { return data[_Index]; } v2 operator+(float _Scalar) { return v2(data[0]+_Scalar,data[1]+_Scalar); } v2 operator+(v2& _Vector) { return v2(data[0]+_Vector[0],data[1]+_Vector[1]); } v2 operator-(float _Scalar) { return v2(data[0]-_Scalar,data[1]-_Scalar); } v2 operator-(v2& _Vector) { return v2(data[0]-_Vector[0],data[1]-_Vector[1]); } v2 operator*(float _Scalar) { return v2(data[0]*_Scalar,data[1]*_Scalar); } v2 operator*(v2& _Vector) { return v2(data[0]*_Vector[0],data[1]*_Vector[1]); } v2 operator/(float _Scalar) { return v2(data[0]/_Scalar,data[1]/_Scalar); } v2 operator/(v2& _Vector) { return v2(data[0]/_Vector[0],data[1]/_Vector[1]); } void operator+=(float _Scalar) { data[0]+=_Scalar; data[1]+=_Scalar; } void operator+=(v2& _Vector) { data[0]+=_Vector[0]; data[1]+=_Vector[1]; } void operator-=(float _Scalar) { data[0]-=_Scalar; data[1]-=_Scalar; } void operator-=(v2& _Vector) { data[0]-=_Vector[0]; data[1]-=_Vector[1]; } void operator*=(float _Scalar) { data[0]*=_Scalar; data[1]*=_Scalar; } void operator*=(v2& _Vector) { data[0]*=_Vector[0]; data[1]*=_Vector[1]; } void operator/=(float _Scalar) { data[0]/=_Scalar; data[1]/=_Scalar; } void operator/=(v2& _Vector) { data[0]/=_Vector[0]; data[1]/=_Vector[1]; } float lengthSquared() { return data[0]*data[0]+data[1]*data[1]; } float length() { return sqrtf(lengthSquared()); } v2 unit() { return *this/length(); } float norm() { float l=length(); *this/=l; return l; } static float dot(v2& _Vector1,v2& _Vector2) { return _Vector1[0]*_Vector2[0]+_Vector1[1]*_Vector2[1]; } }; #endif
I have a suggestion: make the code cleaner The curly braces should take up a line each in my opinion - I always MUST have it like that. Some people like Code: method { } though. But Code: method { } is too messy for me
I totally agree with you. I always have curly braces on their own line. EXCEPT when the function is very small. Or, as in this case, where I wanted to save space for posting code online.
Really? I prefer: Code: -(void) insanelyGreatMethod{ // amazing stuff goes here } Where the method starts shold be obvious, so the only question remaining is where it ends.
Personally, I find method { } too messy, I like to see the braces match up vertically: method { } same for ifs, for loops etc. I've worked at places where this is an enforced coding standard. Personally, I use method{ } for inline stuff but only if the entire code fits on one line without scrolling. Mor controversially, I also do brace free stuff like: if(a>b) c=a; else c=b; when stuff is very simple as I can't see the point of eating up yet more lines of source code when I use a lot of white space and my vertically aligned brace thing 'wastes' lines anyway. In fact I've also used: for(y=0; y<MAXX; y++) for(x=0; x<MAXX; x++) { doSomething(x,y); } On the subject of the original post, Your system sounds a lot like mine, the exceptions being that my Graphics wrapper uses D3D under the hood on the Windows version. I also have a pretty cool custom memory manager (designed by a colleague at a previous company) which forces me to allocate in a slightly odd way but more than pays for itself with the level of control it gives.
I used to religiously use this style: Code: void function() { } but then I worked in a games company and had to follow their coding standard, which put the open brace on a separate line. I have prefered that way ever since. It's just personal preference really. I also use brace-free sometimes, but I have been bitten by resulting bugs fairly often, so I am always cautious, and only do it when I am pretty sure it's okay.
I'm used to the following, but a buddy of mine cannot stand it... Code: void someFunction{ } I also go braceless at times...but ONLY (of course) when it's a very clear if-statement or for-loop.
Here is my game architecture. It's 90% C++, use STL, single thread. Part of math library such as 3D vector and Quaternion came from open source. It has 4 layers ready to expand. 10% of Object-C code for iOS main loop and API. Like someone above, it took very long time to develop the engine and it's so much fun.
@simfrontier Looks quite similar to mine, except yours appears to be much more mature. What kind of event system do you have? And how sophisticated are your aerodynamics calculations? Yes, it is a lot of fun isn't it. It's also a great learning process too. I love getting down to the nitty gritty, nuts and bolts. Recently I had to implement bresenham line drawing algorithm, for drawing into a heightmap. haha!
The event system is centralized. A global event center is in charge of receiving and distribution of event. Any modular who want to listen or post event can register itself at event center, and map the event ID with function pointer. Event ID can be STL string or integer. Modular can also build it's own local event center, but this is rarely used. Event class is dynamically created, will be auto released after all registered handler finish their processing. ( There is ref counter inside event class ) Each event handler has a event queue to store received event. The queue is stored in STL map<float, iEvnt*> container. So event can be processed in order of the delay time you provided when event is created. Quite a simple and typical system based on other devs articles and works. The aerodynamics is very simple. The speed is calculated based on pitch and throttle, plus some delay when input changed. A turning rate is calculated based on banking angle. Still need some tricks of vector and quaternion operation. More sophisticated algorithm is in development for implementation of STALL and a new kind of project. Yes, building the system from scratch is fun and tough. But the engine grows naturally when the features and complexity of Apps grows. Height map is one thing in my TODO list
I made a few, I used to make games with no software architecture or structure in mind, thinking about what elements can be generalized, I ended up creating reusable building blocks to help me make a custom engine depending on a game. To much generalization, ends up being to big and slow. I prefer to have independant modules that can quickly be combined together and tweaked. At the end of the day I have vector math library, 2d collision library, OpenGL rendering library, some tree and graph utilities, very thin game object library basically just containers for game scenes and game objects, scene graph, open al routines, couple of 3d file format parsers, texture loaders, bullet physics for 3d collisions and 3d physics. I used to have most of this in Objestive c but I am moving it to c++. I have similar structure written in java for making level editors and other authoring tools. With java I get the tools to work on both win and osx.
