Thursday, February 14, 2013

The Game

I haven’t described much of the game itself that I’m intending to make so I’ll just take a moment now to describe it in full.  It’s an ambitious project but I would prefer to have a “dwarf fortress” like development cycle in that I have a single game which I iteratively add more and more features and make better.  

The idea of Cultura is a long-term game centered around developing a culture from the earliest days of the stone age when humans first discovered fire to the early modern age when carbine wielding cavalry rode alongside steel plated lancers.  It is meant to be a wide world of exploration and imagination with the “FSM” tech tree, where societies can be fantasy or steampunk or mundane (mimicking the real world).

Controls are designed to be RTS-like, with an interface that will be a cross between Anno series (trade system), Settlers (industry chains) and Civilizations (technological research).  The intent is to have a game focused on the diplomacy and trade to give a real sense to cultural development.  War is more personal, trade is intricately tied with diplomacy and your society’s success depends on your ability to deal with your neighbours both in politics and war.  Really, in this game, war is meant to be an extension of politics of the more aggressive factions.

Ultimately, what I picture is that you develop your own society, building industry chains.  You interact with other societies via “diplomatic-trade” routes.  When you are nomadic you can interact with other societies when you meet them.  Eventually you can build an automated trade route which will both exchange goods and allow diplomatic communication when it arrives at your neighbour.  As your society grows, more tasks can be automated to allow you to focus on the “bigger picture”.  The technology itself will be much more “micro” oriented than Civilizations.  It will involve lots of small technological enhancements and “add-on” techs that improve specific items.  This way there is no dividing line between ages, it’s simply a slow progression.

The game is meant to last indefinitely in that you should be able to develop complex relationships within a particular tech age, fight wars, rebuild armies, fight more wars and play with shifting politics.  All within the same tech age.  I’d prefer it to be a game where you can do a lot but technological change is slow unlike in Civilization where either you fight a war that spans 500 years and three tech ages or you try to play marathon pace and the same thing happens except slower (they slow down both production and tech research equally making the game speed option basically totally pointless).

Resources in the game are split between mundane and fantasy.  As an example, metals would be like “copper”, “tin”, “iron”, “aluminium” and then a fantasy set would be “moonstone”, “viperstone”, “treerock”, “dark iron”.  The random map generator will place mundane and fantasy resources beside societies of respective tech trees.  Steampunk societies use both.  There’s no actual limitation on use, these are just for aesthetic reasons (to appeal to the sense that you are developing an interesting culture where one tribe of dark elves somewhere might produce dark iron swords while your mundane society to the south uses copper and tin to sell the dark elves some farming tools for their blades).

Tuesday, February 12, 2013

Skeleton

Ogre3d will be the graphics wrapper used for the engine (at least for now).  It does what seems to be enough.  Also I will use most of the standard plugins for it such as CEGUI.  My next goal after a few tests of the limits of Ogre3d without any optimization (I wanted to see how much static geometry I could make, as well as the number of separate scene nodes with just a single entity while maintaining 60 fps) will be the basic game engine.

The first goal will be to build a modular skeleton such that I can replace components as needed for optimisation or infrastructure improvements (like my camera management will be a wasd ctrl plus capturing the esc key to exit).  I’ll resolve to not replace any components until necessary to either maintain performance or new features.

Skeleton:

  • TerrainManager: from the perspective of the graphics engine to be built, this is a class to handle most of the static geometry and from the perspective of a game, it is everything that makes up the map
  • InputManager: this will handle the mouse/keyboard input from the player (I won’t support joysticks for now), this class might need some children to handle the different menus that might exist (at the beginning maybe a splash screen and then the main game inputManagers), a question for later is whether I’ll keep track of selected units in here
  • ResourceManager: I’d prefer to shift all the logic for loading scripts (meshes, materials etc) in one place and it’ll store all the messiness of knowing where to load everything (as it’ll like be partially hardcoded to a relative directory structure, it’ll just look plain ugly and I’ll put all the ugly in one hidden spot)
  • GameEngine: this part might have to be split up later on but this will contain the main loop and have member variables to all the different managers, it’ll load up the game, maintain the game state (keeping track of whether the player is in a menu, in the game, in some submenu, in an in-game menu etc) but I’m not sure if I want the main loop somewhere else and have a separate stateManager but we’ll see how the code goes

I’m the kind of coder that prefers prototyping over pre-design because I’m mainly uncomfortable with scoping/design without intimate knowledge of the capabilities of what I’m building.  

Sunday, February 10, 2013

A quad

It is a quad!


So Ogre3d is fairly good so far, though I'll have to write out all the optimisation and so on myself.  At least with this I don't need to do all the more low level details.  This is a quad with some random grass texture I grabbed applied to it and then some colour applied etc.

I'm learning both graphics and ogre3d at the same time, which is a bit much at times but I'm getting there.  This dev journal will have some rather noobish comments about graphics as a result.

The Ogre3d engine comes with a trusty scene manager.  Starting from the beginning I...


  1. Loaded up a directory where my resource files are located
  2. Created a material, with one technique, one pass.  The pass applies the grass texture.
  3. Manually defined four vertices to draw two triangles which makes a quad and converted it into a mesh
  4. Used the mesh to create an entity and then gave it the grass material I created
  5. Added the entity to a scene node.

And then I let the engine render it.  There you have a quad with grass on it sitting in some scene.

So my next few issues are:

  • For an RTS I'll want to display lots of terrain and additionally, for my unique situation, there will be lots of stuff sitting on top of the terrain
  • Making lots of scene nodes will devastate performance, so I'll have to think about how to draw a lot of terrain
Both problems are only issues to me because of my inexperience with graphics (my main expertise are math and artificial intelligence).  So I'll probably research the problem first, as it is a common one and given the number of RTS games out there, a solved problem.

Friday, February 8, 2013

Graphics Engine Start


Starting things off, the game being worked on is called Cultura.  In its simplest terms it is an RTS game played in a constant world where you lead a people from the earliest days of the stone age to the early modern era.  The technology spans from fantasy to steampunk to the mundane world.  The entire goal is to build a convincing history and enjoy a world that you help to shape throughout time.

This dev blog deals with everything about the game’s development.

So first, it’s a nice step for me to finally get started on this project as it’s been sitting in my head for quite some time and a lot of far-off ideas about it are floating about that I’d like to do.  The game’s idea is very large; I want players to control the entire development of their society from the earliest days.  Even more I’d like it to be a “losing is fun” type game where even if you lose you can start again on the same map, at the same tech level, and lead a new “off-shoot” society of the one that was just destroyed.  But, we’ll worry about that later.

The first milestone in this project will be getting a graphics engine up and running.  I’m an artificial intelligence guy (and everybody is a core game coder as that’s a more generic speciality) so I prefer not to work on the graphics engine if I can’t help it.  So I’ll be trying out different graphics engines to try to get the first milestone done: render a small patch of terrain on the screen.

On my list of engines I am considering is Torque2d, FIFE, HPL, Ogre3d and Irrlicht.  I’ll initially just be making a 2d isometric game.  A 3d engine is overkill but it does allow me to expand graphics later at no additional cost (that is, I don’t need to dump the engine and get a new one versus modifying the game to use the existing engine but do 3d stuff).  Also, I can throw in 3d effects in a 2d game.  May be useful in the future.

I think that from my initial impressions I may roll with Ogre3d.  It’s in c++, the game is intended to be incredibly CPU intensive in the future, so it’s imperative I start on a good foundation that can scale (but I won’t prematurely optimise of course).  I'll be making the game very 2d at the beginning (textures onto quads or something) and we'll see where to go from there.  I'm trying to keep the focus on gameplay and not graphics.  Once I get the engine building, I’ll try out the tutorials and see how quickly I can get a patch of terrain going and then move on from there.