Tag: Process

A New Project: Untitled Game

Xavier describes his creative process in making a (currently untitled, text-based) game and discusses other topics such as programming, game development, and linguistics.

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:

  1. 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.
  2. The game will take place in Kithria, the world I have created for low-fantasy stories, games, and whatnot.
  3. 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.

Planners vs. Pantsers

A little blurb about the writing process, some info on Devilspawn, and a hint of life advice mixed in.

A common divide in the writing community is that of Planners and Pantsers. For those who are unaware what this divide is, the former is as their name suggests. They plan their story, outlining, creating all the major characters beforehand, and knowing, from the beginning, exactly what the story is about. Ultimately, things will change – perhaps things don’t go exactly as they expected, or they noticed plotholes that weren’t evident in their initial plan.

Pantsers, on the other hand, do the exact opposite. Their name is in reference to writing ‘by the seat of their pants.’ They do little to plan beforehand, simply starting to write and seeing where the story takes them. They create settings and characters as they emerge, often having a vague idea of where they’re going with things, but with no clear path to get there.

The divide between these two is most evident in that each often finds their own methodology superior. Planners will give new writers the advice to outline and plan everything beforehand. This will often result in a very hardlined story and the finished product will look very much like the first draft. Pansters will give new writers the advice to let the ideas flow through them – let themselves have a trash (or other, less savory, words, if they prefer) first draft. Then, write the second draft in such a way that it seems you knew exactly what you were doing the whole time – much like a Planner first draft. So, ultimately, it would seem, they end up at the same point, just with a different methodology to get there – a methodology dependent on the personality and thought processes of the author.

This can also be compared to the Meyers-Briggs Type Indicator (MBTI – a popular personality assessment) dichotomy of J and P (Judging and Perceiving, respectively). J’s, within the MBTI, are those who dutifully plan, creating schedules and itineraries, while P’s are those who tend to be more laid back about planning – they still plan, but, for those who strongly lean to the P side, every plan is penciled in; nothing is set in stone. It is known, among those who properly hold to the MBTI, that being strongly one way or the other is unhealthy, and, should someone strongly lean one or the other, they should practice moving more toward center, living in a more moderate manner. As stated by Aristotle (and, to a degree, Solomon before him and Paul after), the key to living a good life is moderation.

The same could easily be said of Planning and Pantsing. To lean more toward one side or the other will not result in an opportune story. Planning everything beforehand – having an outline, with specific characters, settings, and whatnot – disregards the minute, yet important, details that, on the surface, have little impact on the story, but can, in the end, inspire fantastic subplots or twists the author never would have thought of otherwise.

On the other hand, pantsing everything – writing with a vague direction – will result in unfinished stories, with a shoehorned ending that attempts tying up every plot thread in a neat little bow while leaving plenty of frayed ends and holes in the finished product that can be difficult to fix with new drafts without scrapping or adding entire chunks of a story.

I have, of course, seen ups and downs with both these methods in my own writing. My beta readers’ favorite characters (one of which ultimately became the actual main character in Devilspawn: Tara) wouldn’t have existed had I planned everything beforehand. As well, any time I try to plan something, I forget those small important details in the planning that are so important to the story itself. But, when I plan little, I find an issue with knowing where I’m going. With Devilspawn, I got to nearly 70,000 words in the first draft with no end in sight. I did as I previously described and shoehorned in an ending that was satisfactory to my beta readers of the time, but felt lackluster to myself. It felt like it was the ending of an entirely new book as I introduced new plot threads by tying them up. Ultimately, this is what led me to write Devilspawn as one novel in two books – the first book is what was the first two-thirds of the first draft, with more details and shorter, though more frequent, time jumps, made to be longer than the entirety of the first draft (the original first draft was around 85,000 words while the ‘first draft’ of Book I is over 90,000), and ultimately tying up the two main plot threads: Agathon’s search for his brother and his loved ones’ reaction to his disappearance. The second book will take on a couple subplots from the first book as main plots to round out the narrative itself.

As well, I’m much better at making up characters as I write than making them up beforehand. My original plan for Agathon and Sarah (a supporting character who was originally planned to take much more of a front-line role, similar to Tara) was hot garbage; both characters, and the ones I made up while writing (because when I was making the Satanists because my brain went ‘yes, 7, that’s a good number’ – should you read the book, you’ll notice I removed one as he turned out to be underutilized and didn’t serve a strong narrative purpose) turned out to be much better than the ones I prepared beforehand. I believe this to be the result of the fact that I was creating the lore for characters, rather than actually making character’s as described by Matthew Colville in his video on Lore vs Writing.

But I digress.

On the nature of Planners vs. Pantsers, I propose this: do both. If you are good at planning things out beforehand, do that – but not too much. Maybe plan a few chapters ahead as you’re writing (this is what I’m doing with Isle of the Dreamer, though the actual second chapter was never outlined at all and the outlined second chapter will be the actual third chapter). If you aren’t too good at planning things ahead (like me, see the paragraph above), write chapter by chapter, asking yourself at the end of each if you’re moving toward the end of your novel (if your novel is the sort which has a main plot). In both, remember to keep the end in mind.

So I suppose the two main takeaways can be found in the Bible: do everything in moderation, and keep the end in mind.