Day 344 : Gooey Gui

I never thought something so trivial would end up being such a quicksand. Again it's great that something like CEGUI exists and that people took the time to build such a system and share it for free, but at the same time it's such a mess that, considering how trivial and limited the GUI requirements of my project are, it becomes legitimate to ask myself if it would have been faster to build my own GUI system from scratch.

I've spend the last weeks ping-ponging between the ideas of either taking TaharezLook and modifying it with the look of my game or create my own skin from scratch. I started with the latter and was faced with the mishmashy reality of the CEGUI system. Not the best design I've ever seen. Forums don't give a lot of answers either. XML files upon XML files of redundant data. For example, suppose I want to rename TaharezLook to SomethingElseLook, I'll have hundreds of occurrences of TaharezLook/ to search and replace with SomethingElseLook/. And a single mistake in one of the 4-5 XML files that constitute a skin will yield weird error messages that don't help pinpoint the problem that much. This just shouldn't be.

Anyway, after 2 weeks I give up. I'll just give a quick coat of paint on top of TaharezLook and be done with this. It's not critical enough to justify the extra delays. I'm entering a rather critical phase of development. The plan is to have something playable at the end of the Christmas vacations on the 14th. And not a prototype but something complete. GUI, mission/weapon selection etc. Let's see how this plan holds up.

Day 331 : Collisions and GUI

I think I'm pretty much done with my collision system. It doesn't hold a candle to any real collision system out there but for the needs of a rail shooter it will be enough. Roughly a combination of AABB bounding boxes in a tree. I needed it fast and simple. Trying to integrate OPCODE, even with OgreOpCode, wasn't smooth enough, so I skipped. Keeps the engine nice and light and avoids an extra dependency.

I'm switching road right now and moving on to doing GUI for menus and interface, as well as finalizing the adaptation of the Shmoulette engine with the game (there was still some splashovers on both sides, I'm now cutting them to be nicely and cleanly separated).

I'm using CEGUI for my GUI. So far I love it. It's a bit rough around the edge and the .XML structure could definitely use better hierarchy, but overall I'm impressed. The original plan was to cut as much as possible in the GUI and limit player options to a bare minimum. But since I'm getting a nice, clean GUI system free of charge I might actually put in all the options I want. I'll see.

The reason I moved to GUI design even though the game module itself isn't complete (I have no outstanding issues with it, but I know they're there, I just didn't find them yet) is because I was getting a bit tired of the loop I was caught in. Start to design a level, find a flaw in the engine, correct it, go back to design, find a flaw in the engine, rinse, repeat. So I'm taking a break from that and will work on GUI which is easier and thus more relaxing. Besides, learning GUI will help me turn the crappy editor I made into a slightly less crappy editor, which is always good.

I'm still on track for a somewhat complete 1 level gaming experience after the Christmas break. Should include main menu, profiles integration, in-between levels interface, and 1 complete level, art and all. With the exception of textures on models, for which I will accept placeholders for now.

What I'm getting the most fed up with now is compile-times. They get bigger and bigger. I feel I'm spending about 1/4 of my time finding bugs, fixing problems and implementing, and 3/4 of my time compiling. Not so good. Maybe I need a new PC...