While still progress is slow I try to tell you guys something about the editor user interface. Decisions where to make the editor in-game for easy access in full screen mode. So far it’s doing it’s job very well. I reworked the editor’s graphical user interface images to some eye-candy that looks pretty good for now.
Currently the editor and UI are able to create, delete and switch scenes, display images, browse through files, transform the camera, and see some logging, browsing and place actors (moving and selecting needs to be implemented at some time). Basically the basics. I try to keep the editor to a minimum as possible and use notepad, paint and other tools to create the game. But eventually you always need some in-game-tweaking. And that’s where our nice user interface comes in handy!!
As I’m fairly busy last few months game development has almost frozen. So to heat things up I will
make a simple post regarding the file format we use in our games and engine.
We had the following demands:
- Easy to read for a human
- Easy to read for a computer
- Easy to extend
So with this in mind we looked at some existing file formats:
- Ini: Easy to read for a computer and a human, but no nesting support.
- XML: Easy to read for a computer, but not for a human.
- Binary: Very easy to read for a computer, not for a human.
So we cam up with our own format: Data Files.
It’s basically a combination of an ini file with the nesting of XML defined as follows:
We have nodes. Nodes can contain new nodes and key-value pairs. Key-value pairs don’t have a
primary key and can only be one liner. Basic design that’s pretty good readable for a human and a computer!
We also have a special variable defined. The “@(…)”. This defines that there’s a value that contains
a variable value. For example the “@(path)” contains the path the file is located in.
This is very useful for fetching a file in the same directory: Texture=@(path)MyTexture.jpg.