Some Thoughts on the Beginning

Somewhat prophetically, last time we were here I said I would try to write more. So, of course by as early as the next day I was hit hard with the left hook of writer's block and the right of twitchy new project obsession. That leads me here, nine o'clock on April 30th trying to get at least something published this month. As usual, part of the problem was another blog post idea falling through I woke up this morning extremely tired and entirely too stupid to do a good edit, a feeling which lasted all day and turned my plans to do some laid back revising, proofreading and typing into enthusiastic staring into space segueing into this. What is this? I don't know, it kinda looks like a loose collection of thoughts I've had in my first month developing my own game full time.

We'll start with this month's hot productivity tip: allow yourself to be consumed by your project -- it works! Whenever I start a project, for work, for school or for myself there is always the risk that I will become obsessed with it. Sometimes this obsession is for something wholly unproductive, for example I have caught all of the (now 719) Pokémon but occasionally I get lucky and it's a thing that I'm supposed to do or that makes my better as a human being. A few of my friends have asked me how I stay so motivated, and excited about this project even without a boss looming over my shoulder, and it's always a bit awkward to explain that it's primarily a personality flaw, so I usually go into the fact that I really shouldn't be short changing myself, as it is a slightly less deranged factor -- I have the opportunity to spend several months simply going after my dreams without anyone else to tell me how, I should really be taking advantage of this. I'm making mistakes, I'm fixing those mistakes, repeat. I'm just really lucky that when I get my teeth into something it's easier to start than to stop.

A lot of the process up to this point has been warming up to get several species of ducks into several interpretations of rows. I'm writing, designing, and programming the game so there's a lot to be done, even though I don't plan on doing most of the final graphics I'm also doing a ton of sketching, though largely floorplans at this point which are more challenging than I expected them to be. As previously mentioned I'm a paper weirdo, so of course a lot of my workflow is running through pens. I have a Rhodia, reporter style, N° 6 graph pad that acts at the central dump related to every part of the game. It's the master notebook complete with the unriddling programming problems, interface diagrams and lore bible. That definitely works for some things, but outlining the game proved more complex than I initially expected and eventually took the 80s conspiracy theorist approach and started using note cards on a bulletin board connected with string.

When I used to write text adventures, a notebook with "Choose Your Own Adventure" style numbering was sufficient to plan every detail, but a text adventure gives you a lot more control over the players than does a first person "stealthily dig through someone else's private notes and possessions". I don't know what areas the player is going to explore first, they may miss a vital clue no matter how obviously placed it is and these things affect the story as they interpret it. I want the game to be challenging but not opaque. A few weeks ago, I was agonizing over a detail that probably would not make that much of a difference to the story and my partner told me point blank that I was getting a little too detailed in my planning, and that one of the things he likes about games like mine is that there are some ambiguous plot points. I told him (less eloquently than this) that while I agreed with his conclusion I didn't think it followed necessarily from his premise. A big chunk of this is how I'm telling the story, I'm dropping a pile of information on the reader but only through hidden items, scraps of paper, and overheard snippets of conversation there is always going to be ambiguity when you tell a story this way, and just because I think it happened one way does not preclude the player from coming to a different conclusion. I've described it to non-game-people as trying to write a novel with no control over your protagonist and not surprisingly it is a real challenge to tell a cohesive tale in this way.

Finally, I'll talk a little bit about Unreal Engine and how it's been going for me. (Actually, as an aside before I get to that the game is going to be closed source for awhile while I decide what I'm going to do with the game starting at the end of this being my full time job in August). I'm still not sure how this relationship is going to go.

On the one hand I am really glad I went with an engine that has a very modern took set. I like that I can play the application inline in the editor and even manipulate the scene from there. Where Unreal runs aground for me is its Visual Scripting Language Blueprint which is ostensibly a set of drag and drop boxes you can use to build a game, the marketing copy says it's possible to build a whole game in Blueprint and I believe it.

I even understand how Blueprint would be useful, if you were new to developing games, for example or were working on a team with non-programmer folk. I, however, am programming folk and wanted to build my game in as much C++ as possible because after years of software development I consider touching a mouse to be a waste of everyone's time. Building the full game in C++ is still possible, but the community reply seems to be a resounding "why would you want to?" Finding how to do things in C++ can be challenging -- guides and tutorials can be pretty middling, and some issues have a Blueprint resolution and nothing else. I've eventually hacked through the docs to find the answer that I want and it probably built character, and I am likely a better person but it was a bit more effort than I thought it needed to be.

I admit, that part of the problem could well be my C++, I'm still learning the ropes of the language as compared to Java or C# but the exuberance surrounding Blueprint does seem to blot out a lot of C++ info. In my opinion.

Anyways, that's how things are going. This post may get a huge edit tomorrow when I'm not bizarrely overtired for exactly no reason.