TerrainSplatting

Devlog: Terrain Splatting

After writing my last devlog post I laid out a roadmap of mini-releases that I wanted to follow that would incrementally add more systems to my game idea, give fast visual feedback and take me to the fun faster. Since my game takes place on a gameboard, it seemed fitting that the first place to start would be to implement the terrain using splatting.

topdown

Final result: 9 32×32 chunks of integrated terrain.

Terrain Concept

For this first test I wanted a flat terrain made of multiple Materials like rock, grass, and sand. I didn’t really care about elevation at this point and I didn’t care about realistic distribution of Materials in the terrain. My goal for the test was to have a system in place that generated terrain and displayed information about the Materials that made up the terrain.

Terrain Splatting Implementation

The most visual way I could think of to display the materials was to have a texture assigned to each Material and render the sections of the terrain that have that Material using the Material’s texture. The problem is that I didn’t want to have square sections of terrain with discrete tiles. I wanted the terrain to blend from one texture to another. So after a bit of research I decided to use Splatting.
For the curious, there’s an article that explains how to implement Splatting at the bottom of this post. Unity does do Splatting out of the box, but I thought it would be quicker to write a small terrain generator that did exactly what I wanted than it would be to learn to bend Unity’s terrain system to my procedural generation needs.

Results

The results are pretty nice. Here are some screen shots of my testing.

Splatting Test Random 1
Splatting Test Random 2
Splatting Test Random
ProgressionTest
Terrain Splatting

Next Steps

Camera Control and Debugging info.

Resources

df

Devlog: Designing a Simulation

Simulation Concept

I’m a simulation junkie. I like creating game rules and watching them play out. I don’t usually care about the level of interactivity. That’s why most of my personal projects involve simulating existing rule sets, like creating an adventure simulator for Dungeons and Dragons.
For my next project I want to create a simulation game using my own rules and with the goal of creating an interactive game instead of merely a simulation. The difference is not that subtle. Dwarf Fortress, a game I absolutely love, is an example of a simulation with game elements. The game is meant to simulate a fantasy world with as much realism as the author can muster. My aim with this project is to use a game-first approach to creating a simulation.

Dwarf Fortress - a simulation game
Clockwork Empires - a game of simulation

Dwarf Fortress, A simulation game and Clockwork Empires, A game of simulation.

Documenting

All projects start with a concept. The first thing I’ve done is to create a small design document that forces me to put to text my ideas for the game. Since I will be the only audience for the design document, the document is nothing more than a text file written using Notepad++. I get to leave out a lot of “pitch” pieces of the design document and focus on filling out the pieces that the developers (Me) will use to create the game.
Putting on my designer hat I start the document with a synopsis. This has a one or two sentence description of the game. That’s followed by a somewhat rambling brain-dump of gameplay concepts at a high level. I’m writing this feature list not for the final game itself, but for the first playable iteration of the game. Chances are my game will change significantly from the first iteration so there’s no point sinking too much brain power into features that will never exist.

A prototype for Spore.

A prototype for Spore.

While I’m going through the features I take notes on whatever my imagination tells me. If it’s something that must exist immediately in the game, I go ahead and put in the description. Otherwise I classify it as a Future feature or Optional feature. This is exceptionally critical in designing a simulation. By their very natures simulations create approximations of observed/imagined situations. This can go on ad nauseam to the point where you end up with a sub-atomic simulation of all matter. That’s a bit beyond the scope of my intended game. This one of the things that separates a simulation like Dwarf Fortress from a game like Clockwork Empires. Dwarf fortress simulates the properties of materials (like density, etc) and lets those material properties dictate the effectiveness of final objects. While that’s an exceptional feature, the concept can be simulated without implementing densities of materials without impacting the function of the game.

Features

Below is an example of what my document has at this point. The features are listed in the order I thought them up, not in any particular measure of importance or priority. This will help me in the future since I can read this document like my original thoughts and pick up on a train of thought and follow it. I generally have a reason listed next to my features to remind future me of why I thought this feature would be a useful addition to the game. These were left off of the list below to save a bit of space. A good option for organizing thoughts is to use something like OneNote or Evernote which can let you group ideas together and link pages of notes.
Genre

  • A science fiction based economic simulation PC game

Synopsis

  • A starship carrying travellers has been hijacked and the surviving crew are left stranded on a planet without hope of rescue. Survive.

Key Features

  • 3D Game
  • Designed for gameplay first instead of simulation accuracy.
  • Modding should a consideration from the beginning
  • Start on a randomly generated planet
  • Start with several people
  • Populate a starting map with flora, fauna, resources, and water
  • People have a high level of autonomy
  • More Omitted…
  • People have basic needs that must be fulfilled: Food, Water, Shelter
  • People without basic needs for a time will die
  • The basic game will “end” when all needs are met for a period of time
  • Allow the player to play multiple saved games

Future Features

  • Support Release on Steam (Achievements, Cards, Streaming, etc.)
  • Allow choice of starting conditions/scenarios
  • Allow customization of starting planet
  • Allow customization of starting people
  • Allow people to own rooms, objects, and items
  • More Omitted…
  • Add Moderate Needs: Dietary diversity, Health(Mental, Spiritual), Entertainment, Hobbies, Aesthetics, Wealth/Employment
  • Add Complex Needs: Complex Needs: Desires, Goals
  • Add Biomes to the world
  • Support destructive world for resource removal

Optional Features

  • Unlock new starting conditions by reaching milestones.
  • Allow different races.
  • More Omitted…
  • Allow for creation of organizations with heraldry, values, etc.
  • Allow for different levels of gameplay once society reaches developmental points

Look And Feel

Now I can remove the designer hat and put on my stylish User Experience expert hat. (Hmm… can’t find one that says expert, I guess this ratty beret will do.) There’s a lovely art/science that goes into user experience and user interface design. I have few of those skills. I do still want to document my thoughts on the User Interface because these will shape the architecture of the game. I close my eyes again and imagine someone playing my game and executing each of the features I listed in my design document. What does it look like? How do I access that feature? How is the feature customized? Here are the results for a couple of my features:
Gameboard

  • The gameboard is rendered in 3D
  • The camera by default is above the gameboard looking down at a moderate angle.
  • The camera can be zoomed out and in to certain constraints
  • The camera can be rotated freely using the mouse or by 90 degree increments using the keyboard
  • The surface is populated with flora appropriate to the material for the surface area
  • Different areas on the surface are textured depending on the properties of the material that makes up that area

GameObject Ineraction

  • During normal gameplay, Clicking on a GameObject (Person, creature, item, object, room, building) will display a contextual panel
  • The panel describes the item and its state
  • The panel displays interaction options with the GameObject
  • The panel is dismissed by pressing ‘ESC’ or a close button
  • Clicking on another GameObject will replace the contents of the currently displayed detail panel

Game Data

As I build out my features I think about what data will be required to get the game to work. For example, while thinking about my Gameboard’s look and feel I noted the materials that would affect the display of the ground. I made a list of Materials I’d need. I like to use a spreadsheet program for this and use a separate sheet in the workbook for each type of data. Be careful, it’s very easy to go overboard on data. Just like with features, record all of your ideas, but keep the data that’s not absolutely required for your first iteration of the game separate.

Architecture

Can I start coding yet? Nope. Time for the Software Architect’s hat to go on! The first stop for me is choosing an engine. There are a lot of great engines out there, but you can’t beat free. The most compelling engine for me is Unity3D. It has a great extensible editor, uses a language I’m very familiar with, and I’ve played with it for years.
The choice of engine really shapes how I’m going to view data. I tend to start designing systems by looking at the data that’s going to be passing through these systems. At their core Games are a while loop that processes data. A Game Engine maintains that loop and it crunches through the data we give to it. The data exist in two major forms: static data files and instanced data that is persisted in memory or serialized to and from storage. Unity takes care of the engine, provides an editor to create static data and provides a way to store and retrieve instanced data.
On to the data. What does the data look like? What is static? What is instanced? How does static data relate to instanced data? What systems consume data? What is the output of that system? In other words: what is the data, where does it need to go, and how does it get there? This is where I have to be careful. I’m still documenting so I don’t want to get into implementations now, otherwise I might as well just start slapping code together.
Here’s an example of the data required for a crafting system.

Crafting Recipe (Static)
Member Description
Name Displayed to Player
Id For other data to refer to this data.
Input Items Item Type Identifiers with Quantities
Output Items Item Type Identifiers with Quantities
Base Duration Time to complete crafting.
Required Tool Id of a Tool Type. Can be empty indicating it can’t be hand crafted.
Required Object Id of an Object Type. Can be empty indicating it can’t be crafted at an object
Crafting Recipe (Dynamic)
Member Description
Template The static Crafting Recipe data.
Crafter The Person crafting this recipe
Inputs Dynamic item data for the items used as inputs
Progress The amount of time spent on this recipe
Tool The tool being used to craft the item.
Workshop The Object that the item is being created with.
Crafting Recipe (Person View)
Member Description
Percentage Complete
Remaining Time Time until completion. Based on simulation factors.
Name Recipe Name
Outputs Item View of outputs. Based on inputs and simulation factors.
Crafting Recipe Management
Object Name Domain
Crafting Recipe Table Manages Static Crafting Recipe.
Crafting Recipe Controller Belongs to the Simulation. Manages Dynamic Crafting Recipe.

Sorry if that’s a lot to digest. I just wanted to share an example of how I envision data flowing from a definition on disk (static), to a simulation element (dynamic), into the scene (view) and how I’ll manage them (table and controller). Even this might be too “implementation-y”, but I find it helpful to think about data members before I get started. For each type of data I write down the pieces I know I’ll need to define the data and then think about how I want to show information about that data to the player. That can bring up a lot of other pieces of data I’ve overlooked like game asset references.

Finding the Fun

So now I have a list of things I’d like to do in the game, a good idea of how it will look, and how the data flows through the game to the Player, but will it all be fun? Well, I can get an idea of what might be fun by keeping my target audience in mind, but really the only way to find out if things are fun or not is to start creating.

Next

Terrain Splatting

Resources

Fail Faster, and Follow the Fun
Game Engine Architecture, Second Edition
Learn with Unity
Evernote

StarLanesTraderMainMenuMini

An Experiment in Rapid Game Development

I love game development! I’ve done it as a hobby for years, but I’ve never completed anything I’ve wanted to share with people. I’ve contributed to mods for other games like Civilization 4 and 5. I’ve worked on some open source projects, and I’ve made some pretty simple games for myself that have proven entertaining. A couple of weeks ago I decided it was time to change all that. I challenged myself to spend a long weekend on creating a fully playable game in 4 days. Ridiculous right? Well, not with the proper tools.

The Proper Tools

I decided that to do this I would have to play to my strengths. I know and love and hate C++ with as much passion as the next developer, but I knew that to get a game going I’d have to be quick and use my strongest language: C#. Next I had to choose an engine. As fun as engine development is, when you only have 4 days to make a game, it certainly pays to get all the guts “off the shelf”. Most of the engines I have experience with are C++ engines so my knowledge of C# engines was a little rusty. I knew about Unity3D and had used it to play around with before and they’d released a new version, and they’re also free. I also considered XNA Framework, but since I was looking for rapid development I ended up choosing Unity3D since it has a rich feature set, excellent creation tools, and most of the features I wanted. It would require a lot of learning, but it seemed to me the engine would be relatively easy to pick up. Now all I needed was an idea.

An Idea

Like most aspiring designers/developers I have a design document describing my Magnum Opus. I took this, found the most basic features that would make the game a game, and began plotting. I ended up throwing the idea out because it just wouldn’t do the game justice. And all my art is the epitome of “Developer Art”, so, I came up with a new plot. I decided to design a game based on the old games I used to waste hours and hours on. One that wouldn’t need a slew of graphics, and could have compelling game play in a matter of days. With a humble beginning and proper architecture a small idea like this could easily grow. I based my new game on the old Trade Wars games that populated the BBSes of my youth. Next I needed a design.

A Design

Rather than writing an entire document for a game that would be developed in 4 days (getting closer to 3 by this point) I decided to use Pivotal Tracker to jot down my ideas in the form of stories, and a spiral bound notebook to draw out gameplay screens. I described a target set of features that I would need to have the game be playable (and marginally fun) and worked out the systems that would need to exist to support these gameplay elements. With a set of features, a layout of screens, and a collection of stories on Pivotal Tracker I was now ready to dive into coding.
PivotalTracker

Coding

I expected to spend a lot of time learning how to accomplish tasks in Unity3D so I decided to start with making the behind-the-scenes systems (business logic) first in Visual Studio and creating a dll that I could reference from Unity3D. As a web developer I’m deeply committed to the separation of model from view. 😀 I developed the basic objects that would be needed in the game, modelling them as simply as possible and creating a preliminary set of basic game data in Excel and writing a quick program to export that data into XML and thereby make it easy to load and save objects. I then created the systems to act on those objects and handle simulating the game world. I didn’t go for Test Driven Development in this project but I did create a simple test project that would at least run through the basic features and make sure nothing was glaringly wrong with the game library. By the second day I had most of the systems in place to consider this a game. Now I just needed to tie it all together with user interface and hook Unity3D to my dll. I ran into a few snags integrating the dll to the Unity3D project, but nothing that was strange or badly documented. I got a little giddy when I realized how ridiculously simple Unity3D’s GUI system was and in matter of hours had all of my hand scrawled screens in the spiral bound notebook and a game state manager in Unity3D. It wasn’t pretty, but it was a user interface! I worked my way through the user interface scenes one at a time hooking up the placeholder interface to the code that lived in the dll I created. By the end of day 4 I had a playable game with all the features I originally intended plus a few more with a nasty prototype user interface, random 3D models from TurboSquid, my very own Developer Art 2D icons, and all the tools I needed to expand the game to add features later. Mission accomplished. On to the future!
Gameplay

The Future

So now I’m excited, I’m motivated, and I’m driven. After accomplishing a feat like that, what can’t I do? Since I accomplished this challenge I’ve added more features. I’ve added a modding system, added a bit of polish to the user interface and started work on online play features. I may even add a page to this website to track progress of the game since some folks have expressed interest.

The Tools

So here are the tools I used to rapidly develop a game.