Sunday, 31 May 2015

World building

Unity 5's physical shading rendering issues have long been ironed out, the multi-player build was successfully merged with the visual prototype and pretty much everything's working great.

I've been spending some time reworking how players connect/disconnect with one another and (more importantly) how each client would send data to each other.  So far, I'm impressed by the progress that I've made (as a programmer) since I started the project.  My code is getting cleaner, organized and more efficient.

Since a lot of the pieces are falling nicely into place, I decided to take some time to refine a bit of the UI.  It's odd how something as simple as a chat window can make a game feel weird just by it's responsiveness (or lack of thereof to be precise) so that's where most of my focus has been.  I know my friends have been complaining about the clunkiness of typing and how the window itself disappears over time (because it wasn't doing it properly).  Not only are all of these things rectified, but I also applied an option to increase/decrease the time delay for when the chat is hid.  The setting has a "keep chat open permanently" mode but the UI doesn't communicate it yet.

I also looked at how the layout of my UI (I have no art for the UI yet) would work at varied screen resolutions... which has been a challenge considering I'm trying to put as much as possible into the main menu; to avoid excessive clicking in order to get somewhere.  At the same time, I don't want to overwhelm the player while he/she is navigating the menus so, as an artist, I'm making sure that one's eye/attention is directed properly.  I'm not 100% there yet but what I've done so far looks promising.

On the procedural generation front end of the project, there's still a lot of work to do.  Dungeon layouts have been pretty good for a long while now (and work great in multi-player) so, lately, my attention has been on the world map:

So what I got is a map that gets divided into distinct regions where the game's varied nations will inhabit.  Upon generation, the map figures out where to put mountains and then plays a quick and crude game of Risk by itself.  The end result are these images you see above.  Each pixel square (voxel) of the map represents a game area that eventually gets generated.

The type of area each voxel represents is determined by many other factors that I then add to the generation algorithm.
The first step is to make sure that the player can reach every nation (even those on islands) by placing at least one city per nation by the shore; that way a port city can be generated for the player to travel by ship.

Then it's just a matter of establishing an eco-system:

The pink dots are large cities.

I'd like to eventually have an elaborate weather system but, for now, I'm content with day/night cycles that I've yet to fix (because, it's still a bit glitchy - particularly in multi-player).

Monday, 2 February 2015


When I started this project, I had a lot of things figured out.  However, there were just as many unanswered questions; one of which was mutli-player.  I knew I wanted to have a 4 player co-op experience, but I didn't know how I was going to approach it, or how to even code it in the first place.

Well, since the transition to Unity 5, I decided to rewrite the entire thing and give multi-player a try.  This time, I'm writing everything in C# becasue I felt like I've gotten progressively more familiar with it.  The bulk of January has been building something that looks more like a video game rather than a mere virtual-tour of a cave.

It's not perfect as, right now, I'm sending way too much information between computers to convey a smooth movement between characters; resulting in higher bandwidth consumption than I would like.  At least its working.

- 3 other players can join an existing game session through LAN and/or TCP/IP.
- Goblins are moving and can be interacted with.
- Text chat is in.
- Time and Day/Night cycles are in.

For the graphic prototype (what has been in blogged about prior to this post) I stumbled upon a slight issue.  It's nothing major but it's still something problematic: Ever since I made the switch to Unity 5, the Windows version of my compiled game looks radically different (and uglier) than what I've been seeing on the Mac whereas they traditionally looked identical.  It was easy to achieve since, as a Mac developper, if it works on OpenGL, chances are it working fine in DirectX.

Here's what it looks like on the Mac (which is kind of normal):

And here's what it looks like on Windows:


I think Unity 5's new physical graphical engine still needs to be ironed out.