Now, this raises questions about what is going on with Crown and Cutlass and how Broad Shoulder Development will relate to the Crown and Cutlass project.  We don’t have all the details ironed out, but really this is just a way for us to focus our development efforts.  None of the Crown and Cutlass source will be closed, none of the artwork licenses will change.  Unfortunately, in order to recover the cost of Apple’s developer program and other business expenses, we are planning to charge for the iPhone games we develop.  We will have to see exactly how this works out, but we’d like to do something along the lines of Ogre’s dual-license (perhaps GPL?) with commercial support.

Our current 2D iPhone engine is really a port of the work we did for Protocce, our new Crown and Cutlass engine.  We have simplified a lot due to the hardware restrictions, but I’m hoping that we can use the experience we gain actually using the engine on the iPhone to improve Crown and Cutlass itself.  As I said, we would love to get a version of Crown and Cutlass running on the iPhone too.  While the gameplay might have to be rethought a little, I think that would be very doable and really fun to play!  Anyway, all that is to say, we are branching out and trying some new stuff, but don’t worry Crown and Cutlass isn’t going away.

If anyone is still with us, watching the blog or the forums for activity, you probably have noticed a considerable slowdown in work. This has been caused by a couple things. First, and I think most importantly, is that fact that David went back to school 8 months ago. Since we work together on Crown and Cutlass quite a bit, our motivation often ebbs and flows together. Since David has less time to work on it, I find myself with less motivation. The other issue I have, is that when I take time off from Crown and Cutlass, I have a very hard time jumping back into the code. Getting back into a C++ mindframe from Delphi (which I use at work) is really difficult.  

Based on that, we’re going to be writing as much of the game play code as possible in Python. By exposing our Protocce engine to Python, we’ll be taking advantage of the rewrite work we’ve been doing as well as moving to a more hospitable development environment. I think this will speed up development on Crown and Cutlass by removing accidental complexity.

We’ve long talked about scripting as a major component to our game engine, but have always put it off for another day. Now, by using Python, all (or most) of our actual game code will be done in script. It gains us the flexibility of Python, while maintaining the speed of C++ in the engine. Anything that needs to be sped up can be implemented in C++.

I think is an exciting development for Crown and Cutlass. It gives us more opportunity to think about the gameplay and avoid the problems we’ve had at times in C++. You should be seeing more exciting developments over the summer as we make more progress on Crown and Cutlass.

Anyway, we are excited about PyCon. I am looking forward to learning about Stackless and there is a talk about embedding Python in Counter-Strike: Source which should be really interesting. Plus there is a bunch of stuff about Jython (“Jython on the Joint Strike Fighter”, how cool is that?!?), IronPython, and a many other talks that look good. Unfortunately, it doesn’t look like you can link to descriptions of individual talks, but if you are interested you should be able to find what I have mentioned in the complete list of scheduled talks without much effort.

If anyone reading this wants to get together at the conference, let us know. I’d enjoy meeting some people who have interest in Crown and Cutlass, and you could give us a hard time about not making more progress on the game!

I really have not quite gotten used to the way the filesystem is arranged. I guess I am comfortable with it not being like Windows, but I want it to be like linux. In Windows, there is no “/usr/lib/” or “/usr/local/lib/” for libraries so you put them somewhere else (like “C:\OgreSDK” or in program files or something). In OS X there is a “/usr/lib/” and “/usr/local/lib/” but it looks like the preferred place to install libraries is into “/Libraries/” which is just weird. Which should I use? Should I treat it as a unix machine, or embrace the weird OS X stuff?

The keyboard also is a little annoying. I want a “home” and an “end” key. I want a “del” key that is separate from the backspace key. I guess you can do “command-right” to get to the end of the line, but that does not seem to work consistently in all applications. I also really think only putting one mouse button on the laptops is a poor decision. And no, I don’t buy the argument that using modifier keys for things like that or to get a right-click is somehow more efficient.

I am also trying to figure out how to get dependencies for Protocce installed. Ogre was really easy since they provide a framework. If I remember correctly from his blog, Steve Streeting got a Mac recently so OS X has a higher priority on the Ogre team. The ogg and vorbis packages came with XCode projects to make frameworks, so building and installing them was really easy. I couldn’t find a binary boost distribution, so I built/installed it just like I would have in linux (“./configure && make && make install”). That is what boost recommends, but I’m not sure that is the OS X way to do things. At this point though, I don’t think there is reason to go through the trouble of making a framework (and really figuring out what frameworks are all about, how they differ from bundles, what a bundle is, etc.). Unfortunately, OS X support in CEGUI seems to be lagging behind. CEGUI seems to be kind of quiet lately anyway (Crazy Eddie appears to have left the project, hopefully it can rise from the ashes and continue strongly eventually). I am going to try building it from SVN where I hope the OS X support is a little better.

XCode seems like it will be nice. I need to try a “hello world” project in it, but it looks like CMake can generate XCode projects. That will be save a lot of work, since it will shield me from having to set up a project manually until after I see how Xcode handles projects a little. I’m sure it’ll still take some getting used to, but I’m interested to see how it compares to Eclipse with the CDT and Visual Studio.

Anyway, if you have tips on getting started with development is OS X, let me know. I found Apple’s getting started page and it seems there could be some good stuff in there., but I have a lot to learn.

Also, because we are making heavy use of the event system, we can test the event sender and the receiver separately. For example, the SoundBuffer and SoundStream classes basically just send events to the sound system telling it to play/pause/stop a sound. In the test, I set my own listener for those events and verified that they are being sent correctly. Another place where the event system was useful was in the initialization of the input system. The input system needs some kind of window handle to give to OIS. Collin set it up so that the input system sends an event with a Variant window handle field. If it is initialized, the render subsystem receives that event and sets the window handle value. However, if you do not have the render system running for whatever reason (like in the input test), you can just register your own handler for that event. So in the input test, Collin creates a simple little window just to get input with raw X11 or Win32 code, and his test receives the event and returns the proper handle. The input system doesn’t care whether the render system created the window, or you did yourself. All it cares about is that something provided it with a window handle. That is pretty slick.

As I mentioned earlier, we aren’t doing anything fancy for user input/output tests for things like sound, graphics, or input. We basically do what we want and then ask the user “did that seem right?” That can get annoying if you are working on something like the sound system. Testing it is a lot of “did the music start?”, “did it stop?”, “did it start again?” kind of questions. It’s not perfect, but it is a simple way to verify that the code works. Compared to what we had it is a huge step forward.

Exception – We implemented the pcce::Exception class which we now use consistently for error reporting. Coupled with our greater focus on RAII (see below), I think we have made some serious progress. We used to use error codes sometimes and throw other times. Unfortunately, sometimes we threw strings, sometimes we threw char *’s, sometimes we threw ints, etc. This is much better. It does not descend from std::exception at the moment, but we are thinking about doing that.

Greater focus on RAII – RAII is really a great idiom for resource management in C++, especially when coupled with smart pointers like boost::shared_ptr. We have design for RAII from the start, so that should make things much more manageable. Again, I’m sure we have more to do in this area, but we have a good start.

Variant – At work, I have gotten used to using the Win32 Variant class in Delphi. While it certainly has its drawbacks, it sure can be helpful for doing things like reading text from a config file. Our variant class is cross platform, and based on boost::variant. I think it will change a little as we use it, but I’m pretty happy with it now. You wouldn’t want to use it when a statically typed variable will do, but for example the config system was really easy to do using Variant.

PropertyBag – Again, at work I got used to using “property bags” which are basically just a map from a string to a variant value. You wouldn’t want to replace all of your normal classes with a property bag (static typing can be nice!), but it can be really useful. For example, our configuration system is an INI file. That gets loaded into a property bag. When you initialize a subsystem, you pass its settings as a property bag. That way, you can change the config options around without changing the config object or the method signature. We have also used property bags to create “game objects” which are just property bags with a couple of predetermined fields for model name, texture, etc. The game programmer can put whatever else he wants in there.

Consistent use of shared_ptr – I really don’t mind managing my own memory, but once you start talking about exceptions and RAII, using some kind of smart pointers really makes sense. We are making pretty serious use of boost::shared_ptr, which has made a lot of things easy. No need to worry about who owns an object, as long as you have a shared_ptr to it, it will stay valid. Of course, we have to think about circular references, but overall I think using smart pointers is a big win.

OGRE – I think it’s pretty clear why I am excited about OGRE. Originally, the project was just an excuse to do OpenGL programming. I enjoyed that, but now I am more interested in other things. I’m a little sad not to get to try that from the ground up, but eventually we can revamp Protocce to use a custom engine if we want. Until then, using OGRE will simplify our code, standardize our models (our old model loading code was really picky), and open up the doors to easily implementing graphical improvements. It will also allow us to focus on the game itself, rather than the details of the graphics.

EventSystem – Our old code used to be very tightly coupled (see the SailingState for an example), so minor changes could not only cause a large number of units to need to be rebuilt, but also end up causing a large number of code changes. The event system is based on what is mentioned in Game Coding Complete and allows us to significantly decouple our code. Once an event is defined, you can register a boost::function to receive that event. Events can be dispatched immediately, or queued to be dispatched once per frame. I expect the way that will work is that game events will be queued, while internal “plumbing” type stuff will be sent immediately. As an example, the input subsystem needs a window handle to receive input. Rather than connecting it directly to the render subsystem (which would force you to initialize the entire render subsystem if you wanted to use the input subsystem), the input subsystem just sends an event that the render system receives. If you don’t want to use the render subsystem for some reason, you could just register a different handler for that event. Collin actually does that in the input test. As I mentioned in my previous post, the sound system is also event driven. It is running in its own thread, and all the main thread does is send an event that says “play sound X” or “stop sound Y”. That data is easily sent out to the other thread, where the actual sound code handles it. We can totally revamp the sound implementation and not touch client code at all. I think the event system is a much more flexible system and I think it will open up a lot of doors for us.

Improved resource management – I mentioned this a little in my last post too. Between the release of Alpha 1.4 and the decision to start the rewrite, I wrote a resource management system. It was pretty good. It would make sure that only one copy of a texture, sound file, or model was loaded at a time and used reference counting to automatically unload the model when it was finished. I have further refined it (partially based on the OGRE resource system) and posted a reply on gamedev explaining the Protocce resource system.

Anyway, there are other things but that is a decent explanation of the things that I am excited about.

I have gotten a good chunk of the way through moving the sound system into our new codebase. I think in general the sound system is much better now. It is a little ugly because it is running on its own thread, but I think that will be worth it. I have renamed the SoundEffect class to SoundBuffer (since it is a sound that is played from a single buffer in memory as opposed to one that is streamed from disk, which is done with the SoundStream class). It has basically the same interface as it used to, but now all the SoundBuffer does is fire off events to the SoundSubSystem (as you can see in the SoundBuffer implementation). Sources are still revoked just like they were, but now I am positioned to combine the source allocation for the SoundStream class too. I wrote a really simple class for reading ogg/vorbis files in a more C++ friendly manner. It allows us to use RAII and hide some of the oddities of the vorbis lib. I reworked our LoadOgg function that loads the entire contents of an ogg/vorbis file into a single OpenAL buffer so that it used the new OggFile wrapper, and it resulted in this diff. That is way more readable, so I’m pretty pleased with that. Now, I’m working on using that ogg/vorbis wrapper to implement streaming music off the disk. It’s nice to have all of my ogg/vorbis code in a single place instead of duplicating it like we used to. Maybe I should do something similar for WAV files. I also probably should rename all of our *Ogg* classes, functions and methods to *Vorbis*…

Anyway, it has been fun to rework the sound stuff using our improved resource management code and just the general better code base we have now.

As I was implementing it, it seemed like there was just going to be too much overhead for it to really be worthwhile. All of the scene nodes were identified by name, so in my unoptimized first-shot implementation there was a lot of lookups in maps of strings. I think we could have improved that to the point where it might still be workable, but the real kicker was 3rd party libraries… We decided to do this “per-subsystem” sort of threading instead of something more like a work queue with worker threads because we wanted to leverage mature, 3rd party libraries. We are excited to get all of the power of OGRE without having to implement all of that ourselves. However, most of the 3rd party libs are not thread-safe or multi-threaded. We thought if we controlled the updates to events that got passed to the thread, that would be ok. CEGUI really killed that idea, though. It is not thread-safe, and in our system it would need to be accessed by both the render thread (to display the buttons) and also the input thread (to handle input events). From what I read on the CEGUI forums and saw in their code, that just isn’t safe.

We had to decide basically whether to continue with our “it might work” idea for multi-threading and possibly implement our own GUI system, or just cut out all of that extra work and use the libs more directly. We decided to abandon our triscene idea. The sound system will probably still be threaded, but the input, physics, rendering, and game logic will all happen on the main thread. That clearly isn’t the best way to go with multi-core processors becoming with more and more common, but I think trying to use non-thread-safe 3rd party libs in a multi-threaded way is just a loosing battle. The only real alternative is to write all of our own subsystems (i.e. no CEGUI, no OGRE, no ODE), but at some point we have to just focus on getting a simple, well structured, singled-threaded (and actually running!) version of Crown and Cutlass instead of diving off into all that.

Actually, we decided to abandon the “game view” idea for now as well. We couldn’t really map that onto the rest of our design. Rather than continuing to bat ideas around that I think sound good but can’t quite get pinned down, I am going to focus more on getting what we have running. I guess that’s 2 fewer cool things I am excited about that, but at least we are getting close to working in Crown and Cutlass again for the first time in almost a year and a half!

PS We tagged the SVN repo before we deleted all this code. You can see the tag here.

In other news, Collin and I talked today about what we still need to do before we can start rewriting Crown and Cutlass game code using our new Protocce engine. That’s a significant milestone! I mean, it’s not as big a deal as actually using Protocce in Crown and Cutlass, but at least we are talking realistically about it. We are getting close to having something workable, and we are both really excited about the foundation Protocce will provide. If you are interested, you can take a look for yourself at our (slightly outdated at the moment) Protocce doxygen docs or at the Protocce SVN repository directly. If you really want to keep an eye on what we are doing, you could even subscribe to our SVN commit mailing list. I’ll try to boil some of that down into some specific things we are excited about in a future post when I have a little more time…