Brad Wardell's Blog


The Elemental game development project at a glance

Published on Friday, October 23, 2009 By Brad Wardell In Elemental Dev Journals

For those of you who aren’t game developers I thought I would write up a quick article on how modern games are made.

In the old days…

You would code up the game.  There was simply “the game”.  The development team would code their largely from scratch.

Now…

image Games are broken up into many different parts. For the sake of simplicity, we’ll divide it into the two main parts: “The Engine” and the actual game.

Civilization IV licensed Gamebryo for its engine.  Demigod uses the “Forge” engine (which Supreme Commander was built on).  Sins of a Solar Empire is powered by the Iron engine.  Galactic Civilizations used Pear. Virtually any modern game you look at has an engine that is fairly separate from the game.

The Development of Elemental

image The biggest challenge we had for Elemental is that we needed to create a modern game engine designed for land-based strategy games.  This is a non-trivial endeavor.  Much of the initial work had been done with Society but that was really just the tip of the iceberg.

A modern game engine isn’t merely about displaying graphics in 3D. There’s the editors and tools to support content for it, the scripting language to interact with it, the user interface tools, multiplayer tools, etc.

For Elemental, before we could even consider writing “the game” this engine had to be built.  That’s where 90% of our development time thus far has gone.

The BETA of Elemental

The first two betas (beta 1 and beta 2 – which won’t be out for months) don’t include this engine.  If you were at PAX, you saw the engine connected to the game.  But for the beta, it’s stripped out so that we can focus exclusively on the game design in such a way that the beta testers themselves are involved in the actual design.

What Beta testers don’t get to see yet

When we play Elemental, below is what we see:

PAXDEMO(10) PAXDEMO(21)

PAXDEMO(38) PAXDEMO(3)

And these screenshots are actually a month old – the engine is being developed at the same time as the “Game” betas (if you critique the screenshots you can see all kinds of flaws still such as places where shadows aren’t yet working and lighting and bloom flaws and temporary graphics and textures, etc.).

So why are they so separate?

The obvious question is, why not have both be tested at once? The reason for that is that once you start tying “the game” to the engine, you lose a lot of flexibility in making game play changes.

For example, this week we put out the Elemental beta 1B which has the beginnings of the game economy.  Users have concluded, and we agree, that resource inventory just isn’t that fun.  Because the game isn’t part of the engine, it’s literally a 2 hour change and balancing is all data-driven.  By contrast, if the engine had been hooked up there would have been the temptation to display resource inventory visually (piles of wood or stacks of wheat bags for instance). That’s just one example.

That’s why what beta testers in Elemental see right looks like this:

image
I’m in pain!

The objective

The motivation to have the beta be drawn out like this is that for us, creating the game, with you guys, is very important to us – as gamers.  It has been many years since a new turn-based strategy game was made that wasn’t tied to the limitations (both hardware and design-wise) from the 1990s.

And there are a lot of people in this beta who, like us, have been waiting a long time for a game like this to get made and have a lot of good ideas.

Personal perspective

There are many outstanding strategy games out there from Civilization IV to Age of Wonders: Shadow Magic to Dominions 3 to Heroes of Might and Magic to the grandaddy of this sub-genre: Master of Magic.  What I am looking for us to do is create a PC game that has the kind of depth that is found only on PC games these days but at the same time isn’t bogged down in detail and minutia. 

The delicate balance – making sure the game isn’t dumbed down or “consolized” and yet not so complicated that it feels like work is the journey that we’re hoping to make together with you guys and the best way we believe to do that is to have the on-going game “prototype” not be merged with the game engine until the game is fun to play in it’s current “fugly” look.  Because if it’s fun with Commodore 64 type graphics, then it should be amazing when it’s played with a state of the art game engine behind it.

Elemental Beta 1B now up

Published on Friday, October 23, 2009 By Brad Wardell In Elemental Dev Journals

Don’t get excited. It’s still primitive. It will still randomly corrupt your boot disk, kill random pets, and make small children cry. But here’s what’s new:

------------------------------------
Change Log - Beta 1b Update (0.25.015 on Impulse)
------------------------------------
[Refreshed 0.25.014 build to fix an intermittent crash bug on launch and to change unit costs to 1 gp per turn.]
- New Features -
+ Info Cards Displaying rollover data
- Game objects, such as Units, Cities, Caravans, Goodie Huts, and Resources all send mouseover messages to pop up the info card
- Caravans will show their destination, goods carried, and time to reach city
- Units will show their stats, current action or destination, and unit count
- Improvements show time to complete and required materials
- Resources list what tech or known improvement is needed to harvest them
- Cities show net income and basic stats (still needs to show resources coming in)
+ 'Turns to build Improvement' Calculations implemented
- Improvements can now require resources to construct (though none do ATM)
- Gold Cost to Build = Labor x GoldCostPerLaborPt
- Time To Build = Labor + Difference in Resources Available vs. Resources Provided
- These calculations should be displayed in the InfoCard when you roll over an improvement in build mode
- Improvements are now built in a queue
- Gold to build an improvement is instantly removed from the treasury
+ City Context ACTIONS Tab now lists all available actions for a city
- Medallion buttons hidden
- Train Unit action now listing in the TRAINING tab
- Construction action now listing in the BUILDING tab
- images made for city actions
+ Cleaned up Internal City Resource management
- made it easier to tell what is going on, both code-wise and for display in the UI
- City Details now lists details on how to reach the next level
+ Smarter Caravans
- Only one caravan per city link
- That caravan will drop off goods from the home city, then bring back goods from the destination city...rince, repeat
+ New Resources
- Twilight Bees and Wild Wheat are rare resources can be build upon by a farm but provide more food than a Fertile Ground tile
- Twilight Bees' 'Apiary' improvement added
- Forests can now harvest lumber with a Lumberyard
+ New 'Save Unit Design' dialog
- lets you set up a scene to (eventually) use as that unit's medallion image
- background can be flipped
- stance for the image is used for the pewter pose
+ Map Generation is now Data Driven
- Maps are moving towards a system where all generation options are moddable, right now only the main features are hooked up
- Maps should no longer look like big blobs, but may end up looking like big spiders instead (it's a work in progress)
------------------------------------
- Tweaks -
+ Texture Atlas: Forces generated texture to a smaller size to help with cards that were struggling on startup
+ Research Screen: Time to unlocked milestone changed from PERCENTAGE to TURNS
+ Lowered the speed of units
+ Evil Factions disabled as opponents until we get more of their assets ready
+ Tweaked Tech costs
+ Logrithmic representation of Techs
+ Roads take 5 turns to build per segment
+ Citizens only produce 0.01 research pts (used to produce 0.05 RPs)
+ Iron Deposits visible right away
+ Most 'Negative Treasury' logic implemented, so if you dont have enough gold, you can't build more Cities, Improvements, or Units
+ More Art Assets Implemented for Tech Tree and UI
------------------------------------
- Fixes -
+ City Build Mode: Improvement Icons stay flat to the Terrain (they were floating 50 units above)
+ Grid lists fixed to properly display dangling entries
+ Players History daa gets Saved and Loaded
+ Changed advanced choose faction screen and advanced choose opponent screens to use shorter strings for the filter buttons
+ Various Typos

 

We plan to do an interim update next week to finish out Beta 1B.

I’d say have fun but…well, you know…

…It is time to discuss….DEATH!!!! (or at least combat)

Published on Wednesday, October 21, 2009 By Brad Wardell In Elemental Dev Journals

Starting next Monday, we begin work internally on the Elemental combat system.  It won’t see the light of day for months (tactical combat part anyway).  But this is the place to discuss how you would like it to work.

Right now, a unit has Attack, Defense, Hitpoints, and speed.  It’s very straight forward. When in battle, other factors come into play too (range of attack, height, and cover).

But obviously there are a lot of other factors that could be looked at.  Blunt weapons vs. Cutting weapons for instance.  My personal inclination is to stay away from damage types because they add a lot of complexity without really giving back a lot of fun (in my opinion).  I’m sure there are those who will disagree but we’ll have to agree to disagree there and perhaps damage types can be made something available to modders later.

I would like to see experience be used more than as simply a modifier to attack and defense and HP.  I don’t mean when you train your units (which gives them more HP) but I mean real combat experience causing them to simply be better at combat but we have not yet come up with a way to convey this well in the game.

I would also like to see Mobility be taken into effect somehow in combat.  The Mongols conquered much of the known world because they were strictly a mobile army that could easily outflank their infantry-heavy opponents. How to convey this to players is again, a challenge that would have to be dealt with.

What would you guys like to see?

WindowBlinds 7 gets a new skinning format

Published on Wednesday, October 21, 2009 By Brad Wardell In Personal Computing

image

It’s been several years since WindowBlinds has added a new skinning format.  For those of you who are techies, WindowBlinds has UIS1 and UIS2 (User Interface Specification). 

UIS2 is extremely powerful and lets users go wild with the design. 99% of skins use UIS2.  The downside is that skins are very hard to do (and even harder to do nicely) and there can be compatibility issues with programs that don’t adhere to the GUI conventions of Windows.

UIS1 is a lot less powerful but faster.  The borders and title bar are a fixed size and the title bar buttons can’t be moved. They’re a bit easier to make but still involve quite a bit of work. They have essentially perfect compatibility but most skinners don’t do UIS1 because they’re nearly as hard as UIS2 and and lack the power.

With WindowBlinds 7, a new skinning format gets introduced: UIS0.  The idea here is to make it very very easy to make skins and the skins only apply to Aero (which means for XP users this won’t apply since there’s no Aero to apply to).  Since the Aero design can’t be “touched” skinners can’t really easily hang themselves.

Don’t get me wrong, you CAN make an ugly Aero skin with UIS0.

image

Besides being easier to create UIS0 skins, UIS0 skins are Aero which means that any weird program that makes the assumption that Aero is running will be fine.

image

image  vs. image

The biggest goal, however is to make it a lot easier to make skins again.  Terrific skins like Aero Metal and Aero Midnight (by Vstyler for Stardock Design) are designed to look just like Aero but with metal textures or be pitch black.  It’s just as hard to make those skins (actually even harder since people are going to be comparing it to the default Aero) as any “original” skin.

Now, people who like the Windows Vista/Windows 7 default look but simply want to enhance it in some way can do so with a minimal of fuss.  Textures, colorization, and other new WindowBlinds 7 effects can be applied to Aero just like any other skin.

The beta of this is due out this week for Object Desktop users.

Object Desktop: DesktopX 4

Published on Saturday, October 17, 2009 By Brad Wardell In Object Desktop blogs

It’s been awhile since DesktopX got the kind of love it deserved. And with the new Object Desktop in development, it’s getting some love. 

First, DesktopX is going back to its roots – desktop eXtension.  Specifically, adding objects to the desktop that can be made to do interesting and useful things.

This will have some consequences and opportunities.

On the consequence side, we’re going to pull out features that are rarely used, hard to support, and are just generally not part of the core product.  For example, creating system trays. That was something we hacked in years ago that really shouldn’t have been in there.  In the early days when there was ObjectBar vs. DesktopX there was the desire to have these two programs be all things to all people.  In an age of Windows 2000/XP, we could get away with that.  But with XP/Vista/7, you really can’t, particularly in a world populated with the UAC where many many battles take place that users never see.

On the opportunity side, it sets up DesktopX to support new technologies like WPF (Windows Presentation Foundation). Picture being able to take an object and apply 3D effects to it even if the object itself is static.  There’s a lot of “good stuff” in Windows 7 that we want to make sure DesktopX is positioned to take advantage of.

A big area of change that most people, sadly, won’t notice (though power users might) is the under the cover work to make DesktopX not just work on Windows 7 but actually make use of the “plumbing” of Windows to do things faster, more robustly, and use less memory while doing it.

The target is to have a beta of DesktopX 4 in the next 2 weeks.