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.