Category Archives: Ramblings

Blog retirement?

This blog has seemed to run its course. I have actually started and finished something, which is cause for celebration. But now I’ve started on Unity development and to avoid crowding this area with information, I’ve started another development blog aimed specifically at the development of CITIZEN in Unity. There’s only an introduction there yet, but it’s just matter of time before I start rambling on again.

Now, my only hope is that I can finish that project as I have with this.

However, it is conceivable that I might create a different isometric game using the framework that I have developed in C2. If I do, then I will continue add to this blog any new material or documentation.

Thanks for reading!

Advertisements

Prototyping – A Killing House

After six months (almost seven!) I can say that I’ve reached what is effectively the ‘end of the road’ insofar as the Citizen prototype is concerned.

I’d like to recap what I am trying to accomplish in this prototype.

I am very aware of my inexperience; I’ve never done a game before, and so I don’t know what works and what doesn’t. I only have my own taste and sensibility for what it’s worth. Though I believe (or hope) I can pull it off, I don’t know what it really is, so this prototype has been an effort to put all the ideas that I’ve come up with into one package. I thought to myself that creating systems for a game is relatively straightforward. But can I integrate any number of those systems with each other, and have them work? If I can manage that in a prototype, then I would have the blueprint for an actual game.

I created this prototype with that mind. And having experienced the troubles of illogical inconsistencies in system, bugs of a generic sort, it feels like I’m about to ‘ship’ a game without the danger of flagellation from Steam reviews.

This is my version of the Killing House, where I rehearse and train for the game I’m going to make. I’m using live rounds and making it as realistic as possible because I want to, as much as possible, be prepared for the task up ahead. I put as much effort into it because if I can get this to a level that I’m happy with, then it’s quite possible that I can pull it off when I make the final game in Unity.

Making the prototype itself was grueling enough. I don’t remember burning so much midnight oil since I was a fledgling 3D artist back more than a decade ago. Not every idea or implementation would make it to the end. But none of those aborted/abandoned things were wasted on the experience of trying to make it.

For example, the game narrative script that I wrote at the beginning is now completely different. However, it served as a springboard for identifying and designing the systems I need to have in place, so it was still a profitable and necessary first step.

There were other ideas, like the ‘Multi-Vision System’, ‘Stacker’, and ‘Map Layers’ that I dreamed up up that had to be thrown away due to either being too oblique, complicated, or just plainly stupid.

Also, I had created and rendered NPC assets which were not used in the final version of the prototype due to a change in narrative.

While there are clear advantages working in Unity — certain bugs and limitations that I’ve encountered in C2 will no longer be relevant — I’m aware that I’m facing a world of hurt in Unity-land, too. Naturally, I will take advantage of what Unity has to offer, as well, such as a full 3D environment (something which I’m comfortable with), dynamic lighting, and a robust pathfinding system, among others. All the while, I must remember to keep it simple. It’s possible that I may have to even dumb down the game more so in Unity, to keep it within my capabilities.


Sights…


Towards the end of the development, I started working on a introductory cinematic, which was a fun thing to do. It wasn’t intended to accurate represent the all the details of the story but only to give a good idea what it’s all about. Here are some screen shots:






Here are some additional screen shots demonstrating how it looks like.

Sample environment. On-screen interfaces (bottom, upper-left, upper-right)
Sample inventory screen. Item descriptions, icons.
Sample dialogue panel (Convo). Portrait.

I posted a gameplay sampler which demonstrates some of the systems in action.


… and sounds!


I’ve also cut up some audio (re-learning Cubase again!) to use with the prototype. I may post a complete playthrough in the future, perhaps after some of my friends play it first themselves and hopefully give some feedback.

 

Why not C2?

(This is a follow-up post to my other one which explained the reasons for choosing to remain working in C2).

When I review this whole venture, it stems from the desire to create a game on my own.  I want to create the graphics, the logic, the story, the words, the music — everything — like how those guy did it back in the day when I was a wee child playing their games.

I came to use C2 because of its simplicity, and the quickness in which I can throw something together and get results. There’s nothing like instant gratification that hooks you in.

But as project size increases, so do doubts about working in C2. Lots of niggles, lots of creaks and groans give me doubts as to appropriateness of the engine/framework for Citizen. A framework is a convenience. But everything out there is a convenience except C++. I could have approached Corona or Phaser, I could have used Godot or Unity, and some of them might have been more suited to the task.

When you turn to an established game engine like Unity, you don’t tend to have that many doubts that your main goal is achievable if you were clever enough to code/design your game well. That’s because you see the sort of games that have already been developed and you can’t really argue with the fact that Unity is established for a reason.

Then you take a gander to notice the sort of games that C2 is generally used for, which is not the sort of thing Citizen is. There are plenty of developmental previews and tutorials of isometric games, — none of them are serious enough to take umbrage — but no finished product as far as the Search Engine can see.

Then one day, you come upon some kind of undesirable behaviour that you have no control over (because Construct is a very blackbox environment). You start weighing in the facts: that C2 isn’t being developed any more; that critical bugs appear in the latest builds; that downgrading is the only recourse because the developers will likely not fix it because they are committed to C3, an app whose design philosophy doesn’t nearly tick enough of your own boxes for you to use with dignity.

These leave you imagining the sort of adventures you’ll have with this little boat, which will receive no more refits, as it takes you across the pond. What awaits you, who knows? But there are tales of show-stopping, insanity-inducing odds, and some are journalistic facts as the asset obfuscation that you won’t get.

 

 


At the end of the day, it’s a ‘use the right tool for the job’ situation. And as the days go by, C2 (and C3) are becoming less of the ‘right’ tool to actually publish a game. But as many C2 users know, C2 is great at prototyping. And so at prototyping it will be relegated to.

Even if from some miracle I complete the prototype and I am able to scale it to encompass the scope of the game I want to make, it will still be a hard-sell for me to publish the game in C2 because of the absence of even a rudimentary obfuscation method: another design philosophy that didn’t get ticked.

We shall see…

Limiting the vision

As I asked in my previous post, is limiting the vision of a game due to technical limitations good or bad? Should we look to other tools that would live up to the expectation of accomplishing that vision, or should we just stick with what we have and make the best out of it?

But I think my question touch a more philosophical note in me, and I’d like to write it that way.

Vision?

What do we mean by vision? Let me put it honestly in the argumentative spirit it came from: when someone says they don’t want to ‘limit the vision’, and when they’re relying someone else to actually realise the vision, it means that they want a free ticket to every ride in town, at any time, for any reason at all. What they mean is feature creep. They might want to add stuff in; particles, explosions, heavier models, bigger textures, other bells and whistles. They might want to add a new kind of gameplay because they think it’s more interesting. Or maybe they want replace the whole engine.

They might say they’re expanding the vision of the product. They put it that way because it sounds better than ‘I changed my mind, because I was never really sure to begin with; let’s do it this way instead.’ Better not to look as dumb as they really are, so they make it out they had this in mind all along.

When you work alone, your decisions will echo in your bones, because if you decide to change game engines, you’re passing sentence onto yourself and doing the time yourself. There’s not much room for ego because there’s no one else around to pass the buck to.

But when more people are involved, let say in a thing called the Creative Company, ‘expanding/modifying/altering visions’ becomes a problem because it’s easy. It’s easy for people who are actually detached from the actual creating process to think of ideas. When there are no consequences to your thoughts, you obviously will just think of any shit that comes into your head, right?

So, am I saying, that easy==bad? Sure. Because it’s usually borne in the bed of laziness. easy==lazy. That’s precisely why it’s bad. That’s precisely why it’s not an idea you can depend on to be sound, no matter how clever it sounds now. Some people in the past introduced the argument that it’s helpful for ideas to be free from the burden of the hard toil necessary to achieve it because, said this person, if anything is seen too hard to do, people will likely lose heart and abandon an idea that would have otherwise been brilliant. Fair point, and it explains a lot of great things in the world, like slavery and cotton fields, to name one of many. Despite its seemingly sound reasoning I’ve only heard it from the mouths of those who don’t know or don’t want to dirty their hands to work the fields. I think my reasonable answer to that argument is that if people forego a good idea because it’s too hard, the only thing lost is the elite’s vainglory, and we can definitely lose a bit of that. And, perhaps the idea is simply not good enough to sacrifice what has to be sacrificed. Perhaps the idea is only good for those who have nothing to lose by having it.

Technocreativity

I think that creativity is expressed primarily by the limitations we impose on ourselves. I don’t believe in the propaganda that boasts that you will can express your creativity because new doors/features/tools/technology have now been opened to you. For example, as recent as a few months ago, a Disney-esque Samsung ad declares at the end: “We make what can’t be made so you can do what can’t be done.” Clever and nonsensical advertising, sure enough, but the point they’re making is even more nonsensical. The consumer actually does nothing. All they’re doing is — what’s the popular verb for this nowadays? — consuming a product. Or they’re consuming an experience. You’re made to believe you’re empowered.

So, in the same vein, is technology empowering us to be more creative? No. We are just more reliant on technology to express our creativity. It shapes or forms how our expressions look like, but it doesn’t necessarily improve them; it doesn’t make us more creative. We might have a greater palette to choose from, but excepting those who are obsessed by stats, why should we give a fuck how much greater our palette is? But that is the problem, isn’t it? Aren’t we all us obsessed by stats? Don’t many of us largely concern ourselves with specifications: which has more VRAM, more Ghz, less latency, more bandwidth, read/write speeds, terrabytes, etc. We are sold and are persuaded that we are better off creatively because we have better hardware or software. And I wonder, how should we rank ourselves against the people’s creativity generations before? Should we, given how we’ve technologically advanced, fancy ourselves superior?

And if new technology doesn’t make us more creative, why should we update our progs at all? Because new technology is our medium. We have no choice because we are born to it and to the dizzying rate of how it changes. But it’s no Muse of Creativity. It will not heal anyone of laziness. In fact, it is far easier to be lazy because there are too many conveniences at our disposal. And even the sincere among us are more readily confused because technological possibilities are too narrow a framework to build creative minds.

If technological updates are too fast, it is no sin to stay where you are. If you can keep up, move on to the new.

The only thing the differentiates a good and a bad decision is the laziness not to know the difference.

 

Why C2?

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.

… and the money is in the taking

(Part 2)

I see a kind of game devs that have a particular preoccupation with monetization. When I say monetization, I generally mean the kind that doesn’t just about selling your stuff on Steam.

Monetization brings a game dev into another framework. When a game dev has an issue with a component in their game that affects their income, it is not an issue they can simply forget. They have chosen a path and decided what their bottom line is. There is, on one side, the hobby of tinkering with games’ nuts and bolts, and on the other, the figuring out how you can be monetarily be rewarded from your efforts. Each balances according to their own tastes.

This points back to the first part of what I was saying. It seems to — partly anyway — explain why there is a such a big fuss when software doesn’t turn out the way you want. For professionals, there’s no time to screw around with incomprehensible decisions, and frustrations grow out of a need to produce results, and that is being undermined by some third party. It’s your job, your paycheck, your reputation at stake. It’s serious business, as all real businesses are. When you make your hobby into a business, it becomes a business, and it won’t feel like a hobby any more.

Game development — with its big studio and indie counterparts — is a whole different world. They have their own denizens, atmosphere, and grading system. It’s far from a desirable world, and heck, it’s not even particularly better than my boring one.

If there is a solace, a quiet place, a haven, where as a kid you dreamed about fascinating worlds, it’s not here, nor there, but temporally offset.

The fun is in the making…

There are two kinds of people. People who like to play, and people who like the make things.  And among those who like to make things, I can see two more kinds of people between them:

  1. Those who like making stuff.
  2. Those who like having made it.

Those who like making stuff, consequently, eventually — ideally — like the fact they made it.

And then there is a kind of person who prefers to have done it already. Of course, if it were already done before he started on it, then he couldn’t be considered a creator — and he wants to create. But if he could do it with a push of a button, or use an Imagino-matic device, that would be the most ideal situation.

But how much work does he want to do? Does he want to work just enough to feel like he’s earned a six-pack from a 2-minute calisthenic workout? Or is it like giving birth to a baby?

There’s more than a line, or a degree, or a quantification that crosses the boundaries of convenience and perseverance. How much automation is there before it’s actually automation? How much are we really putting in for the amount we’re getting back?

The nature of software is that we build on top of one another. We don’t write Assembly because there is no practical benefit to it.  But now, I ask a different question: When it comes down to it, would you be willing to start from scratch? It’s not about delineating degrees of laziness versus masochism. Instead, it is an attitude, an approach to life and learning.

There is absolutely nothing wrong with taking an easier route, especially if you took ‘hard’ to get to ‘easy’: you’re worth your own weight, like any good SAS trooper. But some people don’t want to take ‘hard’ at all. They just want to be shown a way that produces results. They don’t see problems as natural curiosities; for them, they’re irritants, not accelerants.

In the CG industry where I work, there are many varied roles, and people vary a lot in this regard. An animator has animation skills and he doesn’t have the inclination to rig a character, and I wouldn’t hold it upon him to do so. But I would expect him to be committed to all things animation. A modeller may not take interest in matchmoving, but his anatomy should be solid.

So it surprises me that there are so-called game devs who feel insulted to have been forced to troubleshoot their own game-related problems. But aren’t game devs supposed to regard game development problems the very point of game development? Isn’t this what ‘making a game’ is all about? Isn’t this actually the fun part?  ‘Making my game’ is supposedly what we enjoy. But in fact, what some people actually mean is ‘Seeing my game made’.

I don’t know. Maybe I think too old-school. I look at 2400AD and think Chuck Bueche, and the whole lot of them back then, were having loads of fun playing around with bits and pixels. And I am having tons of fun, too, and every bit and byte grateful that in this day and age we have such an easy time making games. But the thing is, I wouldn’t mind it at all if it were much harder.