As the new year approaches, we’re starting to look forward to the DesktopX 4 beta.

So what are the goals of it?  Well, to be honest, the goals are pretty modest: Strip out the parts that are difficult to work with and build it back up.

Stripping it down

First off, DesktopX comes with several plugins that I have asked to be removed:

Any plug-in that doesn’t work on Windows 7 with UAC on would be removed.  The existing DesktopX library would be renamed “DesktopX legacy” and only new creations would be supported.

The source code for our plugins would be made public so that the community could take over their development since, unfortunately, there just aren’t enough development resources available these days to work on such things.

If users wanted to use that code to make weather and other types of plugins to make it easier for people to create new gadgets, that would be great.

The Future: Building it up

Instead, what I would like to see would be Python to be adopted as the means to creating “plugins” that DesktopX could then read in.  Essentially, DesktopX scripting would move to Python and away from JScript or VB Script.

You could still use other scripting languages as well but we would move away from VB Script being the default.

Clicking on the “New” Script would open up the user’s default editor associated with DesktopX (preferably a python editor).

For 4.0

But for 4.0, we’re looking to clean it up. Fix long-standing issues and get to a more solid foundation from which to build on with Windows 7 being the focus for future development.

Coming up with crazy new hobbies in your mid-30s provides an interesting challenge.

2007: Radar Detectors / Radio scanning.

2008: Beekeeping.

2009: Dietary Supplements

So looking forward, I have some new hobbies I’m looking at taking up.

1. Bats.  That is, putting up bat houses and such.

2. Gardening. Though more specifically, conservation and natural restoration.

3. Guns.  I’m having a hard time with this one because in the age of video games, guns lose a lot of their interesting aspects (i.e. shooting a target or whatever).

4. Survivalism. There are sites dedicated to discussing what to do when you need to “bug out”.

5. Solar Power.  I subscribe to Home Power magazine. Love the magazine.  When I get into debates with AGW advocates, it becomes pretty obvious that they really don’t understand that solar power, wind, etc. are not viable alternatives.  It’s Oil. Natural Gas. Or Coal. (don’t get me started on Nuclear, it’s a viable alternative in theory but let’s not kid ourselves, it’s impossible to get them built).  But I am a big believer in solar power as a means to help decrease our need for energy.

6. Botany.  I’ve been slowly building up my library of books on plant identification. My wife got me “Weeds of the Northeast” for Christmas this year. 

I’m leaning towards bats for 2010 right now.

I have to say, I really like what Microsoft has done with Office 2010 so far.  Better across the table.

The Outlook update is much welcome (and much needed).

One of the things that amazes me is when programs lack even 128x128 icons.  WindowBlinds and DeskScapes had this boo boo which we are fixing for an update in the next couple weeks.

But Apple’s programs? Really? Shame on Apple for that.

Better late than never!

In part 1, we talked about quests in general.  Now it’s time to get to the heart of the matter.

Step #1: CLASSES of quests

As one player put it, quests have to be broken up into components. Think of these as the building blocks of a quest (or “bricks” as one user put it).

How are quests initiated? Here are the ones that come to mind:

1. Some tiles would contain an object that when a player enters that tile, triggers a quest event. These tiles would appear on both the cloth map and full map. We’ll call these MAJOR quests.

2. Random events. Player hits turn, and there is a chance that a quest opportunity may come to the player without having to do anything. We’ll call these MINOR quests.

3. Some tiles would have objects in them that when the player interacts with them would trigger the quest event. These would only be available on the full map (players will be able to move within a tile without using up a move on the full map because you can zoom in).  We’ll call these INCIDENTAL quests because they won’t have a game-changing effect.

Step #2: MECHANICS of quests

Here we define the building blocks of these quests specifically.

• Timers. Quests must be completed within a certain time limit.
• Satisfying the quest requirements:
• Kill N creatures.
• Find Object O
• Return object X.
• Rescue character Y.
• Perform Action Z.
• Obtain Q of a particular item.
• Collect items A, B, C…G
• Destroy V
• Kill character T
• Rewards / Consequences
• Get Item
• Get Ability
• Get Money
• Get Spell
• Get Access to Area
• Trigger new Quest
• Trigger new Unit(s)
• Assign unit(s) to your side
• Trigger new object on map
• Get Marriage Proposal
• Get Experience
• Participation
• Just the Hero
• Full group hero is in. (i.e. the whole freaking army he’s in)
• Requirements
• Does it require an adventuring technology?

Step #3: EXECUTION of quests

This is where we decide how these should be implemented. There are 3 obvious ways to do tihs.

One way is to simply code these in C++ but that eliminates modding.

Another way is to implement in XML which makes modding very easy but makes it hard for us to add additional quest types we haven’t thought of.

And finally, they could be implemented in a scripting language (Python) which makes it possible to create new quests but harder to mod.

I’m leaning towards combining the latter two.  Python used to script the mechanics with XML used to provide the actual quests.

Step #4: ACTUAL quests

Quest 1: Kill the rats
Type: Incidental
Trigger: On main map, player can zoom in on a city and see a “!” above one of the buildings. Player can then select one of his heroes and take them there which triggers the event.
Content: “Oh please help me, rats are infesting my Inn. If you can kill them, I’ll gladly give you 20 copper. Will you accept?”
Execution: Player is taken to a tactical battle with rats in the Inn. Only the Hero is allowed in.

Quest 2: Rescue Princess Genica
Type: Minor
Trigger/Conent: Upon the beginning of a new turn, a local noble has asked you to save his daughter Genica from a group of marauding bandits who are operating out of the ruins of one of Curgen’s old fortresses to the East.
Requires: Adventuring Level 2.
Execution: On accepting, a fortress is added to the map to the east. Only an army with a hero can attack it. If successful, you have the opportunity to wed Princess Genica.

Quest 3: Recover the Dragon’s egg
Type: Major
Trigger: Dragon icon on the map, when a hero-equipped army intersects tile, triggers event
Content: The Red dragon of Sythia is outraged that a manling has stolen her precious egg. Dragons only have offspring once a century or so. The dragon agrees to join your kingdom if you recover her egg. The egg was stolen by Calorax the Warlock who lives somewhere in the far north in the Pilgen mountains. Sythia does not know where Calorax is exactly but knows that the Witch of the Swamp knows someone who might know.
Execution: On accepting, a hut is added to the map in a swamp nearby.

Quest 3A: Dragon’s egg part 2
Content: Upon reaching the witch, she tells you that she has a map that will take you to Calorax’s lair that she agrees to give you if you bring her the scroll of Poisoned Claws which she knows is near the bottom of the old dungeon of Harpok to the south. She points out that in getting the scroll, you will be able to make use of that spell as well.
Execution: On accepting, the dungeon of Harpok appears on the map.

Quest 3B: Dragon’s egg part 3
Content: Upon entering the dungeon, you discover that a demon that fled to these deep places of the world after the cataclysm has taken refuge there. You can choose to battle the demon or exit and return later. If you battle the demon, the tactical battle screen comes up and you fight it out. If you win, you gain the scroll which you can then return to the witch. Returning to the witch gets you a map which triggers the fortress of Calorax to appear on the map.

Quest 3C: Dragon’s egg part 4
Content: Your army reaches the fortress of Calorax that you must conquer to rescue the egg. If you’re successful, you get the dragon’s egg which, if you return it to the dragon nets you the dragon (or you could sell the dragon’s egg for money elsewhere) who becomes a unit in your army.

 

So these are the kinds of things we’re thinking about.  Please feel free to add to this and discuss.

If you're interested in seeing where things stand, check out this recent journal entry:

https://forums.elementalgame.com/372152

Greetings!

As we reach the end of the year, we can take stock of where we are and where we’re going next.

…our story so far…

About 3 months ago, we released the first “beta” of Elemental. Designed to let players help us mold the game mechanics, the beta has been going very well so far.

Through beta feedback, the economic system for the game has been changed a great deal, streamline and generally put into place something that will be fun, deep but should also keep players from getting bogged down.

Also thanks to beta feedback, we came up with a different technology system that is, ironically, quite similar to what was in Master of Orion 1. This is an area that is proving a wealth of future fun for us as we prepare to create different technology pools for the different factions.

In addition, again thanks to the beta players, the diplomacy system has been heavily modified.  We just released a beta update that includes the basic diplomacy skeleton. There’s litlte content but it allows us to greatly expand up on it over the coming months.

…lessons and trends…

If I were pressed to list what the biggest trend in the beta feedback has been so far it is this: Make sure the game has a soul. 

Nearly all of our changes in Elemental thus far have been to increase the opportunity to inject story and life into the game play. 

…The remainder of beta 1…

So Beta 1 will have at least 3 more updates which will take us well into February.  The good news is that people who pre-order the beta and are currently waiting for Beta 2 will likely get one of the updates because the Impulse team wants to test out the “pre-load” features of Impulse and we lobbied for Elemental to be the test case so we could let some of the people who have been waiting in.

Now, as a reminder, Beta 1 isn’t fun “to play”. It’s less a “game” than it is a public game proto-type.

The screenshot you see above of the beta engine isn’t even in the game yet because we don’t want the game to have to rely on being pretty to be fun.

What’s coming up next are the quests, the magic system, and the dynasty system.  We’re talking to players right now about specific quests they’d like to see.  We’ll have lots of journals on that.

The Magic system should be very fun to work through.  Though, the tactical battles are where I imagine magic duels being the funnest.  Still, being able to morph the land and change it Populous-style should add a layer of strategic depth that will be very fun.

The dynasty system is something we’re all very excited to play around with. I suspect it’ll go through a lot of iterations through the beta as we discover ways to make having characters in the game more fun.

…Beta 2…

This Winter we’ll have Beta 2 which is the multiplayer beta.  Most people will never play multiplayer but we have ulterior motives for having multiplayer – I want to learn how to get good at the game online so that I can incorporate strategies into the single-player AI.

There will be special modes for multiplayer developed (you’ll be able to play them single player) so that there are ways to play Elemental in 30 minutes all the way to 30 weeks depending on the game mode.  But we’ll talk more about that as we get closer.

During Beta 2, the beta team will decide if the game is “fun enough” to move to Beta 3.

Beta 2 will probably last about 2 months. But it may be less or it may be more depending on whether there’s a consensus on the game’s quality at this point.

..Beta 3…

It’ll be in Beta 3 that players will really start to see what Elemental is about.  The way we think of it is that Elemental is a strategy game that exists within a giant role playing game world. 

Beta 3 will be pretty short (i.e. about 1 month).

…Beta 4…

That’s when we start to get into the tactical battles. This will be a major part of the game (And yet totally skippable with auto-resolve for players who aren’t into it).

This beta will still be fairly short though since it’s really all about the tactical battles.  Probably about 6 weeks.

…Beta 5…

This will be the polish beta and ironically, this will be the first beta that would be considered a “true” beta. The previous betas could have been considered alpha builds because it’s only in Beta 5 that the game is “feature complete”.  Beta 5 will start getting people into modding the game and getitng us to expose more and more of the engine.

I don’t know how long Beta 5 will take. Probably a solid month.

…other notes from the field…

As some of you are aware, we are hoping to do a 64-bit version of Elemental.  The main hold up is Intel’s Havok as we are using it for the animation (we don’t use the physics in it).  Intel has just released a 64-bit version of Havok so we have to see what is involved in getting it. We’ll let you know how that goes.

We will probably make some of the editor features available to beta testers before Beta 1 is over. At least the map maker. If not it’ll be during beta 2.

Like every Stardock developed game, Elemental’s multiplayer will be client/server.  And in fact, our plan is to set up servers across the world that people can join.

However, we also plan to make it so that people can set up their own servers with their own mods, rules, and such for their friends to play or for others to join.  We did this with Stellar Frontier years ago and it worked out fantastically. People would make their own modded star systems with their own races and ships and planets.  Plus, it lets someone set up a LAN game for their friends.

Stellar Frontier allowed users to set up their own servers and mods. This screenshot was the Master of Orion 2 mod for Stellar Frontier. A user could create their own star system and others could join in and play with their mods. This is similar with what we’re going with in Elemental except people would set up their own worlds. 

This upcoming year is going to be really exciting!

Merry Christmas and Happy New Years!

Demigod is close to celebrating its first Christmas.  It’s been an exciting year for its community and for the game itself.

Developer Gas Powered Games has sent us a new Demigod build that has some tweaks to Oculus that we had requested. He won’t make it to the general public until after we get back from the holidays. The QA team have been just swamped with new stuff to test out (they play video games for a living, the bums!).

We expect to begin the new year with a bang with the release of Oculus.

Demigod 2010

So what will be happening during the next year for Demigod players? Demigod, being a Stardock published game, will continue to evolve this next year. Let’s talk about a few of the things we’re planning.

Clan Wars

The Clan Wars feature was originally going to be something that we done sooner rather than later. Instead, it was decided we’d improve the in-game overlay and get modding support in sooner rather than later. We’ll talk about modding in a minute but let’s talk about the clan system first.

Now, the first thing to understand is that a lot of these features will be coming via Impulse Reactor.  The idea is to put together an SDK that will allow game developers to easily add their own achievements, clan support, account info, etc.  Demigod will benefit from these new features.

The way it’ll work is that players will be able to join a clan and each can will gain points when one of their members wins.  That’s the first stage which is obviously pretty easy to do.  The more challenging stage is something we hope to develop for Elemental that will be brought back to Demigod where users will be able to essentially set up entire games through the overlay bypassing the existing Demigod lobby so that we can keep adding new types of match-making and game modes without having to interrupt GPG’s development schedule (GPG is working on Supreme Commander 2 right now).

Modding

There’s already some pretty good balance mods being made for Demigod that sound interesting.  We’re going to create a modding library early in the New Year so that it’s easier to find and download mods made by the community.

I know one of the personal things I am hoping we can get in are some additional maps but we’ll have to see what is possible.  There’s a few of the bigger maps that I’d love to see chopped down for more intensive 3 on 3 play but that’s just me.

More Balancing

We do plan to continue to enhance Demigod itself. We’d like to see the Queen of Thorns get a bit more love. She’s a powerful demigod in the right hands but in the wrong hands, she can become an online “feeder”.

Some quick thoughts on Multiplayer

Those of you in the beta for Impulse: Ready to Play and making good use of it already know this but it’s worth repeating often: Playing online with strangers is always a crapshoot. That’s one of the reasons why so few people actually play online.  Hard-core gamers like myself play online because we like the challenge but it also means we spend a lot of frustrated time online.

What we can do is try to make it easier for people to get games together and that’s going to be one of our major focuses for this next year on the multiplayer front. 

Hope you have a great new year

As for myself, I know I’ve enjoyed this past year a great deal with the Demigod community. There have been times where it’s been hard for all of us, especially when the game released but overall, one of my favorite things about Demigod is its online community.

So no matter where in the world you are, we hope you have a Merry Christmas and Happy New Year!

Cheers!

 

Greetings!  Today we’ll be released Elemental BETA 1D to the beta team.  For those of you not in the beta don’t worry, you’re not missing out on anything. I can assure you that the game will still cause horrible disfigurement if played.

The big thing about the diplomacy engine in Elemental is that it’s live rather than video ala GalCiv or most other games of this type. This means that we can have in-depth conversations with other characters in the game that have their own body language and such.

What we have in now is very basic and needs a lot of work still (and a lot lot more content) but at least shows the direction we’re starting to go there.

There’s a number of cosmetic changes in this build as well that you’ll begin to see crop up here and there.

This build should be available to the public this evening.

 

Below is our pruned change log:

- Elemental 1D Change Log -

***********************************************

** New Features **

- Diplomacy Screen Overhaul -

Overview: The Diplomacy screen should now feel more like a 2-way conversation with whomever you're chatting with (opposed to a series of 'soul-less' buttons).  Treaties and underlying data formats cleaned up as well.

+ Changes to DiplomacyButtonEntryWnd.h/cpp
+ Stripped out most of the enums because we're not using those buttons anymore
+ Added enums for left/right add buttons
+ Added member m_ulButtonID
+ Left/right buttons call AddSelectedItemsToOffer
+ Added DiplomacyConversationListEntry.h/cpp/dxpack
+ Options for conversation like "I want to talk about treaties"

+ Removed DIplomacyScrollItemEnryWnd.dxpack (replaced by DiplomacyScrollItemEntryWnd.dxpack)

+ Changes to DiplomacySCrollItemEntryWnd.cpp
+ Added code to handle treaty types
+ Added image

+ Added DiplomacyTradeListEntry.h/cpp
+ Entries for the items you're offering

+ Removed DiplomacyInfoEntryWnd.h/cpp

+ Removed DiplomacyTreatyEntryWnd.h/cpp/dxpack

+ Added DiplomacyValueEntryWNd.h/cpp/dxpack
+ Used for listing Diplomacy value

+ Changes to DiplomacyWnd.h/cpp
+ Added enum DIplomacyResponses
+ Removed m_pMainbuttonList
+ Added m_pConversationList // for dialog on menu, when picking what to choose
+ Added m_pResponsesList // for accepting/rejecting
+ Added m_pTradeListLeft and m_pTradeListRight, for listing offers
+ Removed m_pMainStatBar
+ Added m_pTradeContainer
+ Added m_pConversationContainer
+ Added m_pLocalPlayerOffer
+ Added m_pOtherPlayerOffer
+ Changed SetConversationTopic to take a LPCTSTR
+ Added function FillListWithTreaties
+ Removed function FillTreatiesList
+ Removed function SHowCivilizationList
+ Removed function ShowWarefareInfo
+ Removed function SHowMagicInfo
+ Added function AddSelectedItemsToOffer
+ Added function Exit

+ Changes to Player.h and PlayerDiplomacy.cpp
+ Uncommented AddTreatyWithPlayer
+ Commented out AddTreaty

+ Added TradeOffer.h/cpp
+ Class that handles trade offers, so that we can eventually pass them into the tradewnd from the AI or multiplayer opponents

+ Changes to Treaties.h/cpp
+ Added support for an image to be associated with a treaty type

+ Changes to DiplomacyWnd

-> Added default text for conversation dialogs
-> Added code to clear trade offer when calling Clear
-> Added code to make description for treaty that uses treaty values

+ Changes to Treaties
-> CTreatyType: Added m_strTreatyValueDescription - use string replacement mapper to place values and player names
-> Added m_strUnits - units the value uses
-> Added m_strSingleUnit - singular form of the units
-> CTreaty: Added function GenerateTreatyValueString to get the treaty's value as a string with the units

+ Wartime messages hooked up to Diplomacy Window
-> Wrote new text entries
-> tweak FlavorText selection to factor 'Relations' into scoring

- New Terrain Types -

Overview: Swamps, deserts, and hills now display as terrain types on the map. These have their own movement cost and will eventually provide various city resource bonuses and penalties.

+ Added three new terrain types: desert (previously was an environment, and it still exists in the game, but isn’t placed in map generation), swamp (also used to be an environment) and hills. All of them are in the land terrain category, and are placed on the map during generation.

+ Added a new class derived from CSelectableObject: CTerrainClothMapObject, which functions likes a generic version of CForest  or CMountain, and allows us to place cloth map icons for various types of terrain, such as the three mentioned above. Desert  and swamp both have the own set of cloth map icons. For the moment, hills use the desert icons, hue-shifted to green.

+ Land terrain types with a MapGenPlaceChance of zero will no longer be placed during map generation.

+ Tweaked map generation to place slightly more swamp/desert/hills on the map.

+ Terrain cloth map objects placed on the map will no longer show up as “mountain” when selected in debug mode.

- City Wall Improvements and Seige Equipment -

Overview: Certain techs in the Military tech field will unlock City Wall Improvements. When placed in a city, these walls provide a considerable bonus to defending units. Walls can be destroyed in battle by siege equipment, which is currently limited to the meager Battering Ram.  You need a 'Siege Workshop' to build siege items.

+ City Improvements in Battle
-> bonuses given, calculated using local data within the BattleEngine
-> Decrementing Bonuses the moment the improvment is destroyed
-> BattleFinalHPData storing Improvements
-> Improvements storing in BattleResults
-> Added DESTROY() to Improvement class
-> Got Destroyed on main map if Destroyed in Battle
+ Battle Report Details Listing
-> Set Text of 'Details' tab
-> Made new class for Details, added to parent window
-> storing hits and improvement damage for battles in results class
-> showing above text on battle report dtails tab

+ Added "SpecialBuildingType" tag to CImprovementType, which is just some string denoting a category it is in
-> Gave siege workshop "SiegeBuilding" category to demonstrate
+ Added prereq type "BuildingRequirement," which is a city-target prereq that is satisfied if the city has an improvement of the attribute type
built
-> Gave battering ram item "SiegeBuilding" prereq to demonstrate
+ In train unit wnd, unit types that can't be trained aren't disabled anymore (though they look different); instead, if you try to train them, it
pops up a message box saying why they can't be trained

+ City Modifier: 'DefendingUnitBonus'
    - StrValue: Stat that gets adjusted
    - Value: Percentage change to above stat
    - Operator: + (Add), x or * (Multiply), % (Percentage)...these need to be hooked up throughout the modifier code for cleanliness
    - DefendingBonuses stored in CCity, recalculated properly
    - CCity now has map for...
        - m_mapfStationedUnitBonus_Addititve
        - m_mapfStationedUnitBonus_Multiply
        - m_mapfStationedUnitBonus_PercentGain
+ Added Improvement function 'CalcGameModifierValues' that gets the ADDITITIVE, MULTIPLIER, and PERCENTAGE GAIN values for a given ModType, Attribute, and StrName

***********************************************

** Additional Features and Improvements **

- 'New Technology' Details window -

+ Implemented the New Tech window, which pops up after selecting a technology breakthrough, and displays data about the technology you selected.

- Smarter AI -

+ UnitType .h/.cpp
-> added AILoad() and AISave(), which are minimalist functions that save/load just enough info for an AI to recreate a unit type they designed.
+ RallyPoint .h/.cpp
-> added save/load functions
+ Player .h/.cpp
-> added GetRallyPoint(x,y) function
-> now saving and loading player rally points
-> IsRallyPoint(x,y) now uses GetRallyPoint() instead of searching on it's own
+ MobileGameObject.cpp
-> if a directive has to be canceled, the message box that tells the local user now only pops up if they owned the unit in question.
+ City .h/.cpp
-> removed a note to myself to add m_pRallyPoint to save/load code
-> now saving/loading m_pRallyPoint
+ AiBasic.cpp
-> now saving and loading minimal data about the designed unit types
-> turned the designing of units back on
-> made it so AI units will not attack enemies with a higher battle rank
-> now researching Civilization at first
-> when picking breakthoughs, AI will pick the one with the lowest rarity, else a random one as before.  Also only rolls the 50% chance to change categories if it had to choose a random breakthrough (ie. they all had 100% rarity)

- added save and load functions to handle the few things (so far) that AIBasic has that don't come from the player class
- updated AiIsCityProperlyDefendedWithOutMe(pCity, pUnit) to return if pCity->GetStationedUnitCount() > 1, on Scott's request, so that AI cities will leave themselves defended and not just send all their guys out in the wild
+ AISkeleton .h/.cpp
- added pure virtual function AICalcShouldAcceptPeaceWithPlayerID()
+ AICreature.h
- made AICalcShouldAcceptPeaceWithPlayerID() just return FALSE
+ AIBasic .h/.cpp
- made AICalcShouldAcceptPeaceWithPlayerID() just return true for now.  Left a pragma about needing logic
- fixed a bug that was causing AI units to not form armies
+ City .h/.cpp
- added CalcSumBattleRankOfDefenders(), so I can use it when looking for the least defended city when I can't find any that are simply undefended.  I sums up the battle rank of all the units stationed in the city
+ Unit.cpp
- wrote the implementation of the AIFindNearestLeastDefendedCity() that I definded earlier.  it goes through all cities the player knows about, and finds the one that is the least defended, that is, has the lowest battle rank of defenders.  in the case of a tie, it will find the closest city out of the tied cities to find the one nearest to the unit.

+ added several functions that I found useful
  ----FindAndSetAttackDest()
  ----AICityFinished()
  ----AIIsCityProperlyDefendedWithoutMe()
  ----AIUnitTrained()
  ----AIArmyUpdated()
  ----AIIsArmyStrongEnoughForOffense()

+ fixed AiGetNumberofUndefendedCitiesWithinRange() to ignore cities they own
+ Found lots of places I could use a wrapper funcition I created instead of using the same code all over the place. yay for re-usability

- Autosaving -

+ changed default turns until auto save from 1 to 5.
+ OptionsWnd.cpp
- added an option to turn on/off auto saving
- added an option to set how many turns go by before an autosave occurs.  for now, slider is 0 to 25 turns
- these options are saved and loaded from prefs.ini under "AutoSave" and "AutoSaveTurns"
- these options are also stored in g_pGameOptions under GAME_OPTION_AUTOSAVE and GAME_OPTION_AUTOSAVE_TURNS
- now calling g_pSaveGameManger->SaveGame() instead of dealing with a gamesave directly
+ elemental.str
- added strings for "Enable Auto Save" and "Turns Until Auto Save"
- added a string for the name of a QuickSave file, "QuickSave"
+ ElementalDefs.h
- added GAME_OPTION_AUTOSAVE and GAME_OPTION_AUTOSAVE_TURNS
+ World .h/.cpp
- added m_ulTurnNumOfLastAutoSave, to be used to keep track of when we need to perform an autosave again
- set m_ulTurnNumOfLastAutoSave = 1 in ctr, and in ClearData()
+ World_SavingLoading.cpp
- now saving and loading m_ulTurnNumOfLastAutoSave right after m_ulTurnNum

+ Gameplay.cpp
- in EndTurn(), at the end, right after the turn is incremented, added a check to see if auto save is enabled,
   and if it's been enough turns.  If so, an AutoSave is performed using the saveGameManager
+ Elemental .h/.cpp
- added wrapper functions that I needed to set function pointers of the SaveGameManger.  The wrapper functions are
---BOOL Load(szFileName)
---BOOL Save(szFileName)
---VOID AddSaveGameFileToList(LPCTSTR szDirectory, LPCTSTR szFileName, LPCTSTR szTimeStamp, SYSTEMTIME GameTimeStamp, LPCTSTR szFullPath);
+ Made Player save and load functions virtual so I could override them in AIBasic
+added AutoSave and AutoSaveTurns options
+ set string for save game manager quickSave string
+set save and load function pointers for save game manager
+ ElementalUI .h/.cpp
- added a key combo for quick save.  it's CTRL + S.
- quick save key combo uses the save game manager to call it's new QuickSave() function
- changed the cheat key for CTRL+S to be CTRL+SHIFT+S instead, because it was absorbing the QuickSave key combo and
   preventing it from working
- added a debug.err string so that when the cheat key callback is hit with a key combo, it prints a string to the debug.err
   about what key combo it was.  I did this because I know in gc2 we had people say that the game was calling them cheaters
   when they didnt cheat.  now, the debug should tell us what key is causing the flag to be set.
+ LoadWnd .h/.cpp
- created a new function to add game save entries to the wnd, so that the save game manager can call the wrapper function
   I made for it by using a function pointer
- fixed bug with disabled buttons when they shouldn't be disabled.
- FillWithGameSaveFiles() now uses the save game manager instead of dealing with game saves manually

- First Time Greetings -

+ added first time unit greetings 'FirstContact'
+ Conversation window smarter about filling responses (possible responses set in
message data)

- Grouping Types and Troop Quality -

+ Added some new techs for unlocking the different unit grouping types, which were waiting for techs that didn't exist

- New Troop Training Wnd -

+ Fixed bug where training a unit or otherwise selecting the same city again in train unit mode would put the game in an infinite loop
+ Now need to know about a city (which I made mean having seen knowing about any improvement belonging to that city) before you can build a road to it
+ Selecting anything other than a city in train unit mode will hide the train unit wnd
+ Reduced the number of times the training wnd is refreshed unnecessarily

+ Fixed bug where you could select cities you don't own in training mode and start training people in them

- City Building -
+ Added a check inside ConstructImprovement() that calls TestImprovementConstruction() just before attempting to construct.  This affects both the AI and the human players.
+  Made a slight change to IsTileBuildable() that was preventing players from building four-subtile improvements on partially-used tiles even when the position was valid.

+  Put in a test to ensure that city hubs cannot be created on forests or mountains (the computer was building cities in forests before).

+ Added lists to hold discovered buildable subtile patterns
+ Added the BuildAllowedSubTiles() function to fill these lists with buildable subtiles based on the currently selected improvement.
+ Altered UpdateGraphics() to use the new buildable subtile lists when drawing subtiles.  Also changed the code to only draw greeen (allowed) subtiles - no more green, yellow or red.
+ Added code in SetCityConstructionImprovement( ) to call BuildAllowedSubTiles() and update the graphics accordingly.

- Misc -

+ Civilization Image displaying in Intro Wnd
+ Fixed bug where moves and sight stats were adding up for armies and grouped troops
+ Info card and info note positioning behavior now matches the train unit wnd, repositioning to the bottom of the screen if the screen is wide
enough, otherwise staying above the main UI bar
+ Train unit wnd crash fix

+ Fixed bug where destroying a hut or anything that provides a population storage bonus wouldn't remove the bonus
+ And, in the process, made resource storage more like the rest of the resource system by having the city pull information about resource storage from the improvements, instead of storing game modifiers (or nothing, as was the case with this bug)
+ Replaced a lot of message box images with medallions of the objects they pertain to, instead
+ A little cleanup to the train unit wnd

+ Hooked up new message boxes
+ Added "pts" back to the unit design wnd training and equipment points display, though it's too long and cuts off

+ SelectNothing function in main game wnd now deselects cities

+ The number of rivers that are generated on a map is now based on a range, drawn from the MapStyle XML (with the tags being NumRiversMin and NumRiversMax). Previously, the number of rivers had been hard-coded to 5, and then, for some reason, divided by 3 just before generation, resulting in (at most) one river per map.

+ Research 'possible breakthrough' entry Tweaked to use colorizing bg, image slot

+ Added Mana, Research Points and Spell Points to the stats that are tracked by the history log, and displayed in the graph. The  research and spell point graphs will look roughly the same, as they’ve both based off of population, unless you build an   improvement that boosts research (currently there are no structures that boost spell point production). Mana is simply the   tally of all mana types each player’s sovereign has.

+ Modified CHistoryLog and CHistoryLogEntry to store data as floats instead of longs.

+ Modified CHistoryLogEntry to be able to display plateaus (previously, if there was a period of time where a stat leveled off,   it would only record the start of that period; now it records both the start and end of the period).

+ Added "AllowedPerCity" and "AllowedPerGame" tags to CImprovementType, which just restrict the number of improvements of this type that can be
around at one time in the entire world or any given city, respectively
+ Cleaned up some build list updating to show restrictions/newly available improvements at the right time
+ The edges of the cloth map now extend out beyond the limits of the camera’s vision, so there is no longer an abrupt edge into darkness.

+ The brightness of the cloth map fog of war texture can be adjusted in the game options, with the bottom end of the scale rendering the fog as complete blackness.

+ Cleaned up the terrain shader code, fixing a number of warnings, and removing deprecated variables and functionality.

+ Fixed bug with caravans freezing every once it a while (which, from what I have been able to reproduce, was caused when the AI
declared war on the player)
+ The only thing is, I think that AI declaring war is relatively new, while people having sporadic caravan freezes is not.

+ Can cancel city building from the "name your city" dialog
+ Message box saying you can research stuff after building your first city pops up before the tech wnd, and only after pressing ok does the tech wnd unhide (so, for now, the users know that the stall after building is from bringing up a screen)

***********************************************

** Engine Tweaks **

- Flavor Text System -
+ FlavorText string vector now clears in constructor
+ REPLIES held in flavor text, read in through XML
+ Conversation Window working with new response system
+ Other flavor text updated to use new responses

- Data-Driven Stats -

+ Stat Icons made
    - Sight, Combat Speed, Structural Attack

+ Sovereigns can't see as far into the FOW
+ Unit Stats Types XML Implemented
    - added file 'CoreUnitTypes.xml'
    - Unit Stat Types class made
    - Display Name, Icon, Description read in from XML
    - Display names, icons used in the various screens that display stats
        - Training Popup
        - Unit Design Window and List
        - Save Unit Infocard
        - Unit Context and Infocard
    - Helper functions to easilly grab that info with jsut one line of code   
+ Unit Levels Using a map
    - stats hooked up to a map in Unit Levels
    - interpolating stat values working with map
    - Update COPY CONSTRUCTOR to use the map
+ Unit Stats using a Map
    - Armor and Equipment Stat Modifiers using STAT NAMES, not IDs
+ Weapons, Armor, and Equipment properly sorting in Unit Design
    - using STAT STRINGS to sort, not IDs

- Multiplayer -

+ started adding NO_GFX and NO_SFX defs for elemental multiplayer server

+ Added project ElementalServer, which will not include any graphics code
+ Added folder server for server specific code

- Misc -

+ Changes to TechManager.h/cpp
-> Added function GetTechCategory that will return the tech category of the specified tech without needing to get a pointer (and a ref) to it
-> Optimized function GetTechDef

+ Changed K_ xml files to fix the scaling issue with pedestrians/guards

+ LOTS MEMORY LEAK FIXES (Memory Inspector prev showed over 4000 leaks after starting up title screen and closing, now shows only 6)
+ XML Data Parser and Data Def Objects Cleaned-up
  + CreateDef functions no longer add the object to the parent
  + AddDef now takes care of adding the object to the parent for ALL CDataDefObject classes
  + AddDef functions that do not add anything now return FALSE
  + Removed "hack" for adding an extra reference to objects that are children of another object
+ Fixed "Circular References" on objects that caused them to leak
  + If A has a ref to B and B has a ref to A, BOTH refs must be released
  + This is done by calling a clear function of B (which releases A) before releasing A yourself
+ Removed extra refs for lots of things (see detailed log)
+ Added missing releases for lots of things (see detailed log)
+ Added missing call to Clear function in destructor of several data objects
+ Added missing calls to unload functions for XML data objects in GameUninitialize