I mentioned previously, in my UNDERTALE blog, that I started working on a game. And that little side project has all but consumed my life for the past month. (Apologies to any and all waiting for Balance Book 3, it has been put on a back burner for the moment. But will resume in earnest when this project is done.)
What was to be an experimental jaunt into the world of coding and programming has taken on a life of its own; a life populated by important sounding terminology that had been gibberish to my ears only weeks prior. Phrases like “parallel priority event,” “cyclic execution process,” and the ever appropriate “event encounter region,” all of which have molested my brain to the point of nearly bringing me to tears. That is to say, ladies and gentlemen; making games is really difficult.
I, like the majority of normal humans, have never given much deep thought to how exactly a game is made. And, I can confirm, it is more complicated then assumed by a long shot. Yes, I’m even using software that simplifies the process a great deal. And, frankly, that programmers have created games without this software at some point in history, is utterly mind boggling. I cannot even begin to fathom manually typing up hundreds of thousand of lines of code, with even one incorrect punctuation point rendering the whole lot useless. I now give those pioneers of gaming a moment of silent recognition.
Say, for example, you want a man to walk into your virtual room, (one that will have been lovingly created in advance,) and address the player character, telling them they are about to set off on a quest wrought with danger and peril. Easy, right? Click on the man, click where you want him to go in the room, then click again and type in the dialogue you want said. Yes? Ha, ha, ha. No. There is no man, there is no door, and the room you so lovingly created is nothing but a grid of graphics tiles that in no way whatsoever relate to a real “room.”
The door is a square that holds code; what it happens to look like, (or what disguise it wears,) is irrelevant. It is an “event,” and an event is never a “door.” It may look like a door; it may appear to “open,” it may even make a squeaking hinges sound. But it never does any such thing. The “opening” part is an illusion; a display of visual graphics that show your eyes a wooden structure swinging on hinges. But what is really happening is that an “event” has changed its state from being “solid” to being “through”. That is to say, it has allowed another event to change its location on the X/Y grid, beyond the door’s location on the X/Y grid. It doesn’t do so automatically. You have to make it run that cycle, when the time is right. (I speak now for one specific kind of game creation. It may be different in other cases.)
That man I mentioned? He is a square with a cycle of “walking man” graphics wallpapered over it. Yes, the door and the man are both events; squares that have properties. The door and the man are, therefore, I’m afraid to say, about as complex as each other. (This may explain why GTA civilians are so daft. They are clearly not that far removed from their door brothers and sisters.)
So, you wanted the man to walk through the door? Alright. Time to give this man a brain. It looks like this; move left, move left, move left, move up, move up, move up, stop. Shall we make him open the door now? Trigger event; door; open. The door is now triggered; it changes its state from being a “solid” object to a “through” object. The man may now pass through it. Move up, move up, move up. Trigger event; door; closed. Did I mention if the “man event” is stuck against a “solid event” (square that wears the disguise of a wall) at any point, the game will crash? (Unless the “man” event is a parallel process, in which case he may attempt to walk through the wall all day long, and be a burden on your resources.) Starting to get the picture?
Ladies and gentlemen, game making is not just difficult; it is also insanely time consuming. I have spent more time entering the code “move up, move left, move right, move down” in the last month then I care to mention. I won’t even venture into explaining how long it took to change a map from being summer, to winter, with each graphics tile having to be manually replaced to show snow.
So what, you might be asking now, exactly is the reward for all this nonsense? And is it worth the effort?
The answer to the second question is a resounding yes. At least for me. Designing a world, populating it with characters that have visual representations, and creating a story that can be seen as well as read, is a new experience. I have never had the pleasure before, and doing so now is like living a dream I thought would never be realised. (No matter how simple the visuals are.) The feeling of liberation, once you get your head around the coding part, is immense. Whatever you want, it can be done. Sure, it may take a little time, and may require a bit of mental gymnastics, but ultimately you may create whatever you can imagine.
The answer to the first question I guess I’ve already answered. The reward is seeing an imagined world come to life. And bringing it to life yourself; one step at a time, one time consuming task after the other. Will people enjoy what I’ve created? I have no idea. I’ve never created a game before. But whether they do or not, I will have the satisfaction of knowing I built a world. Just me, my laptop, and a whole butt load of time.
This project is on going, and I intend, if people like what I have created, perhaps making game development something I spend more time doing. The trick is, of course, that the amount of time required isn’t cheap, if you’re not getting paid for said time. A friend suggested running a Kickstarter, and attempting to raise money to make a bigger, better, game. And I just might do that.
I’ll write more about this project in the future.