Tag Archives: debug

For the past many weeks, I’ve been focusing a lot on the development of the animation sheets. But because of this, I hadn’t touched the former aspects of the game for some time, and when I got back to it, there were some issues that were brought to the fore, such as the Beltway being broken. To be honest, I was utterly surprised at this, since I had no recollection, or notes, that say that it had been broken when I left it to develop the other parts. There were also other things that I noticed that needed changing as I tested the implementation of the animation sheets along with overall player movement.

I found myself a bit overwhelmed and a bit tired, as I sometimes do, from having to debug C2 events. For all the user-friendliness it has, it can still be be quite opaque especially if you’re trying anything abstractly complex. It’s not totally the fault of C2, but because of its lack of modularisation, or object-oriented framework within the event system, picking apart why something doesn’t work requires a bit of jumping around, trying to sort out which are workarounds to some weird behaviour, and which ones are meant to do something actually functional.

Anyway, for several minutes I stared at the monitor, and I was seriously debating why I’m developing this game in C2, and not in Unity, where I have some experience in, and the fact that I’m actually good at coding (at least good enough not to doubt my ability to see the project through). Not only do I code, but I’ve been in the CG industry as a 3D artist and TD for 15 years now; on that alone, Unity is more of a familiar programme than C2. But I had a discussion with my wife who takes these technical diatribes with calmness and puts out good arguments, and the result is my rethinking of my situation.

So the question is: why C2?

It began with the fact that C2 made things simple. But what I’m doing with CITIZEN is not so simple. And that reason seemed to be not good enough.

C2 is fun because of the event sheets. But though the event sheets are effective, they are effective as procedures. They are less fun, and less effective when you want some object-orientation or inheritance, which is so useful when when I started delving into certain gameplay concepts that I wanted to implement for the game.

But I think one of the strongest reasons is one of a balance between a simplistic framework, and the relatively blackbox type of plugin filtered into the C2 editor which results in less bugs during development. This is both a pro and con. Taking Rex’s GridMove/Board/SLG/InstGroup system. These are separate systems working together as one. But it has some learning curve to understand how it all of them work. In fact, some components actually need the other, so they’re really necessary modules in order to come up with something like an isometric grid framework. But once this framework is up, the input and output (eg On reach target, On move accept) is unambiguous, and can interact naturally with any other event/behaviour in C2. Why unambiguous? Well, first, the C2 editor registers the event, so it’s part of the choices. Unity, on the other hand, can be quite confusing in this respect; what event handler is being called?; a search through the documentation is necessary.

In Unity, it is possible to get a well-written framework, but you’re going to have to try it out first before you know what you’re going to get. Sure, that’s the same with C2 plugins, but the C2 plugin framework shields you from some the randomness of 3rd-party scripting. C2 plugins follow C2’s rules in order to play nicely with C2. You’ll spot a lemon faster.

But I think the most important aspect to plugin frameworks is simply that they can be added in without messing things up. I don’t have syntax errors in C2 compared to Unity, so if something doesn’t work, syntax doesn’t necessarily some into the picture. Even data types are managed.

I think the best example I can think of is trying to implement Unity’s 3rd-person controller setup to your own game. There’s so much going on in that package that if you try to fix it to behave how you want it, you’re going to mess it up so much that you might as well write your own to begin with. Unity is so flexible, but unless something is so well written, with open-ended framework development in mind (like, for example, PlayMaker), the Unity environment is pretty much like a sandbox.

C2, on the other hand, is more like a playground. You can’t move the playground that’s there, but you can add other stuff into it, transforming it into something new.

At the end of the day, this is just a hobby so it’s important to have fun. Fun is a major motivator. It’s obviously not fun when I have to deal with the awkwardness of C2, or when I have to refactor my events. It’s not fun when I accidentally change the image-point on one of my images and having no undo option for that. But nevertheless, it’s fun to figure out how implement features on an engine that offers a good starting framework.

Without a doubt (in my opinion, at any rate), it is primitive tool when you consider other production engines out there, open-source or otherwise. I think it is easy to outgrow the tools due to the ever-expanding ideas for a game. That’s partly why I had to limit the ideas that I was coming up with. Is that a bad thing? No, but I think I should like a separate post about that. 🙂

I think, however, in the future, after I complete CITIZEN in C2, I will more seriously consider using Unity for other projects that may require a more expansive toolset, especially one that may yield a better game by going 3D.