#0029: Dev-blog #001: plans and preparations (‘Remote PI’)

Preamble

I wanted to create something of a diary to collate my thoughts, experiences, and general progression towards completing a large multimedia project. One with a significantly wider time-scale and scope of disciplines than I am accustomed to. It will be a multi-session project that will require several months to assemble the knowledge and materials, necessary to ultimately produce a playable video game demo. The working title for this project will be “Remote PI” or “R-PI” for short. Not to be confused with “RPi” (Raspberry Pi).

This project will require creating a proof of concept video game demo as a solo developer. By ‘proof of concept’, I mean a vertical slice of gameplay that will feature all the core gameplay mechanics layered atop each other in a cogent manner to form a functional and hopefully compelling system. The demo will also require thematic art and music, as well as featuring a narrative hook designed to entice players to support the production of the full game.

Essentially I plan on documenting the creation of a playable teaser trailer here. In addition to writing about the development of the demo itself, I will also document my personal relevant skill progression. Since this project will require me to become practiced at all the disciplines that are needed, for realising an interactive multimedia product like a game; I will need to acquire passable skill in art, music, as well as brush up on my general programming fundamentals. During this process I will no doubt have to also learn a few new tools (IDEs, programming languages, etcetera); and that’s not even to mention the more mundane skill-sets like script writing, project organisation, and time management.

This series of post entries will journal my progress in this endeavour.

My current skill-set (or lack thereof)

Before we go on I think it’s best that I identify to you where I am currently with regards to my skill-set. This is in order to understand what I need to work on to realise this vision. At the time of writing this (2021), I have been a hobbyist programmer for a few years now (since 2013-14 I believe). Being a hobbyist I have pursued programming for pleasure primarily.

This however meant that I was largely unguided and unfocused with regards to what I learned and how. This resulted in the collection a more shallow and eclectic experience base, rather than a more guided and structured one (i.e. comprehensive and useful), like the kinds associated with formal education. More aptly it also dictated how long I stuck with things after the initial fun dries up and the laborious hard-work begins. But that’s a more personal failing of mine. I can’t blame the books that I bought, for me not reading them. I mean most of them had pictures and everything.

Anyway, I started with making short text adventures in an IDE called Bloodshed Dev-C++ using the C++ language. On a technical inspection: these games could be boiled down to basically a series of if/else statements, with their function calls nested within another series of if/else statements. If I got fancy, I might even throw in a switch statement here or there. The only one I remember completing and being proud of was called “A little after midnight”.

It’s most notable feature was that it had a rudimentary inventory system that simply fed into the cascade of if/else statements that constituted that game. I vaguely remember codifying the handful of items in the game as individual boolean variables. Example use-case: “if (isGotKey == true) open_door(); else locked_door_dialogue();”, or something to that effect. Like I said it was primitive.

At the time: I remember just wanting to create a game, any game, and have it work. I liked “choose your own adventure” books like “Island of the lizard king” by Ian Livingstone, and the various MSDOS text adventures that I played as a child, all who’s names unfortunately escape me right now; and simply wanted to have a go.

After wetting my feet with text adventures, I transitioned to making flash games using the ECMAscript derivative language Action Script 3. This was on the FlashDevelop IDE. In this time of approximately 3 years I only managed to complete two games. Keyword: ‘complete’. A basic 20 level platformer with godawful hit-detection called “Runaway Units”, and a single room point-and-click adventure called “Last Life: The Blue Key”. In both games I was helped by my friend Kross Drayllih who created the music to Runaway Units and did the majority of the art and all the music for Last Life. However, I did the artwork for the user interface for that game. This will be relevant when I discuss the pixel art of this demo later.

Around this time I started dabbling with modding games. I created a few JSON mods for a community driven game called Cataclysm: Dark Days Ahead. Notables include: a mod that gives early game access to mutagens via (IIRC) an XCOM-esque gene-therapy clinic building, and a more general extra buildings mod called “OA’s additional buildings”. The later of the two mods even got folded into the main game. If you ever find a sex shop, internet cafe, walled park, cruise ship, or ranger’s lookout: well, that might be my work you’re exploring. In addition to CDDA I also created a few simple ship mods for a space logistics game called Endless Space.

After this I fell out of love with making games, and moved onto playing with mini-PCs and microcontrollers. Namely, Raspberry Pis and (clone) Arduino boards. I wanted to make robots. With these I was introduced to Linux based operating systems, specifically Rasbian. Which I accessed remotely over WIFI (via secure shell protocol) using a program named Putty on my Windows 7 machine.

I remember using bash as a remotely accessible text user interface to run custom bash scripts and programs written in Python 2. These programs were for controlling the RPi’s GPIO (general purpose input output) pins. Which in turn controlled peripheral components like sensors, lights, relays, and motors. These programs were very utilitarian in nature and simple, as they were merely concerned with converting button presses into signal outputs, or interpreting signal inputs from the sensory peripherals and converting them into a textual output for the console. The RPI’s GPIO library was the one who really did the heavy lifting there. Similar story with the Arduino IDE. My instruction sets where pretty basic there too.

As you probably have put together, I am just a hobbyist programmer. I’ve read a few books, did a few online courses, and played around with a few tools; including everything from complete development environments like the Unity engine, to simple graphics libraries like SMFL, SDL, and Allegro. But never to a serious extent. I also have more general knowledge about programming. For example: programming paradigms like functional programming, versus procedural programming, versus object orientated programming. But since all of my projects have either been small enough that I didn’t really need to research proper code organisation for creating a maintainable codebase, or that the project was so large that it has been abandoned for other reasons before necessitating an ordered big-picture view approach to coding.

As I am now, I am even rusty at the basic programming level I once had. This is due to my interests moving on once again. I’m not sure when exactly it happened, but as I started working and acquiring money: my interests gradually drifted towards the hardware side. As I am now I am more versed in repairing devices like power-supplies and old games consoles, than I am programming using a graphics library like SDL2 (Simple Direct-media Layer), in order to do something simple like create a window and render an image onto it.

You might have also sussed out from it’s absence of mention in the above summary, that I am not an artist. Although I have dabbled with some watercolours during my poetry writing teenage phase. I even had a Deviant-art account (“night-eater”) that I used to host the handful of halfway decent things that I did managed to create at the time. But it didn’t stick. As for music, as I am writing this I don’t even understand basic music theory. For example what the notes mean: like A# or B flat. No idea. It’s embarrassing to write this down but it is also the truth.

And that’s my starting point here. A rusty ass second-rate programmer, who can barely art, and can’t music. Still though I think that this project is within my projected ability to complete. It’s like that chess adage: “the only way to get better, is by playing a better opponent”. The same I think it is with creating and refining a skill-set. It needs a specific objective or challenge to be measured against. Otherwise its easy to just end up drifting around aimlessly without ever feeling the need to work hard and develop the skills that have been acquired, at least not to a point where they can bare tangible fruit.

I know I said otherwise in the preamble above, however I do think that the scope of this project is actually relatively small (compared to what it could be). It’s just a short demo; and whose music and art only need to be functional, they don’t need to be masterpieces. Still, lets not risk falling for the Dunning-Kruger effect and underestimating the energy and time taken to develop the relevant skills. That’s a lesson I learned the hard way when making LL:TBK, where everything took three times as long to get done as initially predicted. All in all though, I do think this is doable for me.

Game Outline

Without any further ado lets outline the game that this demo will come from. Please note I will go into much further detail on the game’s mechanical substance during it’s dedicated article. This is just the declaration of the initial parameters that I wish to work within.

Game Specifications:

Working title: “Remote PI”
Genre (mechanics): (primary) point-and-click adventure, (secondary) hacking simulator
Additional mechanics: puzzle mini-games, rouge-like (permadeath and multi-run unlocks), survival (resource management)
Genre (narrative): detective thriller
Art style: medium-low resolution pixel art
Music: low key techno synths (i.e “electronic music”), or something closer to chip-tunes
Playtime (demo version): approximately 15-30 minutes
Playtime (full version): around 1 hour per complete run
Technology (for game): C++ and SDL2 using Code::Blocks IDE
Technology (for demo): HTML, CSS, JS, and a simple text editor like Xed
Target platform (game): personal computer (Windows, Linux, Mac)
Target platform (demo): web browsers (specifically my website)

Synopsis:

Remote PI is a game in which you play as a private investigator working in a particularly seedy part of (an alternate history) London in 1999. It will have a gig type gameplay loop where the player is offered several cases via email. These discrete cases are then shown to contain an over arching narrative. One that escalates the stakes by tying the the jobs to a central story about national security.

Thoughts on game ideas

You may be wondering why I am just listing out my game’s premise here for something that one day I’d very much like to turn into a real commercial product and sell? Why I am revealing how this sausage is going to be made, secret family recipe in all? Well its because I don’t value ideas (and thus “idea guys”) very highly. They’re not something to be jealously guarded like a dragon on a pile of gold (at least not at this level). I mean I’d be willing to bet that you reading this could probably come up with a better idea for a video game. For example: Pacman but sexy. Boom! Million dollar idea right there. You just thought up Ms Pacman. Genius.

The idea of a detective noir, point-and-click/hacking-sim thriller that is set in late 90’s London is not unique or special. It’s just a disparate amalgamation of various things I like (and am familiar with) that I think will work well together. It’s the execution of the plan that dictates whether or not this product will be worth anyone’s time. Not the premise and promise provided by a “good idea”.

Thoughts on developer teams

You may have been wondering why I don’t team up with other people for these types of larger projects? I mean many hands make light work, after all. Well, in my opinion its more often than not the opposite case of too many chefs spoiling the broth.

This is especially true in cases such as where a group of friends decide to work together. Typically having vague workload expectations, job roles, schedules, and naturally differing creative visions for the final product. In such situations, I expect people to essentially waste their time and energy before the inevitable fruitless dissolution of the project. Also likely with some hurt feelings incurred in the process.

To give you a more personal and direct answer: I simply don’t like working with others on creative endeavours like video games. Especially in smaller more intimate teams, where each individual has significant influence when it comes to whether or not the project is ever actually completed. The idea of expending myself: pouring serious time and energy into a project, only for it to still fail to finish due to someone else, either not pulling their weight or spitefully sabotaging it for some interpersonal gripe — actually genuinely frightens me. This is because It’d leave me in a situation where I can’t get that time back, and I’d also have nothing to show for it.

In the case of shared revenue projects (i.e. a project where money only comes in after it is completed, if at all): people tend to start behaving oddly as the project progresses and the initial new project enthusiasm drops off. I find it is at this time that people begin to gripe about things like: creative control, division of labour, maintaining personal morale, as well as time keeping, and deadlines.

Oh and lets not forget people’s general trouble with listening to basic instructions and specifications. And quite frankly when I have worked with “creative types”, I find that I quickly can become frustrated with the development process, and risk factors associated with co-ordinating various people who say that they are invested in the completion of the project, but whose actions say otherwise. I find co-ordinating with these types of people to be a generally draining experience, closer to an exercise in herding cats than co-ordinating with professionals.

This feeling is exacerbated when these people then choose to organise themselves into flat leader-less structures. I believe this is due to the incorrect assumption that such a small group will not need a leader to organise and co-ordinate the membership, especially when they can all join the same chat group and co-ordinate that way. Like a group of friends might do for example. This type of headless group structure is generally bad unless everyone in the group genuinely holds themselves responsible for making their contributions on time and on par. Even with the absence of the downward pressure and authoritative structure a clear leader would offer.

For example: I have had experiences with creative partners who would only work on things as they feel like it. On one hand I understand creative desire and that sometimes it can dry up. However when working to deadlines it really can become frustrating, especially when they hold up the supply lines by making others wait on them for materials. And since no-one is currently paying them for their contributions, they don’t take their responsibility to the group seriously and prioritise it within the routine of their lives appropriately.

I once had a partner who decided to create a superfluous website and start writing a script for a sequel to the title we were working on at the time. This was at a time when the actual current title was about halfway done, and I was waiting on them for materials. That’s got on my nerves, and the worst part is that I had to find the nicest way to ask the person to go back to making what we actually need; rather than what the person felt like doing. I was also acutely aware of the real chance that my criticism my disenfranchise the person into quitting all together, if I happen to upset them. In which case that project is dead in the water. That tiptoeing around people’s feelings is honestly exhausting.

I could gas on about this, but it ultimately comes down to me not wanting to work with others for this type of thing. Things just have a habit of getting complicated when working on creative (and potentially commercial) endeavours with others. Who owns what and how much is also a headache of a conversation (argument) to have, especially when the group can end up fighting over scraps or (fantastical) projected earnings.

That’s as far my experience with shared revenue type deals go. I have looked at alternatives such as hiring artists and musicians. However I don’t really want to work with freelancers I meet online. I may for discrete commissions of work, such as for character profile pictures or wallpapers for a game. However I don’t really want to get into in more extended business relationship with freelances if I can avoid it. As I fear being nickel-and-dimed for every alteration or modification I may request.

I can’t say I’d blame them for having a mercenary attitude in this case either. They make their money during the development process, and strictly in exchange for their work. It’s not like I’d be willing to share revenue or copyrights of the finished game after-all. So the only way they make money is by charging for everything that they do; including time working on alterations.

Additionally, I am not in position in my life right now where I can invest the time necessary to source and vet good contractors; research contract and copyright law to the point of competency, as I want to legally own the commissioned work; and finally (and most importantly) cough of the dough to pay for all this. So its all academic at the end of the day.

Closing thoughts

As I write this I ask myself: What is the purpose of this blog? Given a moment to think – I believe it’s main purpose is as a public declaration of intent. (Not that there’s anyone actually reading this mind you.) I have had many similar projects in the past, one’s that I have quietly started, worked on for a couple of months, then just as quietly abandoned them. I always justified the abandonment with one reason or another. I am sure that at the time, they were good reasons and not just excuses. However I can not deny a certain emergent pattern of behaviour of mine: I have started many projects but only really have ever completed a small handful. And all the effort that went into those unfinished works is largely lost, not having paid me back any sort of tangible dividends.

The only exception is probably some skill building experience acquired whilst creating and prototyping new systems and mechanics. I have many unfinished games that have their core mechanics articulated to satisfaction but not fleshed out with actual game content materials. Like a functioning inventory system filled with placeholder articles, and having all it’s item population and depopulation event calls coming from one central controller function. So that I could test and trigger the events at will. (Needless to say: this event controller function is to be removed once the system is placed into an actual game, and has all it’s event calls tied to in-game trigger events.)

Additionally, I have created systems like dialogue trees, local saving and loading, and 2D weather effects. Experience modelling these mechanics does in my opinion carry over. Even when tools like engines and languages change, understanding the fundamental principals of how something like saving a game state to file works, and actually having an instance of implementing it, is valuable in my opinion. Although nothing beats the grim satisfaction of actually finishing a fucking project.

Anyhow, here’s to this thing. *downs an alcoholic beverage* burp… cheers.

Thanks for letting me ramble.