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.