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

Multi-player

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:

Bleeeeh!~~~


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

Unity 5

Unity 5 has been available for paying developers as a beta for quite a while now and, I figured, I might as well get acquainted with it as soon as possible and see how I can apply (if at all) its new toys into my project.

Physical-based shaders and real-time global illumination were the key components that I was interested in.  While saying "real-time" (in the context of global illumination) is not necessarily a lie, the omission of "pre-runtime calculations" in the disclaimer is a major disappointment for me; making it practically useless for my project.  Unity 5 is still in beta, though, so they might eventually remedy that because they're ALMOST there.  With that said, the physical shaders have been really good so far and really makes materials closer to what 3D artists (like myself) are accustomed to.

What really surprised me were the subtle (yet noticeable) changes in some of the other aspects.  On the "good" spectrum, ambient light can now have three colours instead of just one to better control the mood of a given scene.  My code is also quicker to compute now (aside from my own optimization), is lighter at run-time and, therefore, allows for a better graphical performance.

On the "bad" side of things, fog (which adds tremendously to the ambience) can no longer be applied to an already established rendering method... the rendering method that my project is using.  The Unity team implies that developers should be using an "image effect" on a given camera to add the fog (a different way of rendering fog)... which, again, my project cannot practically use given its procedural nature.

So, right now, my project cannot have fog.  Somewhat of a setback but, again, it's all in beta.  They'll have plenty of time to fix things as well as I have time to adjust and rework my project.

It's all good.

On the coding side of things, things are looking great!  I've been spending less time on debugging now; allowing me to experiment with a method of adding secondary lights in really dark areas.  That's to make things less realistic yet more appealing to the eyes and I think, so far, it's showing great promise.  I just need to elaborate on it.

Lights, Crystals, Water and Grass

Nothing encourages me (and my team) more than seeing promising results; and the most recent build of my prototype has been pretty awesome.  It's starting to look like a video game despite having practically nothing in it yet.  It's pretty much all about the environments still and it will continue to be for a few more months.

- added the possibility for multiple alternate paths throughout the environments.
- more lighting adjustments.
- added environmental decorations such as crystals, water and grass.
- more graphical and scripting optimization.

Optimization and bug fixes as been my focus for some time, now.  Large dungeon layouts take roughly a full minute to generate (which is a major improvement) and there are performance dips that occur in certain areas.  I'm starting to see what's causing these dips and finding solutions has been pretty entertaining despite being a destractions from my current priorities.

Right now we're pretty dedicated in adding more and more art assets to make it feel more organic while, at the same time, I'm trying to keep everything as lightweight as possible for a stable performance.  It's essential that my environments run as smooth as possible before I start to inject gameplay elements to them.

I'm at a point where, on the programming side, I'm only doing a few things here and here.  Mostly adjusting variables and fixing a few bugs and coding oversights.  The code is more or less ready (for a prototype) so I can allow myself to take some time and make everything look pretty.

The question to how we're going to procedurally light an envionrment has more or less been figured out and it'll be interesting to see how (well) these solutions.  Our glowing crystals coupled with lights shining from large holes in the ceiling already shows us a glimpse of what can be done.  Regardless of how we're going to light everything, there's still the issue of balancing the areas so that they remain somewhat forboding.

I've noticed that finding the various paths in the dark have been somewhat difficult without following a particular wall.  As an artist, that's an appealing challenge to have.

Screenshot Dump

A lot has changed over the last few months (how long has it been? 6 months since last blog update?). Here's a few noteworthy changes:

• Lighting calibration.
• Guaranteed player pathing.
• Faster procedural algorithms.
• "Organic" dungeon structures.
• Goblin models replaced.
• Camera focus & Occlusion Culling.
• Water implementation.
• Grass implementation.

Small progress

Nothing major changed from the last build.  I added some functionality under the hood and made adjustments here and there.  I'm trying to implement a Shufflebag system for my random values but it's really not working at the moment; I guess that's my big hurdle to overcome this week.

There's also room for improvement to optimize the generation process; some of the dungeons get so large that it can take the computer a very, very long time to complete a task that should be straight forward.  At least I know WHERE to look in order to make the adjustments.

In the following screenshots, you'll see some progress in the different lighting variations, new art assets as well as an updated look at how dungeons are laid out: