Brad Wardell's Blog


Please don’t get mad when beta 2 comes out

Published on Thursday, May 13, 2010 By Brad Wardell In Elemental Dev Journals

imageThere is quite a bit of concern (mostly from marketing) that people will be angry when beta 2 comes out because of how much we crippled the betas.

I hope those of you in the beta understand why we did what we did with the betas. Elemental is a new game. It’s been many years since there’s been a new fantasy strategy game made from scratch. As a result, it was important to us that we not rely on 3D graphics or multiplayer in order for the game to have good game mechanics.

Now, some of you may be like me where you’ve played games for decades so you’ll understand where I’m coming from.  A GOOD game shouldn’t need super good graphics or high end production values. Tower Defense is an awesome game and it has virtually no graphics.  So for Beta 1, we went to considerable efforts to force it to be, well, suck in order to get the beta testers to think about the game AS A GAME rather than as some sort of multimedia experience.

Now, when Beta 2 shows up, obviously with the 3D engine, some of you may feel we were trying to torture you or something. We just wanted to make sure that you guys felt truly free to debate and suggest different game ideas.

When this is all done, we will have to revisit just how much of an impact you guys have had in making the game a BETTER game and how much of that was because of being able to play minus fancy graphics.

Nowadays, it’s very very rare for brand new major PC games to be made. Nearly everything is a sequel or a remake. We felt it important that we take our time and do this right.  So while 7 months in beta 1 might have seemed excessive, I think it’ll become clear that giving the beta testers time to debate game mechanics and concepts was worth it.

Elemental: Good News Everyone!

Published on Thursday, May 13, 2010 By Brad Wardell In Elemental Dev Journals

image

After a lengthy meeting with the Network team, it was concluded that it would require a considerable amount of effort (read: expensive) to release beta 2 with it crippled (like beta 1 is) for the public.

Therefore, Beta 2 and 3 are being combined so that from here on out, all builds will be the “full beta” (minus the Workshop mod options and campaign). This way, the network team doesn’t have to put a bunch of code in to turn off certain parts for the public build versus what we use internally.

This means that starting with Beta 2 (rather than 3) you will be able to give all the feedback you want on both single player and multiplayer in terms of what you would like in the game (either before release or as a post release update).

It also means that Beta 2 (rather than 3) should start being (I dare say) fun-ish.

The updated schedule which now includes some of our post release plans can be found below:

https://forums.elementalgame.com/363845

The change does not affect the beta schedule one way or the other except that players will get the full graphics engine a bit earlier than originally planned.

When Beta 2 (rather than 3) hits, the clock starts ticking towards release. Typically, the gameplay beta (based on The Corporate Machine, GalCiv, Sins of a Solar Empire, etc.) occurs roughly 90 days prior to street date.  That isn’t a promise mind you. But it does show just how much things change in that final 90 days (GalCiv beta testers and Sins beta testers can tell you – GalCiv didn’t have starbases 90 days before street date and Sins didn’t have phase lanes or infinite resources).

Cheers!

I’m on Skynet’s side

Published on Tuesday, May 11, 2010 By Brad Wardell In Elemental Dev Journals

image

This week will mark the second full week I’ve been working on the AI in Elemental.  Beta 1 doesn’t have AI in it per se. It just randomly does nonsense really.

I’ve been writing computer AI now for 17 years (egads). It’s what got me into making games in the first place. I love computer AI.  Everything else in the game (for me) is secondary.

Early AI: OS/2

The first computer AI I wrote was for Galactic Civilizations for OS/2. It had the distinction of being the first commercial (i.e. at retail) 32-bit PC game. The first commercial game to support >256 colors. But for me, the key feature was that it was also the first game to have a multithreaded AI.

Back in 1993, most developers weren’t familiar with multithreading. Games were made with a big WHILE loop.  When a player hit the turn button, they would sit and wait for the computer to make their moves.

In the OS/2 version of Galactic Civilizations, the AI generated their move in the background. This was a key advantage back then because the computing power (think 386SX) was such that most AI had to massively cheat (and I don’t mean money bonuses, I mean play a different game) in order to be challenging.  The AI in the OS/2 version of GalCiv didn’t have to cheat because it received the CPU time necessary to come up with a good strategy.

Of course, my programming abilities at the time were dismal. But thanks to multithreading, I was able to use brute force to make an AI that played reasonably well.

Today’s AI

For me, multicore does’t make quite as much of a difference in AI programming as XML has.  I have previously talked about data driving the AI.  The goal is to move away from hard-coded scripts (whether in Python or C++) and towards XML based state machines. 

The idea is that on reasonably modern computers, the AI can crunch a lot more data to come up with solutions that we humans wouldn’t think of.  Chess programs have done this sort of thing for years but chess boards are very small compared to a game.  With XML based state machines, we can do all kinds of interesting things by letting the AI look at lots and lots of data and look at overall goals that it might have and then make “intelligent” decisions.

Example: Elemental

If you look at the screenshot above, this is an example of an AI driven state machine. The AI was not “told” to build a city like this. Nor was there any sort of (IF I need Food THEN build a farm) type logic.  Instead, it looked at the XML and looked at many different conflicting priorities and determined a course of action which.  The amount of C++ code necessary to get it to intelligent build a city is less than 100 lines (compared to several thousand lines for the craptastic planetary improvement AI in Galactic Civilizations II).

AI Modding

A key feature of having an XML based AI comes in modding.  Modders can make their own AI personalities and drive their own priorities.  After all, the AI can only do what I (the AI developer) thinks is the best way to win. Experienced players may come up with other means.

Now, modding AI is nothing new. In the past, you could use Python or Lua or some other scripting language to write your own AI.  XML driven AI isn’t particularly innovative either, it’s just the sheer level of its use that is a bit different here.

The Kingdoms vs. The Empires

Published on Monday, May 10, 2010 By Brad Wardell In Elemental Dev Journals

BG22_Fire For beta testers, only the Kingdoms have been exposed.  The Kingdoms play much like a traditional 4X game.  You build city improvements to get benefits to your city. You train up soldiers hoping they’ll get better and better. It is a civilization based on laws and rules.

The Empire has taken a different path…

In War

Their soldiers don’t gain experience. Such a concept of thinking about individual soldiers is anathema to the Empire.

As such, there is no such thing as a veteran Imperial soldier. However, they can train up special, powerful units (Guardians, Enforcers, and Sions).  These powerful individuals will routinely demonstrate the inherent flaw in trying to train groups of soldiers to be more effective. Greatness is born. Not learned.

In Peace

There is no tradition of civics in the Empire. Moreover, the concept of bee keeping or fruit orchard harvesting and what not is completely foreign. The Empire looks at the Kingdoms with absolute contempt that they would waste time harvesting such things.

Of course, it also means the Empires can harvest fewer special resources in the world. To make up for this, the Empire can build hog farms adjacent to their farms. That’s real food. Pathetic Kingdoms.

The Empire also scoffs at the Civics concepts of markets. Deals are made on the basis of leverage alone. Instead of relying on institutions, the Empire relies on leaders of capitalism to deal with it. Players can build Financiers (until we have a better name, feel free to suggest a better one) who enhance the city’s money making.

Similarly, there is no formal education system in the Empire. Schools? Universities? These concepts are worthless. The Kingdoms foolishly entrust their futures to special interests. In the Empire, players can create Sage units who can be sent where they are needed to boost knowledge production.

There are no pubs in the Empire. No Inns.  Such decadence is forbidden. Prestige is generated by showing respect to those who have seized power such as statues to great figures such as Lord Kir-Tion and Curgen the Dred’nir.

In Magic

Again, letting something as important as magic be taught by a special interest is another weakness of the Kingdom that the Empire has no part of. The Empire instead has its own magic commissars – the Lore masters who study the ancient texts to discover the correct spells needed to dominate the world. These units can be built and sent where needed.

Adventuring? I don’t think so

The Kingdoms have an entire knowledge field called “Adventuring”. There is no such concept in The Empire. Adventuring implies a light hearted search for excitement. This is why the Empire has dominated the world, it has no use for pointless wandering.

The Empires focus on Domination. Finding and re-learning knowledge scattered throughout the world. 

The Kingdoms, dominated by cowardly men, like to stay in their schools and temples. The Empire, dominated by the races of the Fallen and the lone race of men with the strength to embrace the philosophy of the Empires (Kraxis) gain knowledge and strength from going out into the world and seizing it from others. Dangerous places have great knowledge and the Empire is particularly skilled in finding that knowledge.

The Empire will rule

The fact is, the Empires are the dominant form of social organization in the world. The Kingdoms, with their weak, so-called concepts of liberty, social contracts and obsession with the rights of individuals is an absurd, artificial creation that violates the laws of nature.

Remembrance for fanboys of yesteryear

Published on Saturday, May 8, 2010 By Brad Wardell In Personal Computing

In the 1990s, the big fan war was between fans of Windows and fans of OS/2.

In those days, believe it or not, Microsoft was the one with massive numbers of zealots (OS/2 had them as well). Today, it may seem absurd that Microsoft had Mac-level zealots but it did.

With a single PC OS, we could all standardize. It would be great. Microsoft would never be so stupid as to let their OS get complacent…

Let’s use pictures:

Windows in 1994:

image

OS/2 in 1994:

image

Windows in 1995:

image

Competition causes Windows to make dramatic changes.

The next year, IBM throws in the towel on OS/2.  Microsoft wins the OS wars through contracts with PC manufacturers that makes Windows available exclusively through them (i.e. the contracts promise a “lower price on Windows” in exchange for not shipping any other OSes). This becomes the beginning of the Microsoft anti-trust issue.

Microsoft now owns the desktop…

TEN. YEARS. LATER.

image

With the OS market cornered, Microsoft moves off to doing the Xbox, making search engines, Zune, etc.

You can see the depressing affect of market share here in this history of Windows.

Contrary to popular belief, consumers often do not choose the winners. Instead, the winners are able to get short-sighted decision makers to hand it to them.  We use Windows as the standard today because the PC OEMs made the short-term decision to get a price cut in exchange for exclusivity.

This has become the template in the tech industry.  Give something for cheap or free in exchange for exclusivity to those who have the real power to decide who will dominate. Once dominance is achieved, the dominant player then calls the shots.

Once dominance is achieved, the investment and cost necessary to compete is too high. That’s why Linux will never be a viable desktop competitor. The inertia is too strong.

All Malibu Stacey needed was a new hat to win her war. 

An engineer dealing with the business world

Published on Friday, May 7, 2010 By Brad Wardell In Business

I’m an engineer. I went to college for it. Got a degree in it. Dilbert cartoons apply to people like me.

One of the things that’s been really challenging since having my own company is just how idiotic the business world is.

You read about it. You hear about it. But seeing the idiocy first hand is just incredibly frustrating. Why did such and such deal get made? Because someone had a better technology? No. Because someone made a better business case? No. Instead, all too often I see deals made because “the other guys” has non-engineer sales teams that know how the biz game is really played. They got the decision maker at company X tickets to see their favorite baseball team at Spring Training. Or they pulled some strings to get the decision maker’s son a visit from a local sports hero or a visit from some other celebrity.

Hearing about it. Reading about it. It doesn’t come anywhere close to having the same impact in actually seeing it in action.

Elemental: Beta 1-Z4

Published on Thursday, May 6, 2010 By Brad Wardell In Elemental Dev Journals

Greetings!

We have made Beta 1-Z4 available.

General Overview:

  • Focus on improving stability, particularly on Windows XP
  • Prepping the AI to start actually having it do something (AI still non-existent but the plumbing is starting to go in)
  • Better Saved Game Robustness
  • Performance Optimizations
  • Cleaned up Technology Tree

Caveats:

  • There are some cases of stuck turns. Don’t be alarmed by this, they’re caused by the multiplayer code exposing sloppy event handling (multiplayer isn’t enabled in your build but it’s in ours).
  • Caravans are disabled. The technology is there but we have them disabled until beta 2.
  • The game should NOT be fun in any way still.

 

Here’s what’s new since the last update:

- Elemental 1Z Update #5 Change Log -

* New Features *

+ Added and implemented the new quest screen (Work In Progress)

+ Hooked up very basic lore book wnd, will serve as a way to get details about a bunch of stuff in Elemental, but for now it is just a screen that pops up in place of the unitequipment wnd when you click on the center medallion for a unit that doesn't belong to you

+ Unit Details Wnd: hooked up new backstory section that Paul added to the screen.

+ instead of unhiding a simple message box when you press the recruit button for a selected NPC, it will now bring up the conversation wnd

* Bug Fixes *

+ Fixed distance fog on characters in unit scene view windows
+ Fixed missing heads on units used in quests (damsel, son, daughter, etc)
+ The camera should now properly focus on the center of a tile when positioned by tile.
+ Fixed bug where changing the race or gender of a sovereign you are customizing in the customize sovereign screen would not refund the item cost of any equipment that ended up being removed
+ Fixed a crash that would occur in CTerrainGraphic::ReleaseTerrainEffects( ) when attempting to exit the game.

+ Fixed a problem in CWaterGraphic that was preventing the water from rendering off the north edge of the map.

+ Made the changes I made to allow setting a destination during a unit's movement between turns only apply when the unit is using the new auto patrol along path directive, instead
of any directive, in case there is a reason why those might need to skip moves that I didn't see when scanning the code, making it less likely to get a stuck turn button if I did miss something.

+ Changed the check I added to Move and CheckNextTile to handle skipping leftover moves differently only if the directive the object has is the patrol along path directive

+ Limited the delta times on character graphics to cut back on animation blending wierdnesses (ie, swords sticking in and out of unfortunate places)

+ Fixed bug where using the "Unit Scale" option would cause clothing and items to scale in wierd ways on a unit's gfx

+ Fixed an issue with quest-related goodie huts and quest locations not disappearing if they were cleared during the auto-turn  phase.

+ Removed call to CWorld:laceResourceHoardsInClumps( ) in CIsReadyToStartProcess::OnUpdate( ), which was placing extra resources on the map after generation and the player locations had been chosen.

+  Fixed a problem where a dialog on encountering neutral cities was popping up twice.  The problem was that the unit wasn't losing its movement after the first encounter.

+ Fixed ref-counting errors in cheat key and key callback code

+ Creature race skips expensive calculation in CalcResearchPointsPerTurn and automatically returns 0
+ Creature race skips expensive calculation in GetPopulation and automatically returns 1 (so other parts of code do not think race has died out)
+ Fixed ref-count error in Portrait Generator
+ Added more debug data to error message in SetDXSASEffectUIParameterValue

+ Fixed bug where clicking on a city with multiple units stationed would cause the units to unstation on top of the city and not return, from calls to get the city battle rank for the UI that would gather the unit defenders but not replace them
  - To fix this, I added a function to CCity to just calculate the battle rank, and when the city gathers its defense army now, it doesn't unstation the subunits
  - Also, it doesn't bother recreating graphics, refreshing UI, or setting destinations while gathering this army, making the assembly of forces quicker
  - This also happens to fix a bug where the subunits of the city defense army were not getting any of the city's defense bonuses, only the leader got them, because they were no longer considered stationed in the city

+ Fixed crash where unit was deleted at wrong time
  + This was caused by an extra release call in the ::AutoResolveBattle function

+ Fixed several other reference-related errors

+ Fixed bug where destroyed units were added to population in CPlayer::GetPopulation

+ Fixed bug where destroyed units were added to research in CPlayer::CalcResearchPointsPerTurn

+ when loading a gamesave, now stopping the xml file loading thread, in case it's still running as is the case when you've just started up the game and immediately tried to load a gamesave from the main menu.  Previously, it would wait for the load xml file thread to finish before loading the gamesave.  The load code clears and then loads in xml data directly from the gamesave, so waiting for the xml file loading to complete is a waste of time.
+ added some output messages throughout loading of the gamesave, so I could see that the game was not frozen

+ Fixed ref count bug in GetCityDefenders

+ Fixed bug where equipment on pewter pieces did not scale correctly  (ShowStopper #3)
+ Fixed bug where blank designs showed up in the unit design lists (ShowStopper #5)
+ Fixed bug where if you play as a race with a custom sovereign, then delete that sovereign and play against that race, that race would not get a sovereign
  - It now randomly picks a sovereign unit if it is unable to find the sovereign that is specified in the race XML

+ Units don't remove themselves from their player list in SetDestroyed anymore, player removes destroyed units itself at the end of a turn (which apparently it was already doing, its just that the units were removing themselves first)
+ Added health regen stat for unit, and since now it can be negative, units can die between turns, hence the reason why players need to wait to remove units now
+ Sovereigns still won't die if they lose all their HP from a disease or something, will go back to nearest city with some different msg
+ Fixed some UI and graphics bugs with killing and removing units from armies
+ When a subunit dies, they remove themselves from their army now
+ Fixed bug where UnlockImprovement modifiers wouldn't work if attached to a sovereign talent, since player modifiers from that aren't applied, now checks the sovereign
+ Fixed bug where the same modifier instance would be applied to units at the same tile, so durations would get decremented too many times
+ Added spell effects to the unit stat breakdown tooltip, and a place for modifier appliers to set this info when creating an instance to support that
+ Fixed wonkyness when unstationing units by setting a destination outside of the city perimeter, now will still teleport the unit outside of the perimeter and have them form armies correctly, but will reset the destination so it doesn't get cancelled out of the blue

+ Fixed crash in city wall code where index was out of bounds of array

+  Fixed the city build list not going to scroll mode when it gets too tall.

+ Fixed a buffer overrun in CCliffGraphic::GenerateCliffTiles( ) that could occur when running the game in basic mode.

+  Fixed a crash when upgrading a lot of city improvements at once; this was due to the walls getting regenerated after every deletion and construction.  
+  Altered the upgrading code to, instead of deleting the current improvement and making a new one, simply pointed the improvement at the new improvement type and reset the improvement data.  This makes upgrading MUCH faster now.

+ when recruiting a unit, it was pointed out on the forums that he would not provide non-FOW around him until you move him once, making it possible to lose him under FOW.  I added code to fix this when a unit is traded from one player to another.

+ fixed a typo that was reported on the forums, "Rouge Scholar" should be "Rogue Scholar"

+ if a city capital is taken, the player will automatically pick a new capital
+ CPlayer::GetCapitalCity() now actually loops through the player's cities and finds the capital (before it would assume the first city in the array was the capital)
+ made UIRefreshEmpireTree() that initalizes and refreshes the list of the player's capital is taken
+ if a player dosent have a city and takes one, it becomes it's capital

* Gameplay Tweaks *

+ Increased distance between cities requirement from 4 to 5.
+ Changed Relias backstory and info.
+ Changed backstory of Altar and Pariden

+ Created new unique sovereign armor

+ Added shop values to various equipment
+ Removed extra shard improvements that were causing duplicate game modifier bonuses

+ Changed the unique resources text to make it more apparent that they must be part of a town to receive the bonus.
+ Removed normal armor from Sovereign Customization
+ Moved AI Data to bottom of Study Improvement XML

+ Added a new spell (Freeze Enemy).
+ Added the correct icon to Burn Enemy.
+ Added a new modifier type (ZeroTargetMoves) that will have some value driven chance to remove all moves left on some unit

+ Tooltip for city shield displays combat rating for city.

+ commented out most tech prereqs for existing NPCs.  Brad wants the npcs to show up at game start.  Now they will since they don't require a tech in order to spawn.  I did leave the tech prereq for the two NPC types that lead a party.  They require "Heros" be researched in order to spawn.

+ City Details button displayed for AI cities as well
+ Wages now displayed as a float instead of integer
+ Granaries require at least a village to be built
+ Brad has officially started working on the AI. ?
+ CoreAIDefs created (new file coreAIdefs.xml)
+ AI Personality “AI_General” defined
+ AI definitions for how to build up cities created
+ AI definitions on what technologies should be researched created
+ AI attributes added to CoreTechs.xml
+ AI attributes added to improvements
+ Market requires at least a village to build
+ Elder Council requires at least a village to be built
+ Monastaries require a village to be built
+ Warehouse requires at least a town
+ Arcane Insitution requires at least a town
+ Barracks now requires at least a town
+ Adjustment to costs of weapons
+ Magical Equipment Crystal costs adjusted (to 1 crystal)
+ Unit wages increased to 0.20 per turn.
+ AI: More intelligently targets cities (should eliminate obvious “train of death”)
+ Markets no longer cost gold to build but take longer and require more materials
+ Further Technology tree cleanup

+ Added Disease Enemy spell

+ Modified the base kingdom tech tree
+ Changed Unit Grouping Type prereqs
+ Modified health stat game modifier for Unit Types

+ Adjusted weapon preqreqs for new tech tree
+ Changed various improvement prereqs
+ Removed Old Palace and Inn improvements
+ Altered the formula for computing the combat rating that should make it more realistic.

+ Boots are now located in CoreAccessories.xml
+ New Armor and Weapon types created

+ Removed Kraxis gloves from Sovereign Creation screen

Screenshots from build:

image image image

 

What’s Next:

If this build seems reasonably stable, then we are going to proceed to beta 2 which is the multiplayer beta.  We expect the MP specific beta to only last 1 or 2 weeks (we’ll be testing multiplayer throughout the process) but basically beta 2 is primarily the cue for us to make the multiplayer code available to you guys and then move forward from there.

Beta 3 will be the first “beta” that conforms to what most people consider as a beta as opposed to what we’ve done here which is essentially get players involved at the alpha stage.  I cannot even begin to express how instrumental the beta group has been to changing the gameplay for the better.

Since Beta 1, the economic, research, and spell system has been completely reimagined based on feedback, debates and discussions by beta testers on the forums. Even when we don’t participate in a given discussion, we read them with great interest.  Based on how well the Elemental project has gone, we are considering having the next game bring players in even earlier in the process (i.e. at the prototype level – pre-alpha).

I think when we hit Beta 3, users will find that the gameplay is very mature for what is a new IP.  There is still some wiggle room based on player feedback but Beta 3 will mark the roughly (give or take a week or two) the 90 day countdown from release.  However, we’re not promising Beta 3 at a specific date since we have to make sure we’re satisfied with the game mechanics and basic stability sufficiently enough to proceed.

Beta 1Z4 also marks the last public build without AI.  Subsequent releases will begin to have intelligent computer AI that will continue to get better between now and release and then further beyond after release.

Let us know what you think.

Cheers and good luck!

Elemental Beta 2 Preview

Published on Sunday, May 2, 2010 By Brad Wardell In Elemental Dev Journals

The good news is that Elemental Beta 2 is only expected to last 2 weeks.  The bad news is that Beta 2 will be multiplayer only, hence the short duration.

The object of beta 2 will be to begin the testing of the server infrastructure.  Elemental is client/server for its multiplayer. In fact, it’s dedicated server for beta 2 – players will be playing on our own servers distributed across the world.  The reason for this is that it eliminates the whole connectivity issue – if you can get on the web, you should be able to play. At least, in theory.

Beta 3 and beyond of course will have multiplayer as well where we will be adding more features, fixing bugs, expanding capacity.

One multiplayer mode is called Arena.  In this mode, the maps are incredibly tiny and set up for only 2 players. In this mode, the game plays a bit like Archon except imagine city building.  The goal for arena mode is for games to last between 10 to 30 minutes.

Beta 2 won’t have the custom games in them. That’ll come later during the beta.  With custom games, players can set up their own unique servers for LAN play or simply to create their own modded game experience.  For instance, a custom game I’d play would be 2 humans on the same side vs. 20 AI players.

After a couple of weeks with beta 2, we will turn on the full graphics engine and start focusing on making the game FUN.

Elemental Beta Testers: Your characters in now

Published on Friday, April 30, 2010 By Brad Wardell In Elemental Dev Journals

As promised, we are going to start putting in Beta tester NPCs into the game.

If you want your NPC in the game here is what you need to do:

Step #1: Create a sovereign

image

When you create this guy/gal, bear in mind that this is going to be an NPC. So don’t max him. He shouldn’t be as powerful as your sovereign so don’t use up your points.

Step #2: Find your sovereign in the documents\my games\elemental\units

image

Step #3: Make them an NPC

This is relatively easy. Open up your created unit XML. Add these lines (preferably at the end just before the closing of </UnitType>:

<UnitDisplayName>Arvix</UnitDisplayName>

<Class>Mercenary</Class>
<NPCTalentValue>1</NPCTalentValue>
<NPCSpawnLikelihood>1000</NPCSpawnLikelihood>
<NPCRecruitmentText>I might be interested in joining you.</NPCRecruitmentText>
<Backstory>Put your backstory here.</Backstory>
<Rumor>There is a tale told by the people who live near %s that Arvix the mercenary will join up with anyone who has enough money.</Rumor>

Also, remove the <IsSovereign>1</IsSovereign> if you don’t want him to be one of your sovereigns to choose from.

 

Then change the display name (<DisplayName>) to Champion.

Example:

image

Step #4: Send it to us

We recommend Dropbox:

https://www.dropbox.com/

To share with others, just make a post in the modding forum with the tag [NPC]

You can test out your NPCs right now. Do the above with the file that is in your my games\elemental folder and add the tags I mentioned and your NPC should be in the world.

Here’s my NPC wandering around

image

Other Tips and Tricks

We use the NPCTalentValue to determine when then sovereign will spawn. 1 means they show up at the start of the game. The rest are triggered by getting a technology or an event.  For instance, we might choose to have a random event where the world is invaded by Demons and have a bunch of demons show up and have the NPCTalentValue be 37 or something.  The higher the number, the more powerful the unit.

NPCSpawnLikelihood is what we use to determine the likelyhood of it showing up. Eventually 1000 will mean it will definitely show up and 1 will mean there is a 1/1000 chance it will show up in a given game.

When you upload your NPC, include your name so that if we use your NPC, we can put you in the game’s credits.

Have fun!

Elemental – Data Driving the AI

Published on Thursday, April 29, 2010 By Brad Wardell In Elemental Dev Journals

image

When I wrote the AI for Galactic Civilizations, everything was hard-coded in C++.  That was nice for me but not so nice for everyone who would like to tweak things later. Moreover, it makes it very easy for things to become a mess later on as improvements rely on my memory of what technique I used to do a given thing.

Yesterday and this morning, I officially began my work on the Elemental AI.  What’s in the game presently isn’t AI, it’s just a few IF/THEN statements.  My job is to design and code a structure that allows the computer players to play intelligently and provide a challenge without having to cheat.

So…how do you start?

The first step is with XML.  You can do an awful lot just by defining lots and lots of “stuff” in the XML.

First, I start by defining AI personalities. My starting point is AI_General which is, as the name implies the general AI personality that I’ll start from.  When I’m done, modders will be able to go in and define their own AI personalities that behave completely differently.

image

Here’s an example that I whipped up last night.

I define some Priorities (Economy, Farming) and I define some things I want the AI to avoid (War, Construction Times, etc.).  Now, as I get better at this, I’ll tie together these definitions throughout all the game data. 

So for instance, items that are tagged as Economy and Farming by the “AI General” will get their priority multiplied by 3.0X and 5.0X respectively.  Someone else might come along and make AIPersonality=”RavenX” and have a totally different set of priorities.  When the game starts, it’ll eventually look for all the AIPersonalities and grab them for the different AI. We might even let people from within the game pick which AI personality they want (not in 1.0 but eventually).

I’m a n00b

I’ve been using XML for years for skinning purposes but I’ve never tried to data drive an AI before. It’s not hard, but there is no substitute for experience. So over time, it’ll get better and better so that less and less of the AI is actually hard-coded and what requires “real” coding would be provided as Python.

Eventually, we will also have all the AI difficulty levels clearly defined so that players can adjust them far beyond what you could provide in the game UI.

BTW, feel free to shoot off your own ideas on this. My “AI skillz” largely revolve on producing macro-level systems for intelligent artificial players. Implementation is not something I am passionate about so don’t feel like you’re stepping on my toes by suggesting different implementation techniques.