I’ve begun work on yet another project, because I have difficulty focusing on only one project at a time (or, rather, I have difficulty focusing on one project for an extended period of time, resulting in me rotating which project I’m working on).
The project itself is a currently untitled and I’m not sure what the main story will consist of (though I have a general idea), but I know a few things about it:
- It will be created using a game engine (story-making tool?) called Twine. That means that it’s going to be a text-based game, kind of like those old choose-your-own-adventure books.
- The game will take place in Kithria, the world I have created for low-fantasy stories, games, and whatnot.
- Like most of my other works, it will explore various social themes, including (but probably not limited to) racism and sexism.
Below are some of my thoughts so far as I’ve been working on the game.
Working with Game Engines
Disclaimer: I am aware HTML is technically a markup language and not a programming language, thus why, when I’m referring to both, I use the term ‘computer language’.
HTML is relatively simple as a baseline. Before I started working on this game, I had a little experience with HTML during my time as a CS major and the web developer for the Daily Egyptian. I could take a template that already existed and mess around with it to make the website I wanted. As well, I could make a (admittedly garbage looking) webpage from scratch fairly easily. What I could not do was create a beautiful webpage from scratch. And I still can’t. But Twine is based in HTML, so it should help me learn, maybe. Right?
Wrong!
I learned a similar thing when I first started working on Project Divus, in which I played around with Unity a bit. For those who don’t know, Unity is a game engine that is based in the programming language, C#. Making a game using Unity, however, requires more knowledge on how Unity works than how C# works. This is because Unity has its own classes, methods, and functions built in that the programmer needs to know how to call properly. Unless you’re adding completely unheard of functionality, the chances of you needing to know C# seem to be pretty slim, and knowing C# won’t make you proficient in using Unity.
This also applies to Twine. The only actual HTML I have used in the 6+ hours I’ve spent working on this game (at the time of writing) is to make a table so my buttons don’t look weird. Other than that, it’s all been calls to macros built into Twine or SugarCube (a sort of secondary engine built on Twine), none of which are accessible in basic HTML. Both pieces of the engine (Twine and SugarCube) have their own documentation, just like basically every computer language (Unity also has such documentation).
This all comes down to one main idea: engines themselves are, in effect, child languages of whatever language they’re based on. This is perhaps why creating an engine is so difficult and time consuming – in fact, many developers forgo it because creating a proper engine can take years for a relatively simple game – because you are trying to build a new language.
As well, this goes to show that just because someone is proficient in a given computer language doesn’t mean they’re proficient in engines based on it and vice-versa. Although, knowing a single language from a family of languages makes it far easier to understand other languages; e.g. object-oriented languages, such as Java or C#; or Romantic languages, such as Spanish, French, or Latin. Obviously knowing one language won’t make you fluent in the others, but I know of plenty of university students who have been able to decipher Latin documents because they know Spanish.
Nothing in Game Development is Simple
I already knew this was the case. Most people who have tried game development already know this to be the case (probably). Those who don’t know this to be the case would be anyone who has never tried to develop a game or watched someone develop a game (or who has used a very simple drag-and-drop engine, which generally aren’t powerful and are less of making a game and more making a level in a game unless you really know what you’re doing and you put a lot of time and effort in, but I digress). Making what you think could be the simplest addition to a game takes a long time. I mentioned before that I have spent 6+ hours working on this game in the past two days. All that time was spent on character creation (which I’ll discuss later), and that part isn’t even done.
On top of that: if you’re not careful, a single wrong word can spend hours to fix (especially if you, say, wrote a line of code that you knew you would be using again and just copied and pasted it to the new location only to later realize it was wrong). On the bright side, none of the bugs I accidentally included in my code took hours to fix. They each took half an hour, and there were approximately a lot of them. Most of that time, of course, is finding out what you did wrong; often, once you’ve found the problem it’s fairly simple (though it’s usually either changing a single character or sifting through the whole document to find every mistake). I once had a project to create a parser for a programming language in one of my CS classes; it took me 2 hours to figure out how to fix it (with the help of my manager at the DE of the time) and all I had to do was change a 0 to a 1.
So, yeah, programming ain’t a walk in the park. But you probably already knew that.
Trying to Make Things Interesting
I mentioned, like, a bunch of lines ago that I spent over 6 hours over the course of the last 2 days working on character creation for this game. That’s because I’m trying to make things interesting. You see, appearance (and gender) in this game is more than an aesthetic choice. My plan is to make it where characters in the game will make judgement calls based on what you look like. If you’re a Shelezar but look like a Mikri and the character happens to be racist against Mikri, they’ll treat you as such. If you’re a woman and you’re interacting with a character that thinks women are lesser than men, they’ll treat you as such. The flipside is also true: if you look like a Kapfian, military personnel may favor you because Kaps are known for their combat prowess. If you’re a woman, members of certain cultures will favor you because that’s their culture. And setting up the appearance mechanics – the part where the player determines the character’s appearance on top of the part where the game goes through and sees what people group they might be confused with – took me most of those 6 hours. That means that I definitely need to make that appearance mechanic matter. Because you shouldn’t devote time to something that won’t matter. It’s bold because it’s a life lesson.
The main issue I need to find out now (before I move on from character creation; that’s right, it’s not done yet) is whether I want to follow through on another idea I had: basing the game mechanics on Lady Luck’s Chosen Few. Right now, the mechanics I have set up for the game are fairly simple and much more reminiscent of standard TTRPG mechanics: a number is generated and modified by four attributes the PC has (in this case Endurance, Strength, Agility, and Wit) and the result of an action that has multiple (more than one) pass-fail states is determined based on the final number. It’s simple and it’s easy. Making a game based on LLCF mechanics will be far more complicated. That being said, trying to work those mechanics into a text-based game like this will be a lot easier than trying to work them into a more standard video-game. So, I still need to make a decision on that.
Conclusion
So far, I’d say I’m happy with this project. Despite the pitfalls I’ve run into, it’s going pretty well and I’m making some decent headway. Admittedly, I should maybe not be putting another project on my plate, but I’ve decided to disregard that fact in an effort to add one more thing to have consistent updates that I can share publicly, alongside Isle of the Dreamer. So I’m making this now.
Xavier Makes 