I am working on an engine entirely written in C++, and today i’ll show you the current result. There is still a lot of thing to do, but you know what it is, write a game engine is a never ending task.
First, a small video
I wrote it after months of works with JMonkeyEngine, and for this reason some aspects are similar. It’s the main reason of this topic: do you agree with that ? I wrote everything myself (except the Quaternion that i shamelessly pilfered). The similarity are: a scene graph, controls on elements, appstates and an assetsmanager. I didn’t say it in this video (cause i don’t know your opinion about it) but i’ll edit it (if i can do it. It’s my first video on youtube) to add a mention to JME if you agree. There’ll be no amiguity about your support (e.g. i’ll write something like “This engine is inspired from an other engine, JMonkeyEngine 3”).
Ok, now some tips about the engine itself:
The physic engine (you can jump etc) is made by me and is called BasicPhysicEngine for a reason: it’s not suppose to be used in production. It handle collision detection but there is no collision response (feedback torque etc).
This was the worst part of the engine. Now nice things:
Models are encoded in a home-made format, XSB (standing for eXtensible Statefull Builder) which a binary format inspired from the .obj one but improved to reduce the redunduncy of the information, make the loading easier, support local translation/rotation for every item and, in a near future, animations (i only need to find where animations are stored in blender). This will finalize the XSB+Vanilla. It the very end, it should look more like .bsa format, with blocks of informations that allow extensibility (each block announce its size, so if an implementation doesn’t support a block it can skip it). Extensibility means that i’ll not be the only one that will define block types and if artists need complexe shading with never-ever-except-once-in-a-life-used parameter i’ll not make my format dirt for that: it’ll become XSB+SpecialThingu, not related to the Xiaoyu Engine.
I plan to add script, images, sounds and some more things in it. For example it would be nice to have a “physic shape” entry.
The network is also home-made with a very political decision, but i can’t talk about it now, i need to finish it before. The main idea is: a human should stay the boss of its computer, always, and every message from the network should be treated as a hint. I hate the “server-client” approach and i think that a mailbox (physical one with two flag on it, one for “something new in the mail box”, one for “something to send in the mail box”) should be a good new approach. Also, push a “find near network” would be amazing, throwing away the mere idea of a central server who is the big boss and dumb clients etc.
Well, i told about it more than i expected …
For the gui, it’s a small thing: a nine-patch mesh and over it an other mesh with a texture containing the text. I’ll merge both later and cheat with the shader to obtain the same effect. Also, the engine support 3 fonts: ttf (with a sdl-ttf as backend) a F256 (a font that handle ascii encoding … not good, will likely disappear soon) and an other home-made format, CSF (Clear Sky Font, from an older project) that support UTF-8 encoding and it based on a picture + an xml file (you can imagine it).
The inputs are handled in a new way (home made ) : in the idea, every device (mouse, keyboard, timer, in-game button, in-game door) is a statefulldevice, which is more or less … well, it’s hard to explain, but to make a long story short you can ask a statefulldevice question about its current state and about what happened since the last frame.
I also wrote a homemade handling of the gamepad, sdl wasn’t able to read it. So, i read datas from /something-i-forgot/js0 and give a meaning to it. It’s what i use in the video.
In the very end, Xiaoyu should be on its own linux distrib (XiaoyuX), specifically designed for game developpement. The idea is: too much project stay on the computer of the dev only because it’s hard to list all the library used, find absolute path, handle specific plateforms etc. This is also the reason why a console (the device) game crash less often, because devs know the target device. With in mind the idea that an OS should be an abstract layer between the hardware and the software it would be nice to have a linux distrib with a “burn image” button that will just burn the game on a playable distrib on a usb key or on a cd/dvd.
Well, there is a lot more to say, but it’s out of my mind right now.
Any comment is welcome. Also, everything rely on your validation (the projet is dead if you say that you want me to don’t use the idea of your game engine in mine).