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 ;)