Friday, September 5, 2014

Post Two - "Visual development"

Most games start out with a vision, some even incorporate market research. This one sadly doesn't, that's one of the reasons why I consider this an art/learning project rather than a "real" game.

The graphics of Rancor (and ultimately the gameplay as you will see later) is built around the samurai character, which is actually made for another game! That project turned out to be a bit too ambitious for a one-man-studio such as myself, so that guy found his (temporary) home in Rancor! Did I mention I like recycling?

Since I have no plans of revolutionizing the way users play mobile games, I had to make the visuals as striking as possible.

Paper and pencil is not my mode of expression, so I make sketches in 3ds Max. 
It's convenient to sketch in 3d, because that usually means the finished concept model IS the final model! Efficient, isn't it?

My first concept looked like the following image:

The character was a bit different and not animated. Those files perished in an external HDD accident in the meantime, so this is a "reconstruction". 
This looked very cool on a tablet, so I had decided to develop something along those lines!

This is all great, but how do you actually start making a game? As a 3d artist it was only natural to simply start modeling!

I was inspired by the following 3ds Max presentation:
If you're not a max user it's less great, but still worth watching!


One of Unity's advertised features is that it can handle .max files. With that in mind, a practical person will simply drop the .max file in your Unity project, so it gets updated automatically as you develop your scene in Max. Great huh?

DON'T do it!!!

First of all, as every 3ds Max user knows, unless you save a different version of your file every so often - you'll soon be in a world of hurt! But saving all the different file versions inside your Unity project folder will eventually break it (or it will take ages for the Unity editor to load your project).
Reason no.2: Unity editor doesn't really use .max files directly, but converts them to the .fbx format implicitly, whenever it detects a change (that's what causes the long wait). There's absolutely not a single reason for you to lose control over the .fbx export process - so don't! The third important reason not to have .max files in your project is version control (more on that later, much later..)
So, here comes the first useful lesson in this blog (and so far the only one): 

Have a separate project folder for your assets and import only .fbx and texture files in your Unity project folder, never .max files (or other similarly large and "useless" binary files).


So without overthinking it, I started building my scene in Max. The most prominent object is definitely the terrain:



The concept behind making it is pretty standard (keyword: grayscale height maps), everyone who's ever used Unity's terrain tools (or Unreal, or Cryengine or whatever..) is familiar with the concept. There is only one (not very important) difference. These mountains actually exist and are located in Japan. Extracting real world digital elevation models is a part of my standard visualization workflow. I may write a tutorial someday if there's interest for it, but there are *similar* workflows readily available online, "OK Google..."
A couple of very simple objects make up the rest of this concept game environment. These are subdivided plane primitives with displace modifiers on them (Max's noise map drives the displacement).

Game environment in Max - self-illuminated materials, owing to the game's visual style

I experimented with different material diffuse colors until I came up with this:


Since this is in no way a well thought-out process with a clear goal in mind I've decided (rather impulsively) that it looks better in gray! In later posts dedicated to the game's visuals I'll explain the back story that evolved recently, about each of the 4 different worlds that I plan on making (this is world no.1)

The background seemed pretty dull. What's the point of making a cool terrain without anyone actually seeing it? I also wanted it to look slightly "cartoony" instead of those perfectly smooth Blinn's gradients. It's a standard Max material (with self illumination on 100), but it has this in the diffuse slot:
"..never draw a texture if you can make it procedural.."  - a very clever person
Also, a z-depth pass was rendered with the background and composited on top for some atmospheric perspective and added "coolness".
The final "world 1" background:

With UI elements, background and stuff..

As always, thanks for reading and please subscribe via e-mail on the top of this page and share with friends that might be interested.


Monday, September 1, 2014

Post One: "Init"

This blog is primarily meant for me... Developing a game in one's free time may sound like a fun idea but if you plan on actually releasing a game, things tend to complicate rather quickly!

So again, how is this meant for me, myself and I? 
I need motivation to work on this game regularly (or any personal project, really) and I thought: "..sharing will help..." in between the usual thoughts of "what to eat next?" and "how long until this next render finally finishes"

On top of all this, if someone finds this interesting and/or learns something from my (many) mistakes - GREAT SUCCESS!


About the game:
Rancor is, first and foremost, a learning experience. It can also be called an "art project", if you are so inclined. It probably won't make me rich (financially speaking), since it basically has no target audience.. although it's a casual game meant for mobile platforms. The problem is: it's turning out to be pretty difficult and I don't plan to introduce any in-app purchases that will make gameplay easier. All of this is subject to change, of course. It's a work in progress!


Current state of affairs (Unity player preview of an android build)


About the Blog:
I've seen more than a few development blogs across the web, but I still haven't found one that describes a beginner's experience, especially not through the entire development process. 

Sadly it's simply not possible to go into every detail, issue or technique that I've used. This blog will be quite technical and not particularly interesting to those that have 0 technical knowledge regarding 3D graphics and/or game engines.

However, 3D and graphics in general will not be my focus. Present - yes, focus - no. It's coding that I need to learn, so code I shall, to the best of my abilities... I will even go into more obscure areas such as integrating analytics and social networks in your game and similar "technical" stuff that most people don't even think about when you say: "I'm making a game!"

Special thanks to Mario Antić (Cateia Games) and Lovro Nola (Machina Game Design School) for providing me with (much needed) education in using Unity 3d! It was exactly the push that I needed to actually start doing something, instead of simply experimenting and following meaningless tutorials. Tutorials are great for specific stuff, but developing a game - any game - is something so big and complex that no tutorial can prepare you for it!

The Plan is to post on a (bi)weekly basis, however it's something I can't guarantee, sometimes work gets in the way of life.. unfortunately. 

Until the "real" first post... !

p.s. Don't forget to subscribe via email on the top of the page!