Jan 13, 2016

Progress Update January 2016

Happy new year everyone!

What have I been up to since October? Less than I would have liked. However, I've made some excellent progress on the crafting system again, taking some influence from games I've been playing recently. Unfortunately I find it way too easy to make my game systems crazy complicated.

One of the risks of being a one man dev operation is you have to be your own bullshit filter. I often get so enamoured with an idea I'm working on I don't realise it will be terribly complicated for the player until I'm a decent way in. Eventually (once the shine wears off) the sanity police rock up and I drastically cut functionality and make it sane. I just wish it'd happen sooner, so I don't waste development effort. :)

On a related note, recently I've discovered some annoying issues in my codebase that are not going to be quick fixes and are preventing me from building certain pieces of functionality. They are relatively minor presentation things, so it isn't a big deal at this stage, but at some point I'm going to have to redesign my UI system to be more flexible. Not looking forward to that at all.

On a non coding front, I recently made some major breakthroughs on the backstory front. I've broadly defined the story elements that will occur leading up to the player taking control and even had some ideas for a short intro sequence to relate this to the player. Previously I had a general idea for what I wanted but there was no clear path from normal world to the game world, narratively speaking.

In the development pipeline for the future I have: Finishing off the crafting system, as well as some technical architecture things such as a procedural content system I've been itching to get going on, as well as rendering improvements such as LOD for my terrain meshes.

Until next time!

Oct 22, 2015

Progress Update October 2015

A while back I finished Snapshot 12. It turned out to be one of the longest snapshots I've worked on, coming out at about 8 months. Most of the changes were behind the scenes stuff, so to most users nothing has changed since the beginning of the year.

Under the hood, I've made quite a lot of changes. The biggest of which is splitting the codebase into a client and a server thread. Currently the server thread takes care of creating the initial terrain, and nothing more.  However, over the next few snapshots I'll gradually move more of the client's processing into the server, with the eventually goal of supporting multiplayer.

One of the biggest issues I encountered during that time was serialisation of gamestate. Somewhere around 2 years ago I made an error in judgement which made serialisation impossible without an extensive rewrite. I didn't notice at the time because I hadn't written any of the serialisation code yet.

In retrospect I should have implemented the save and load functions early on. This would have forced me to consider game state serialisation immediately.

So, lessons to be learned here:

1) As soon as you start creating game objects, write the code that serialises and deserialises them.
2) Maintain your serialising code. If you modify the game objects, modify the serialisers. Don't rely on coming back to it at a later date. You will forget.
3) Write unit tests to verify your serialisation/deserialisation process works correctly and then maintain them.

Jul 5, 2015

Progress Update July 2015

In the last couple of months I've continued integrating the fruits of my new terrain generator side-project into the main project. Progress has been good, and I should be up and running with the new terrain any day now.

I took a brief detour to explore network connectivity as I've always imagined that Bulldog would eventually support multiplayer functionality. Since I started the project with singleplayer in mind, there's a great deal of work to do to make the game client/server capable. I decided to kick things off by getting the new terrain generator to run on the server thread, and have the client request it via a network call, as it will eventually function that way for multiplayer.

Before I could get going on that I needed to decide on a network stack. I started rolling my own and got a little ways into it with a brief proof of concept that achieved listening and connecting before I decided to look around for pre-built network solutions for .net.  The first one I came across was RakNet, it's been around for quite some time, is used by a lot of people and supports C#.

I grabbed the source and I've spent 4 hours trying to get the examples compiling. I followed the c# tutorial and ran into issues, such as the build failing due to missing folders. So I fixed that by creating the folders. Then there were files missing from the project. I found them and added them to the project. None of the generated files have any standard "using" clauses, so I add the required "using" clauses to the generated code. Now I'm stuck with build errors such as "Cannot implicitly convert type 'RakNet.Row' to 'RakNet.TableRow'" or "Cannot apply indexing with [] to an expression of type 'RakNet.SWIGTYPE_p_DataStructures__ListT_DataStructures__Table__Cell_p_t'"... the list goes on...

The above paragraph is actually from a gamedev.net post I wrote in desperation after having no success with RakNet. Luckily, my friend, axefrog, saw my post and put me onto lidgren, which I'd also seen during my searches before I settled on RakNet.

I took his advice and checked it out and the difference was like night and day. It required one tiny tweak to get it working (Bulldog is built on .net 4 and the latest lidgren assumes .net 4.5 or higher). I hit the internet for tutorials to write some test code. Unfortunately most lidgren tutorials are slightly out of date, leading to a weird corruption issue with status messages, but I sorted that out quickly. In an hour or so I was up and running with a decent message-based network system.

This represents a big change. It's very unlike me to rely on 3rd party components. I much prefer to write everything myself as I can fix bugs in my own code or add functionality I need. I felt vindicated by the difficulties I experienced with RakNet and was itching to go back to the roll your own method. The subtext of my gamedev.net post was that if I didn't get some decent suggestions I was going back to my own implementation.

In the end I'm glad I didn't, and I'm indebted to axefrog for putting me on the right path.  Cheers, mate!

Apr 14, 2015

Progress Update April 2015

This morning I fired up Mercurial and noted that my last check-in was 6 weeks ago. I'm kind of surprised, I expected it to be much longer. The last couple of months has seen my day job almost completely take over my life. Working on the weekends and out of hours meant there's been little time to even say "hi" to my family, let alone work on this side project. Fortunately, the crunch is now over, and I can go back to a more manageable schedule.

What has happened in the last 5 months? Early on I decided to completely rewrite my terrain generator to incorporate a long list of improvements, as well as finally get around to producing correct biomes.  The main project is currently using my 2nd generation Terrain generator from a few years ago, and this new one will be version 5. What happened to version 3 & 4? They were experiments that failed but ended up teaching me the techniques I've now honed in version 5. The new terrain generator is faster and produces much more interesting terrain than before, but so far I've failed to achieve the full objective of producing biomes.

An example of the terrain I'm currently creating. 

The rainfall map generated for the same terrain.

Part of the reason is due to the intrusion of my day job into my spare time as outlined at the beginning of the post. The second is that I'm in uncharted territory and there has been a great deal of trial and error. One of the key factors involved in biome assignment is rainfall, which is a fairly complex phenomenon. In the real world, it involves temperature, pressure, moisture, wind and is affected by the topography of the land itself.

However, I'm not trying to simulate a full on climate system, so I've taken a bunch of shortcuts. Like others, I've tried to seed the world with moisture, then introduce winds, and let them move the mositure around generating rainfall. Since this is a gross abstraction of what is really happening, the results are quite unpredictable, and its taken alot of tweaking and fine-tuning of the overall algorithm to achieve useful results. That said, its still not right. Some areas are completely bone dry, and others receive the equivalent of an olympic swimming pool of water every hour.

To add to the complexity, I decided to take into account seasons. In the real world, average wind patterns change with the seasons, leading to vastly varying rainfall. I wanted to achieve something akin to realistic conditions on earth. Eg, some places have about the same rainfall all year, others have a distinct wet season where the rains are torrential, whilst others receive very little rainfall all year round.

I said earlier that I failed at my objective to produce biomes. I decided to have a go at the terrain generation rewrite because I'd made good progress in the previous months re: updates and thought I needed to work on something a bit more experimental for a few weeks. That ballooned into several months, and its not even finished yet, so tangible progress on the main project is non-existent, because the new terrain generator isn't finished enough to make use of.

Time to knuckle down and finish.