The post of shame

It's been a long time since my last blog post and I have next to nothing to show for it. I know, it's bad. A combination of the problems I've been talking about for a while now with stuff happening in my life outside of this project deflated my motivation to get anything done. Deflated, but not destroyed.

I still have a personal commitment to completing this game, come hell or high water, even if it takes another 3 years. But I need to revaluate some things now, considering as everything stands now nothing is getting done. I need to make some changes. As far as I see it there is one main major issue stopping me, and a bunch of side issues that might be contributing to the main problem. Some of these peripheral problems include:

• The dialogue system I have is still clunky and frustrating to work with
• Unity is slow and complex to work with (compared to what I am used to)
• There is no concrete roadmap or gameplay design

The main problem? Motivation. I need to be able to spend hours working on things without it feeling like a waste of time or a chore. I achieved this early on because of that great rush you get towards the start of a project where every minute you spend on it gives immediate and multiplicative dividends.

I could spend hours drawing character portraits because each one was self-contained and fun to do, but spending hours researching dialogue systems or debugging UI code is Not Fun and doesn't give an immediate satisfying feeling of productivity. Couple this with the chore that is starting up Unity (downloading updates, launching the program, compiling for debug, etc.) and it becomes more and more difficult to find the motivation turn the abstract desire to "make game" into the practical steps that have to be done. It's frustrating to be in this slump because the desire to work on this project is still there, and has been there the last few months, but all it's resulted in has been extended note taking and some half-hearted research.

Some of this has been useful, but not in a tangible way. I'll go over my general thoughts though, as they relate to my ideas for ways to change up what I'm working with to start making progress again.

Firstly, I've been doing a bunch of thinking about the gameplay mechanics of the "game". My goal and focus has always been on the meta narrative that the player will experience. Their experience with the world, the way they will be presented information and what sort of impact I want to have on them. The gameplay aspect of my game was always secondary to that, but since the very beginning this attitude has proven to be a thorn in my side. Without an actual plan for the gameplay it has become impossible to plan things such as the map layout, or even the way the UI should work. If I went with one of my earlier designs for a sort of survival gameplay element for example, I would want to re-design vast areas of the map, and change a lot of NPC dialogue to refer to this part of the game. I don't think I'm going to go that route, however.

I wanted to avoid from the very beginning standard RPG mechanics, because they have no relevance to my actual goal (the meta narrative), and would instead just be a pointless distraction. I held off for the longest time putting some sort of gameplay mechanic in to replace them in the hopes I would come up with a big brain play, that I would find some sort of perfect solution that would create fun and engaging gameplay while also bolstering my meta narrative. Alas, it is probably time to admit I failed. I don't have the experience or insight or sheer genius to solve that issue for this project, and I may have to just cash in and choose something established I know will work. While it pains me to think it, if I can't come up with something else quickly I may resort to just slapping on a generic RPG combat system with robots you can whack.

This ties in to the second problem that I have been thinking about, which is just a specific case of the first. I have wanted from the beginning for the player to walk on foot between the two faction's bases, the Ecological Arcadian's areas, and the industrial Utopian area. The meta narrative idea behind this is to make sure the player experiences the impact these two worldviews have on the environment, so they can draw their own conclusions later. From an even further meta point, this gradual movement between areas is specifically designed to be a cognitive break for the player, and a gradual refocusing of their mind as they transition between the two extremes, reminding them of the policies of the factions they are leaving behind or moving towards. Great, that all sounds good. It's just that slowly walking between two areas is Not Fun. Now there are ways it can be made engaging if not fun, using techniques from cinema or walking simulator games, but the thing is I'm not convinced I can pull those off. Exceptional sound design, a varied and evolving landscape, or a monologue reflecting on past experiences are all things I would love to be able to try, but they would take me months and months of work and might be dead ends. I had the idea of instead allowing fast travel between the areas (avoiding the need to make the journey engaging) but with a quick camera pan instead of the standard cut/fade/loading screen, so that the distance and contrast is still seen and felt by the player.

The other idea to make travelling engaging that ties in to the gameplay issues I mentioned above would be to include puzzles. Mazes or basic movement puzzles like seen in Pokémon or other RPGs could be mildly interesting, but again the idea pains me because it has nothing to do with my meta narrative.

Speaking of, the third major issue I have been thinking of is how to make the player actually want to go between the two areas in the first place. My most up to date version of my main storyline has the player wandering until they find either the Arcadians or the Utopians and then learning about them by talking to NPCs. The end goal of the player is the vague "find somewhere to belong", with the plan being they will join one of the two sides. But what incentive is there for them to visit both and learn about both sides? A player might just beeline right for one of the factions and join it without thinking, instantly ending the game. Is that an issue? Maybe it will encourage replayability? Maybe joining a faction requires a long questline that eventually forces them to "check out" the other faction?

One earlier idea I keep thinking about was a concept of the player being a messenger between the two factions. It is their job to relay diplomatic messages between them. The player then has a reason to travel, a reason to learn about the faction's beliefs and stances on each other, and a means to impact the world (by choosing what information to withhold/edit/present at each meeting) - or remain passive (just presenting everything truthfully). I think I might return to this idea, and perhaps try to combine it with the "join one side" idea as well. The player starts by visiting one of the factions and then is tasked by that side to be their neutral representative to the other before they are allowed to join. In doing so they are shown both sides and both sides attempt to recruit them. The main problem with this idea is that it will require even more writing from me. Very complex writing with many complex branches. Still, it's the best I have at the moment and I might just have a crack at it.

Finally, too, I should elaborate on my issues with the dialogue system. I did get Fluid Dialogue to work ok for me, and it's mostly alright, but it's just not that much easier than my own code. I bought a licence to Unity Dialogue System, which is a professional tool (on sale!) and have been reading through some docs. It does everything, perfectly, but I can't help but feel apprehension at the learning curve and the size of the project. I worry that in the end my little 2D pixelart game may be a GB in size just because of Unity asset bloat and I have no idea how to deal with that. The feature that got me on board was the import function that can take text formats such as Twine2. I watched a video by Josh Sawyer on dialogue systems in RPG games where he talks about how much easier it is these days to develop dialogue due to tools such as Twine, and I'm curious to see if it can help me. I'm especially interested in the idea of writing dialogue quickly in Twine and seeing the result online instantly, without having to run it through Unity, and then being able to import it later. It would be a dream come true to be able to debug and test the dialogue live on a website externally to Unity.

That's all for now, hopefully the next post will be a lot more optimistic ;_;











p.s



Here's something else I've been working on on my weekends unrelated to this project: http://squidempire.com/iso/



It's an extension/rework of my Three.js FPS engine into an isometric RTS/city builder engine with the idea of making a city builder style game where you go into some horrible polluted wasteland and have to rehabilitate it!

My concept art

The idea sort of came from my enjoyment of C&C Tiberian Sun. I used to always think about the idea of "red zones" in that game, and how people would react to that sort of thing happening. I think if we could, we'd do our best to clean them up. So this is sort of a post-post apocalyptic game.

Current in-game screenshot

The engine has been cool to write so far, and I've learned a lot! I even messed around with shaders (the water in the above screenshot), which had instant payoff when my job required some shader work.

It's been a fun side project but it's hard to say how much more I plan to work on it. I'd need to start making custom models soon and doing performance passes, which are two things I'm not really enthused about.

Convo update

It's been a very slow month for the project. I've had a lot of other things I've had to deal with, and my motivation has been pretty low. However, the one big thing I did was deal with the conversation question form the last blog post. I ended up going with fluid dialogue. It was a bit of work to rip out my custom dialogue system and replace it with fluid, but I have to say it's nice to not have to worry about it anymore. Fluid does pretty much everything I need and is much easier to edit than my original code method, though it's still not perfect. I will have to make some modifications and extensions myself to fluid locally which is a bit annoying, but there's no way around it. The main thing I need is a way to hook into conversation choices and run arbitrary functions afterwards. I need this right now actually, for the demo. After speaking to a character and exiting the conversation by a certain path I need that character to move somewhere. It shouldn't be too hard, after all, fluid has some docs on customising the system, but my progress has been very slow due to my current lack of motivation.

What's been killing my motivation is the lack of easy and clear steps to take now. I know sort of what needs to be done, but I haven't managed to build a clear path in my mind of how to get there and what to do along the way. This is bad for the conversations especially because writing huge amounts of dialogue on the fly is hard for me and mistakes are complicated to fix. Using fluid's dialogue editor, I can't find/replace all instances of a word if I change a character's name or something later on, as an example. I think I need to find some way to write my dialogues down outside of my game so I can run through them, see how they all interact, and make changes on the fly quickly without having to hard code them clunkily into Unity.

I might have to do some research into how other RPG style games go about their writing. I'm sure this has been done many times by many teams who have had the exact same problems I'm having.

Anyway, hopefully soon I'll have something to show. If I get totally stuck on the conversation stuff again, I might switch to doing spritework or something for a bit to make some progress.

The horrors of writing my own conversation system (continued)

So, the elephant in the room is that after more than a year my conversation system still SUCKS. I tried writing a real conversation in my system for the first time in my system as part of the work I have been doing to get my demo running and I nearly went insane. That's a joke obviously, but it wasn't very fun and debugging my mistakes I made in my own system built FOR ME by ME took me hours. I realised pretty fast that it was going to be untenable to just write the conversations directly into the code with my current system like I had sort of assumed I would. Normally, I'm pretty good at ploughing through difficult and tedious work like this, but the time I would have to spend debugging obscure mistakes would quickly burn me out, I can see it. Thing is, of course, I sort of knew this would happen. I wrote about foreseeing this exact issue in an earlier blog when I gleefully talked about how my convo system was all done and working great. It's doubly frustrating because it is very close to working perfectly. The main thing is just that it's unworkable to write the conversations directly into the code. The code becomes too complex and confusing too fast, and it's far too easy to lose track of what I'm even doing. Here's a screenshot of a single response for a conversation fragment for the Demo NPC I was building: 

ahhhhhhhhhhhhhhhhhhhh

It could certainly be worse, but dealing with magic numbers ("priority") in the constructor just isn't great. This drove me to look into libraries that already handle conversations. I have generally avoided libraries for things I thought I could do myself, because I'm doing this to learn after all. Plus, as a programmer working solo, I find it more motivating and consequently faster to work on my own code that I control and understand than spending time learning someone else's code. Lord knows I do plenty of that at work. What makes it fun as a programmer is being able to do things my way, and that's a big part of why this is a fun hobby. But at some point, I guess it's better to let someone else handle the pain. So, I did a search for convo systems for Unity that I could hopefully drop in and replace mine with. There's a bunch of paid ones - but I can't really justify to myself dropping $100 on an overengineered perfect system I would barely use 5% of the features of and have to spend weeks learning - and some cool free ones. I tried out a cool free one called Fluid Dialogue which looked super promising. The system seems very compatible with my own, and had a cool active community and slick in-unity tree/graph convo editor. 

 

The convo system in use (Demo)

But as I started to use it, I came across a fundamental issue. Most convo systems (fluid included) use a sort of "flow" paradigm, where the conversation is mapped like a graph or tree and answering 1 to dialogue A sends you to dialogue B. From the start however, I built my system state based instead, where answering 1 to dialogue A sets a flag that makes the convo manager choose B as the next most relevant conversation to show. This system means my conversations can flow in any direction at any time, and allows me to be extremely complicated with my conversation choice conditions and effects in ways that I plan to use, but also makes it difficult to adapt to the flow based approach. I got halfway through adapting my demo script I had written into the Fluid Dialogue system before I realised that this was a fundamental issue and couldn't be solved with a simple band aid. So sadly, once again I am forced to reconsider fundamental issues with my conversation system as planned. Going forward I think I have 5 options (in decreasing levels of upfront effort):

1. Build a visual editor or tool for my existing conversation system inside Unity to allow me to work with my existing conversation system more easily
2. Adapt Fluid Dialogue to work with my system - I assume this means big rewrites of that code
3. Abandon the state-based conversation plan and go to a flow-based approach instead, using Fluid Dialogue - including a restructure and total rewrite of my planned gameplay and conversations
4. Carefully write all my conversations/state down in some gigantic document and test the state flow externally somehow, and then simply copy/paste it into my game system
5. Suck it up and slog through writing all the convos ad hoc in my code

There are more options of course. I came across a markdown-like system called Ink that has Unity integration, but again like most systems and libraries it uses a flow-based format. In the end, it's really going to have to be a choice between rebuilding my system to be flow based, or making it easier for me to write my state based conversations. I'm just not really sure what to do. I've made some inquiries with the Fluid Dialogue community to see what they think, but otherwise I'm going to have to just sleep on it a bit. I'm feeling a little bit like I'm leaning towards either writing a tool for my system or writing all my dialogue externally first (perhaps both?) at the moment. The idea of using my own system has a powerful draw for the reasons I mentioned before, even if it's a siren song...

It's been fun at least to start building interiors out. Note the new chromatic aberration and noise post-processing effects!

It's a shame I know so little about what I'm doing. But this feels like the way I learn. It would be better if I knew someone who knew what they were doing and could get some advice, but without that this seems like the right thing to do (i.e., flounder in the dark). I looked briefly into how Bethesda's convo system worked in their Creation engine through Fallout3/NV's GECK (their system being a big inspiration behind mine) and wasn't surprised to see a monolithic and dense custom interface system masking a hacked upon flow-based system. Reading about NV's development and their recording voice lines basically from day 1 until the development finalised indicated to me that they must have planned out all their dialogue before programming it into the game. I wonder if they did that through some tool that later converted the raw text into game data, or whether they just wrote it all down in gigantic text files and later copied it into the game line by line. This is baseless speculation on my behalf of course, but it gives me hope that if I was careful enough I might be able to just write my entire game's script down in a file and then later copy it into the game line by line... Or that could be a madness inducing dead end. Like I said, I'll have to sleep on it.

Here's a lighthouse sprite I did a little while back

Also I don't want to say too much but the band whose music I was hoping to get to use in the game is interested! They're interested in seeing the demo first before they commit, so that's another reason for me to get it done asap.

2021 post 2!

Unfortunately, I don't have much to show in the way of progress this time. I made some small progress on the map design and some spritework (including a lighthouse), but for the last month and a bit my attention was focused on some major events outside of this project. Mainly, I started a new job - as a game developer! Hooray! This project played no small part in landing me that job, not just as evidence I am competent and committed, but also in what it taught me so I could be confident when applying. It's a big change in my career and life and I've had to focus pretty hard on organising my time and energy for now, so my side projects have been on hold.

I also spent about a week and a half looking deeply into converting my simple JavaScript 3D FPS engine to handle multiplayer. Nobody else has done it yet from what I've seen online - at least not perfectly - and the pieces required to make it work are just falling into place at the moment. Three.Js for the engine, web RTC (with customised binary data instead of json) for the client/server communication, frame saving and distribution serverside... it's all possible and very close to reality. With only a small team and using existing libraries it wouldn't take more than a few weeks to have a full 3D 60fps action FPS multiplayer game that runs entirely in a browser! I tried it myself but due to my new job I just didn't have the time or energy to get it working before I lost interest, but I'm certain it will be done soon.

To work out what steps I would have had to take to get my dream of my FPS game converted to multiplayer taught me heaps about multiplayer game architecture. I'm glad I looked into it even if I didn't end up making the game, because it taught me a lot.

I have some other ideas for things to write about in regards to Ecodustrial but I think I'll hold off until the next blog post, when I have some more progress to show.

Exciting times!

2021 blog 1

Here is the first blog post of the year! It's been quite a while since the last one. I meant to post an update about 2 weeks ago at the start of the holidays to put down what I'd managed to get done right before my end of year holidays started. I put it off then because I kept thinking "I'll just do a little bit more before posting..." at first, and then it became a bit daunting to write down everything I'd done - which by now is a lot.

The elephant in the room is that I didn't get the end of year demo done. Boo! Well, the good thing about having no investors or even interest in my project is that no one can be disappointed by this news. So, this blog post will cover two topics: what I've got done, and why the demo isn't ready yet.

Firstly: what have I done?

The two biggest achievements I have to report are the completion of the "ruins" spritesheet, and the main "blocking" out of the game overworld. Here's a look at the spritesheet:

The "ruins" spritesheet for the unincorporated areas

Man, that took a while to make! You'll notice right away that the sprites are sort of jumbled around and broken up. I had to squeeze every cell out of this spritesheet so I did a lot more culling of redundant textures than I usually do to try to make sure every cell was being used. 

Overall, I'm really happy with this spritesheet. I think I've improved a lot over this project so far, and some of my favourite spritework ever is on this sheet. The car and tarp-covered roof stand out to me as some of my best ever!

A car (based on a Morris Minor) before and after being abandoned

Once I'd finished the spritesheet for the ruins area I set about building out the ruins area in the game world. My plan was to build the area only to the extent that would be explorable in the demo/game intro. Then, I would focus on the cutscenes and game logic for the demo/game intro and have the demo done by now... However, what happened was that as I started building out the intro area, I realised that I couldn't build up the exits without building the areas they exited into - and then, I couldn't build those areas without also being the areas they lead to. Otherwise, how would I know whether the map size/pacing/layout was correct for the areas I'd already made? So it pretty quickly turned into the job of "let's lay down the entire game map".

The demo area I build first

A higher-level view showing the surrounding areas being built out

It's hard to get a grip of the game pacing while doing this. I can walk around in game and see how long it takes, but without the audio, objectives, or finished art it's hard to really "feel" whether a distance is too short or long. The player shouldn't get bored of walking around and they shouldn't get hopelessly lost, but at the same time exploration and taking in the environment is a part of my game's world and even its story. I brought the Arcadians much closer to the starting area and moved them away again twice while debating this issue, before finally just accepting that I won't get it right the first time, and I'm going to have to tweak it later anyway.

Here's a couple of miscellaneous images showing some of the environmental art in further detail

A nice beach under construction (minus the water!)

A mockup of a ruined ruined area I did while testing sprite contrast/colour

One issue I've come across while testing the placement of my sprites is that is can be very hard for the player to know where they can and can't walk. Sometimes a wall or object blocks you when you feel it shouldn't, or you can't walk somewhere you feel you should be able to. I'm not 100% on how to fix this yet. I'm not even sure if it's just an issue with certain sprites that I need to fix on a case-by-case or whether it's a fundamental issue with the way I've designed my presentation. My plan for this is to research into other games using my 2.5D art style and see how they work. I'll report back if I learn anything important from this.

Finally, I did some additional art for the game's intro (and the demo). At the start of the game the player will go through a brief "flashback" montage, giving them some context and showing them the mechanics of the game. This flashback sequence will involve two separate segments where the player controls the main character as a young child and then as a teenager as time skips forward. The final segment has the player as an adult as the game begins. To handle these timeskips, I needed to make art that could be "aged"; hence, the rusted out car and broken buildings. In addition, I needed some new NPC art for the new characters, and their aged versions.

A character portrait with three stages of aging

A character portrait with two stages of aging

Various aged sprites for the above characters

Of course, when presenting the same character with years between it doesn't make a huge amount of sense to show them wearing the exact same clothes and in the exact same pose. Obviously though, it's more important that the player understands what's happening instantly. 

So as for what's next now?
I'm going to be continuing to work on the main map while performing some side research into my sprite/movement difficulties. I'll also still be mainly working towards the demo. While I don't feel pressured to have it done "asap", I still want to make sure it's done soon.

Also hopefully it's not a bad omen but this blog ended up taking me three days to write (normally I write them in one sitting over like an hour) and it's not to the same standards as my earliest posts. Only time will tell....

Gearing up for the end of year demo

 I made a promise to myself earlier this year that I would have a demo of this game ready by the end of the year, and by gum I will do it! It's not going to be as easy as I had imagined, but I'm well on my way. I have a plan too, which I will get into in a bit, but first; the state of things since the last post!

Water

There were a few large "unknown unknowns" with this project that I knew I would have to tackle going in. These sorts of problems are the hardest to work on. It can be hard to solve a tightly constrained and defined problem, it is always harder to solve a more open and nebulous problem, and it is downright difficult to solve a problem when you don't even know what the constraints are. I have just now checked off one of these unknown unknowns' issues. This is a huge boon to the project and my own experience and skills going forward. Very exciting! The problem? What to do about water.

So far in my game all the visual element have been hand drawn pixelart sprites. I know how to do these after years of experience. I know what I can achieve, and I can visualise what the end result will probably look like before I start. I knew right from the start that I would have water in my game and for just as long I had a very good understanding of what the water would look like if I hand drew it. Here's an example:

I drew one of these myself, the others are examples from various games

I know I could produce water to around this quality level. But I also knew I wouldn't be able to animate it if I did, and that was the problem. I really wanted animated water so I could have gently flowing streams or quietly lapping waves on a shore. The unknown unknown was shaders. My experience with shaders had up until I started this project been entirely through webgl, for some silly text effects on my website. I didn't (and still don't) know very much about them, but I had the understanding that they were what made water look like water in video games. I felt that there must have been many people before me who had used shaders for water in a 2D game in Unity, so I did some googling. From there I read a bunch of tutorials and downloaded a few open source demos. 

And then basically, I just mucked around with these preset demos until I got something I liked. I find that the best way I learn something huge at the start is to do this. Download something already working and tinker with it. I changed variables around, looked deeper into the functions used, and tweaked the existing functions watching the effect this had on my scene live - Unity's ability to hotload is very impressive. Here's a quick montage of images showing my progress:

My initial "mirror" shader

Mirror with some colour

Redid the mirror with a system where only certain objects are reflected

My attempt 1 at a falloff as the water got "deeper"

A much better falloff!

New tiles to transition between water and land a bit more smoothly

I'm very happy with the results so far! I have solved a huge issue that had been plaguing me for some time. Well, "solved". Every solution comes with a slew of new problems and questions of course. At the moment here are the remaining things to investigate and solve with the water:

• How can I do waves and water sparkles/glints? Can I hand draw these or can they only be done through the shader?
• How can I do ripples when characters walk through the water?
• Only sprites can be reflected (not tilemaps). Do I need to replicate certain tiles as sprites? How does Unity's workflow work with sprites instead of tiles?

But! It is still a big achievement, and I'm happy to let the water settle (so to speak) for now, before I tackle the above issues. And what about the other main "unknown unknown" issues left to investigate? Well that leads on pretty well to my next main topic for this post...

The End of Year Demo

The end of year demo will consist of the opening of the game, the opening background interactive cutscenes up until the game proper begins. The player will wander around their home village through a few time skips as they watch their neighbours die or leave as the Union and the Arcadians creep closer and closer. 

As mentioned at the start, the demo is still looking good. There are basically three big technical things left to solve, some art to do, and then a bunch of content writing. Two of the technical things are unknown unknowns, which is a little worrying, but I'm fairly confident I will find solutions quickly:

1. Program UI -> A start menu, pause, save / load menu
2. Cutscene control / scripting
3. Save / load functionality

I know nothing about the UI, but it's the one I'm least worried about. I am 100% confident there will be endless tutorials and resources for UI construction in Unity, so I expect that it take me only a day or two to get something simple working.

The cutscene control and scripting is something I feel will be totally custom to my project. I have the instinct that Unity will not provide anything for this, and it will be totally custom, which means I at least don't have to worry about doing much research or messing around in menus and so on. It will probably just be a few custom C# scripts and shouldn't take more than a few days, though if it gets finicky I could see it taking longer.

The real scary task is the save and load functionality. I felt early on I should have focused on this and tried to have it working from the start, but alas, I never did. I did at least keep the idea that I would be serialising my game in mind as I wrote my data structures. I have a big singleton "state" class that contains just about everything I would ever need to save, so theoretically I will just have to serialise that class to json or xml or some Unity supported format and then handle reloading it in again later. But at the same time, save/load reeks of something there would be a Unity™ way of doing. I am sure there are countless tutorials and resources on this as well so I will do some research, but I am at this point at least leaning towards rolling my own system. Anything could happen once I start on this problem though, so I'm a little worried about it. I can't estimate how long it will take...

After that, I just have to do all the art assets for the intros (a few new characters, buildings in various states of decay, and clutter assets), and the writing. The assets will take the bulk of the time from now until the demo is ready. It takes me about a day to do a set of maybe 5 sprites, and I expect I'll need upwards of 40. The writing shouldn't be too hard, I can write these blogs for example in about an hour. However, it will be my first time using my dialog programming system for real and that will be a stress test. I mean literally, I'll find out if it's too stressful to use and whether I should switch to a different way of handling the dialogue. 

Other progress

I finished more of the various Arcadian homestead buildings:

The Temple homestead building

The Lahtinen sauna building

I also started the "ruined" architecture for the unincorporated areas - i.e. the intro area for the demo

Beautiful brown brick blocks. Might make the windows smaller

And the final piece of news I have is that I have made contact with one of the bands I have been pursuing about licensing their music for this game and we've started talking. Very exciting! 

Until next blog,

Me

After the holidays

I took a holiday a few weeks ago and before that spent a week making Tetris in C++. Okay, that was an excuse. This post is a bit late, but I kept putting it off until I had something worthwhile to show. Before I got into what I actually got done since last blog I want to just write a bit about my experience making Tetris. 

Tetris 2

The image above is what I made, from scratch, in C++, in about 6 days. It's always fun for me to work in a language with strict type rules after working at my day to day in the anarchy of PHP and JavaScript. Working in a compiled language is tough in some ways, but I find it really neat having the peace of mind knowing that what compiles is "correct". Once I finally managed to iron out all the nasty bugs and compile errors I wrote I found the game worked wonderfully. I didn't have to worry as much as I usually have to about bizarre runtime behaviour and the likes.

Programming Tetris was overall a fairly easy activity for me. I've had enough experience by now writing basic 2D games like this from scratch that I knew exactly what I would need and how to write it. A render loop here, and a gameplay loop there... some abstract classes and a pinch of graphics manipulation and voila! That's not to say there weren't any challenges... I attempted to write a generic rotation function that would be capable of rotating any shape by 90 degrees but failed and resorted to hardcoding the rotations - this was possible because there was only a handful of shapes. I also dealt with many bugs that I wrote in my misunderstanding of C++ styles or just plain carelessness. The last bug I solved was a fun one:

Once the gameover screen was displayed you could press enter to restart the game. That worked fine, but the GAME OVER text didn't vanish. I checked the code to make it disappear, and it all seemed right. When the game detected game over it showed the text and stored the pointer to it, and when the player triggered restart that pointer was cleared from the render list. It all checked out. So, what was going on?  The big clue was when I watched the resource allocation graph Visual Studio helpfully gives in debug mode. It was happily chugging up and down most of the game until the game over screen appeared... at which point it started climbing like a mountain goat, straight up. The cause? The code to check when to add the game over screen was in the main game loop, so each game tick it was triggered over and over, adding a new gameover screen to the render list every time. When restart occurred the game dutifully removed the pointer it had to the game over screen - but this was just the last pointer it had, there were still a few hundred thousand gameover screens displayed underneath it. Whoops!

Anyway, I won't talk any more about the Tetris project. I wanted to mention it to show I haven't been doing nothing. You can see the git repo for it here if you want to see the code: https://gitlab.com/SquidEmpire/tetris2

So now, what have I done for this game?

Mostly... spritework. There's so much to be done and as always I suffer from thinking "what if"? What if my sprites are not good enough? What if I used a stronger pallet and reduced the colours? What if I redid the grass tiles? What if I use a shader for water, or what if I hand drew all the water myself? It's easy to become paralysed by thinking what you've done isn't good enough, I know. The only solution is just to power on and answer "I can fix it later" to all the what ifs. Of course, that's the actual decision. Just making the call and telling yourself I can fix it later IS the actual decision. Rarely do I ever fix things later, but the option is always there. Better to make some decision at all than to languish in "what ifs".

And so, I have been doing building sprites for my Arcadians.

Briar Homestead

Unlike the communal utilitarian Union, the individualistic Arcadians live in houses that are as personalised as they are individual. To this end I am drawing all their houses completely custom, pixel by pixel, as opposed to the Union's tilesheet based architecture. This means a lot of time spend pushing pixels around, but I think it is important to visually set the two factions apart. 

The Briar Homestead (above) is designed to be a mix between a traditional English farmhouse and an ecological "green" structure. I have a thick layer on turf on the roof and used a green tint for rocks that make up the walls. The house will be on top of a hill on some rolling plains, with old drystone walls rising and sinking from the thick grass. 

Here's the description of the homestead from my designs:

Briar Homestead

The biggest and westernmost homestead in the area, Briar homestead is a large turf covered rough stone complex, located atop a gently sloping grass hill and surrounded by plains dotted with small ponds and clumps of trees. The area’s terrain bears the outline of the remains of an 18th century manor house: Greenehall Prirory, itself built on the ruins of an older monastery, which was built on an old Norman castle which in turn was built on a roman fort. The areas adjacent to the hill are now covered over by fields, where the Briar family grows wheat, potatoes, and vegetables. The homestead proper consists of a main hall, four bedrooms, a small library, kitchen, storehouse, mill, an apiary, and a - now disused - barn. There is a barrow to the south of the homestead, where preceding generations of the family are buried. 

Teljä Homestead

Here is the Teljä Homestead. It is based on a kesämökki. There will also be a boathouse and sauna building in the same complex, made in the same style. For this building I took a red colour scheme and drew all the shingles on the roof by hand over about an hour, hurting my wrist in the process. As with a lot of my work about 1/2 of the way through I was extremely pleased with the result, thinking it might be my best ever, and then by the time I get to the end I am less enthusiastic. The singles on the small extension on the front are haphazard and poorly defined. The roof's angle appears wrong. The house doesn't look right. It will be a lot of work to redo this one later if I have to, so for now it will do, but I am keeping it in the back of my mind. 

This homestead is described as so:

Teljä Homestead

In the far north of the Arcadian lands on the shoreline is the homestead of the Lahtinen family. The homestead is strongly built from timber near the shore, where the Lahitnen’s focus is on fishing. There are three main buildings, the homestead proper, the boat shed, and the sauna house.There is very little cleared land around the homestead, and only a small herb and vegetable garden.

I haven't started on the final homestead, the Temple Homestead. That one is to be a simple small log cabin.

There's a lot to do and my plan to get a demo out by the end of the year demands I work hard, but I still think it's doable!

Thanks for having a read ;)

Putting sprite to grid

 I've started laying sprites. Nice! I wrote in the last post that I was looking for a way to start building the actual maps for the game. I did it! And from there I've been building up the main game map. While doing that I've also been making new sprites to fill niches that are missing I notice as I lay out my map. 

This feels like a milestone. After months of laying down the foundations, all the programming and artwork, I can finally walk around my game's world. What a feeling! 

A short clip showing how the game plays at the moment

I was looking into using a tool or external program (even rolling my own) to build and load the map after having a hard time using Unity's in-built tile editor. I solved the main problem I was having with unity though, so I have been using that so far. The problem I was having was that every time I updated any or my spritesheets all the existing sprites on the map would break. It was doing this because Unity is smart with the way it splits spritesheets up into individual sprites: it will ignore empty spaces by default. If later on I went and added a sprite in one of the blank spaces the ids of all the rest of the sprites would change as well. The solution was simple: I discovered that this was what was happening - the hard part - and then I 
found the setting to tell Unity to allow empty spaces in spritesheets. Voilà!

The gates of the Union...

I quickly found I needed a lot more sprites than I currently had. I really needed more small terrain details and things to break up the plain grass that made up a lot of the open areas. So, I spent a bit of time working on those. I also started up again on my industrial sprites, because I needed a lot more of them to even start laying out the industrial areas. 

A bin chicken at home on a pile of landfill

After mucking around in-game and walking around for a bit, I think I will need to pull the camera up a little. It's hard to get a sense of any scale when you can't see more than a metre in front of you. I kept the camera close in originally to keep the view focused and restrictive, but now I think I need to relax it a bit.

Astroturf lawns

I also had some thoughts about the gameplay, again. I've not yet reached a point where I'm as confident with the gameplay as I want to be. I've reached compromises that satisfied me before along the way, but nothing has yet felt finalised. A game generally consists of puzzles for a player to solve, giving them a mental or reflex challenge that feels good to solve. So far my game has none of that. While of course I don't have to go all in and add pointless puzzle minigames to my game I do feel that I have to make some effort to speak the language of a video game in my project. I believe with some minor tweaks to my story I can add in some basic survival and problem-solving challenges, while also streamlining the introductory story and setting of the game. I don't want to talk too much about these changes here just now though, I'll let you know next blog post whether they're going ahead.

For now though, I'm going to continue laying out the main map and adding required sprites as I go.

Characters: done

It has, once more, been too long since my last post ;_;

I've been working much slower than I would like, and I believe I know why. But first, what have I been doing? I've been ploughing through the characters, still. I completely finished the character portraits and am just about through the sprites as well. Hooray! It's been a long process, much longer than I am comfortable with, but the results are good at it's just about over.

So let's start with the character portraits:

I'm pretty happy with these. Actually, very happy. It was a really fun time drawing them and I feel like I learned a lot about what I was doing as I went. I would be a lot more confident drawing more in the future, that's for sure. The portraits also really helped me when writing the characters. Having a face to look at helped me write what sort of people they would be like, and of course the character descriptions also informed the portraits. Two-way street.

These will be used in the game when talking to these NPCs. 

But the rest of the time in the game world, the characters will be represented through their sprites. I hoped the sprites would be much faster to draw than the portraits due to already having the colours and features worked out, but alas I was still only able to do perhaps 3 a day. At the moment I have a few left to do, but most of the sprites are done. Here's the new ones in no particular order:

Of course, working in 32x32 is much more limiting, and it can be hard to get across facial features. I think I've done a good job overall though so far. There's a few that might need to be revised to raise contrast or add detail, but I will wait until I have seen them in game to decide to do that.

Of course, all the sprites come in sheets. They look like this:

With this I can animate my charcters shuffling about or standing around in different directions. I left one column empty for two reasons: I wanted to save that in case I needed another pose later, and I wanted to keep my sheets power of two sizes.

Here's some example animations:

I already wrote my own animation script for this which I mentioned a few blog posts back. I've also since then had some more experience with manual animation work, having written two sprite animators in JS for both Three.js and HTML canvas. I think it's worth mentioning the Three.js project. I won't go into detail here yet because it's not super relevant to this project, but I spent about a week working like a madman on a 3D FPS engine thing in Three.js just to see if I could. I could, and it turned out ok. I never implimented physics and didn't want to import a library for it, so the enemy behaviour isn't great on the terrain, but other than that it's fairly complete. It was a fun project and I learned a great deal about game development techniques and fundamentals; things like game loops/render loops, the purpose of coroutines, and so on. You can see the result of it here -> http://www.squidempire.com/plutonium/index, and you can see the code here -> https://gitlab.com/SquidEmpire/plutonium

Anyway, I said I had an idea why work is progressing too slowly here. It's the same reason I did the project I just mentioned I think; I'm driven and motivated by results. I like to see things happen. It's been a very long time on this project since I made anything happen. Drawing characters and writing their stories is fun and productive, but at the end of it there's no tangible result. The actual game isn't any further progressed. And so, I started getting demotivated. I didn't want to fire up paint and just draw sprites and then go to bed. So, hopefully now that I've forced myself through this period I can start making things happen again and the game progress will speed up once more. I would like to have a demo ready before the end of the year. I don't think it's an unresonable goal, the game logic is sound, the characters and writen and drawn. I just need to find a way to build the level and start laying the content down.

Burnout + my characters

I burned myself out about a month ago on this project when I had the genius idea of making a video about the game's world using archive footage. I three solid days collecting archive footage, scouring through hours and hours of videos to find relevant clips, and assembling a video from it all. And after all that...

The video was "ok". It didn't really have a solid purpose or direction and was in the end just a rambling series of clips. I should have known that that would be the outcome from the start, but I was excited and having a good time, so it didn't bother me at the time. However, the realisation afterwards that I had spent hours on something that was never going to be useful, combined with the deep dive I had to perform into my game's lore and setting and the concentration that required left me deeply exhausted.

It's taken me weeks to get back on track afterwards, which has been a bitter pill to swallow, but now that I am back on track I'm working at a good pace again. The video was not 100% wasted time, I'm confident that later on I can make a much tighter cut using the best clips I acquired and make something really dazzling and punchy, but for now I've moved on to the characters of my game.

I started a character document with the details of all the NPCs planned for my game months ago, but progress was very very slow. I never seemed to want to write, and the illustrations for the characters were similarly stop and start. After I recovered from my self inflicted burns I focused on this character reference, planning on finishing it all. It dragged on and on, taking longer and longer than I expected. I was really not prepared for how long it would take me to invent and polish my characters. Turns out writing interesting people is hard! I did end up enjoying myself immensely though once I got the swing of it, and I'm really proud of a few of my NPCs especially.

The document as it stands is 8700 words, and describes 11 Union NPCs and 12 Arcadian NPCs. Each NPC is designed to represent a certain aspect of their faction, some good, some bad, some inbetween. They are going to be met and interacted with by the player character at different stages of the game, and provide different insights and responses. Here's what I have for one of my Union characters:

Hamish Broom

Alignment: Union

Job: Particle Physicist 

Location: Cervine Tower

Appearance: Hamish is 46, tall, dark skinned, and with bad posture. He keeps himself well groomed but smokes heavily.

Summary: Long long ago Hamish was born in an Unincorporated region in central Africa under a different name. The Union arrived when he was only 3 and he was soon processed and registered along with the rest of his family. While the Central AI tries to make special accommodations for families that enter the Union system “whole”, eventually they have to be fully integrated back into the regular Union system and the family unit split up. The child who would be renamed “Hamish Broom” was sent to a separate Union facility from his parents at age 11 and began his new life. Hamish was a quiet child who, although he was different to his classmates, was never bullied or exploited. He did well at his studies, and eventually fell into working as a particle physicist in one of the labs at Cervine Tower. He has been there ever since, for 4 years so far, making minor discoveries in the field of neutrino dynamics. He works closely with a lab at the antipode of Cervine Tower to do this, sending beams of neutrinos there through the earth.

Interaction: Hamish is a man who is not fully Union, though he chooses to be there. He is unlike many other Union characters in that he is aware of the Arcadians and is willing to talk about them; he is curious about his ancestry and history. His skin colour makes him feel vaguely out of place, even when no one else around him seems to notice. He likes to debate with the player about the Arcadians, and whether they have the right idea for humanity's future, but ultimately cannot get over their abandonment of scientific progress. He will talk practically about his work, and admits it is not immediately “useful” but believes strongly in the cause of science for science’s sake.

And here's one of my Arcadian characters:

Timo Lahtinen

 

Alignment: Arcadian (Lahtinen) Job: Lahtinen patriarch / fisherLocation: Teljä homestead, surrounding terrain, Lake GoodeAppearance: Timo is a solidly built man. He is of moderate height and is generally unassuming in appearance. He is around 40 years old.Summary: Timo is a restless soul, attracted to the solitude of remote places. He left home at the age of 15 to roam the wilderness, travelling by boats he made to cross lakes and seas multiple times. Eventually his roaming concentrated on this region, which he found to be particularly beautiful. He discovered and soon fell in love with Lyyti and signed up with her father Pekka’s war party to try to get closer to her. The party was a disaster facing Union drones in great numbers. Lyyti’s father pushed the party onwards despite the casualties, until there were only three left - Pekka, Timo, and Sean Temple. As the three entered a clearing a rush of bullets tore into them - knocking them all down. Pekka demanded they rise and continue, goading Timo by calling him a coward, while Sean lay dying and Timo’s leg ached. Timo crawled to the collapsed Pekka and murdered him with a knife, then dragged himself to Sean to bandage his wounds. Horribly wounded, he made the arduous trek back to Teljä, supporting and protecting the semi-conscious sean all with a broken leg and rib. Timo told Lyyti little of the events, claiming Pekka died a hero. Lyyti was heartbroken by the death of her father but the two bonded over caring for the critically wounded Sean. Eventually Sean died without regaining consciousness and Lyyti and Timo were married soon after. They had three children, the firstborn being a son who died at age 2.Timo genuinely loves Lyyti, while Lyyti is content with him. He is very proud and protective of his two daughters, but worries they are too dependent on Lyyti to survive on their own. He avoids the more militant Arcadian groups out of fear they might hurt Paula. He continues to trek into the deep wilderness at least once a year, vanishing for months at a time to visit distant mountains or lakes. He is acutely troubled by his betrayal of Pekka and his supposed cowardice, and is secretly terrified of the Union and fighting in general.Interaction:Timo presents the player with a neutral look at the Arcadian life. He is a non-violent, unpretentious, quiet man who simply lives the way he knows. At the same time, he is strong and independent, having little interest in the opinions of others and needing nothing to be done for him. He is slow to talk to the player, but may be coaxed to talk at length if met in the wilderness.

In addition, I finished all the portraits for the Union characters, and started the Arcadian ones. Drawing the portraits was very relaxing for me, and I learnt a lot about portrait drawing as I went along, getting better by the end. I went back and touched up some older portraits as I went and refined my work.

Union character portraits

That is about all I have at the moment unfortunately. It's been a bit of a rollercoaster recently, but I'm hopefully back on track now. The next thing I'm going to do (after finishing the Arcadian portraits) will be the NPC sprites, and then some investigations into how I can make level editing easier.