Brad Wardell's Blog


Elemental: A preview of the modding

Published on Tuesday, April 20, 2010 By Brad Wardell In Elemental Dev Journals

image

Sometime after July 4th we expect to have the Elemental modding beta.  Modding isn’t something that we plan to work X weeks on and then finish. Rather, the modding budget involves full time Stardock developers assigned to it for the next 18 months.

The modding beta will comprise making available the core tools that modding will need. Namely:

  1. Making your own maps
  2. Making your own creatures
  3. Making your own items
  4. Making your own buildings
  5. Making your own conversations
  6. Packaging and sharing your mods within the game with others

This, however, is only phase 1 of modding. Our current strategy for modding will be to work with active modders to see what sorts of things they need us to expose to modding that we haven’t thought of.

The way things will be exposed (as previously mentioned) will be via Python and XML.  It will be through Python and XML that players will be able to make their own AI, change the economics and balance and eventually create their own games.

I’ve mentioned in past that I plan to take time off after Elemental ships to focus on modding on my own time. I plan to use Elemental to make other games that I’d give away to others to help build up the mod ecosystem and help learn first hand what sorts of engine APIs need to be exposed.  Temple of Apshai and an Ultima IV-style game are things that would be on my list.

The above is a video of Ultima IV.  I am no artist so I would probably stick with that “style” of graphics.

I would imagine other modders would use Elemental to make a literal Master of Magic style remake or what have you.

Is Modding hard?

It depends on how much you want to do.  The key tools are included with Elemental.  The ability to make a map/level and then load it from your mod and load additional maps/levels in  your mod and go back makes it relatively easy for someone to make “dungeons” or have cities be a simple icon that when they go into expands into a full blown city.

The character edtior is obviously a major part as well since you will want to be able to create people and save them.

If you look in your documents\my games\elemental\units you can see your units right there. There is an icons sub directory where the art for your unit is generated as a .PNG.

Tandis_0

This unit is one I made and is just saved as a .PNG that you can use.

And of course, the item and building editors are very important since you’ll want to create your treasures and weapons and rings and potions and what not along with your castles and shops and whatever else.

How does Python and XML fit in?

We picked Python because it’s the modern-age version of BASIC. When my generation learned programming, we did it in BASIC.  Nowadays, it’s ridiculous how much work it takes to get up and going with programming. I tried to get my son into programming and quickly realized that it’s far too much work to do anything.

With Python you get a very easy interpretative language. Easy to learn. By exposing APIs from Kumquat (our game engine that includes the 3D graphics rendering) people can quickly put “stuff” on the map. 

Want to make a mod that’s a new game? You would create your guys with the character engine, the level with the map editor and then use Python to load up the guy and pick which animation you want and run him around based on mouse or keyboard input (all provided by Kumquat).

Our style of XML formatting is kind of old school and we admit it.  We use it not for programming but for data structures. 

If you look in games\data\English you can see how data driven things are (basically everything is stored in XML, no binaries).

In the current betas, there’s no modding allowed because we stream the data from our servers so that we can constantly tweak them without requiring a download.  This will be taken OUT of the final version of the game since we don’t want to require an Internet connection to play the game. But during the beta, it’s a big time saver for us.

Post Release

During the modding beta, we’ll be selecting promising mod projects and assigning development resources to exposing Kumquat APIs (written in C++) to Python so that modders can do interesting things with them.  We think it makes more sense to adapt ourselves to the needs of the modders than for modders to have to adapt to us.

Sorry guys, there will be a beta 1z3

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

Before people groan, progress on Elemental continues across the board besides just the “game” aspect (if there are any developers reading this feel free to explain to non-developers what I mean).

Anyway, Beta 1Z2 that went up yesterday is much better than Z1 was in terms of stability and such but it’s not quite there yet.

Namely, the stuck turns and saved games need to be addressed more.  There are still reports of crashes but memory and stability seem to be adequate to proceed.

I don’t have an exact date of z3 yet but hopefully in the next week or so.

Sorry to be such a stickler here. We’re not trying to be perfectionists. We just want to make sure we produce the best possible game we can.

One other thing to note: Be wary about getting invested in the gameplay. There are already debates on various balance things. While the underpinnings are there, we expect to make a lot of radical changes between now and release.  So if you’re having fun with the beta, please don’t get too attached to anything.

Appreciating good health

Published on Thursday, April 15, 2010 By Brad Wardell In Life Journals

For years I’ve taken to the system of pre-planning my days weeks in advanced. Every waking hour is assigned to something because there’s just too much going on.

This week, I realized that the only way I am able to plan my schedule to such a fine detail is because I have unfailingly good health – at least until this week when I got a cold. In a blog last year, I mentioned I didn’t have to blow my nose until I was 34.

This week, I didn’t get particularly sick (no nose blowing <g>) but it slowed me down enough that I had to take a two half-days at work due to fatigue.

It’s amazing how quickly a schedule can fall apart and how quickly the consequences line up.

two lost half days result in:

1. Having to delay the WinCustomize 2K10 launch a week since I wasn’t there to help with it.

2. Some minor (but expensive) finished carpentry changes because we had moved to an “on the fly” system for finished carpentry on the new house and a desk that was being built into the wall was at chest height instead of sitting height (long story).

3. I had to get an extension on the book I’m writing. The copy editing came back for my review and I just couldn’t get to it.

4. I won’t even get into the email backlog. I haven’t touched that yet.

5. Several enterprise software meetings had to be canceled putting back multiple projects.

6. Had to cancel a couple of design meetings with partners.

7. Absolutely blew the Elemental retail videos I was supposed to do and narrate. Luckily Jason Ocampo is helping me on that but we’ll still lose a week.

8. Failed to evaluate feedback on ObjectDock 2 in order to prioritize development which put the next beta build back probably a solid week.

9. Didn’t spend any time this week with the kids since I was sleeping so much.

10. I would normally do my Spring cleaning of the beehives. I was able to still feed them but I should be tearing them down for the Spring build up and now the weather is going to get bad for a few days.

11. Has to pass off the work on Total Annihilation changes to Jason Ocampo as I was too under the weather to look at the TA uberfix and other mods this week. I normally lurk on TAUniverse but couldn’t this week.

Luckily, thanks to good project management by Scott (Boogiebac), Elemental beta 1Z2 made it out on time. I also was able to work with Chris Taylor on Demigod update focus this week.

But as Thursday comes to a close, I’m fading which means I’m still not back to full power.

I have a new appreciation for those who manage to still work despite having imperfect health. 

One technique I did make use of was taking a stroll outside to recharge. I took some pictures.

---

Pictures from this week…

 

IMG_0295

A view from the edge of the covered pool at the new house.

 

IMG_0302

The pond at Stardock as the sun sets..

IMG_0303

“Stardock Creek”

 

IMG_0304

The Stardock building.

 

IMG_0305

The beehives. I need to take off their Winter wrappings and tear them down (fewer of the boxes) to prepare them for Spring.

 

IMG_0306

Cute bunny. It’s a lot closer to me than it looks in this picture.

 

IMG_0307

Elemental: Destiny Ember original manuscript (yep, the final drafts are Fed Ex’d back and forth on paper, no computer at this point).

Great game intros of all time

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

Elemental Beta 1-Z2 News and Changelog

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

image Beta 1Z2 is scheduled to be released this week (today or tomorrow). The beta will close to new members tomorrow afternoon.

As I mentioned earlier this week, we are committed to releasing the game when we’re happy with it even if it means we have to delay it repeatedly to do so. 

That said, as you can see with this 1 week of progress, there is also good reason to believe that we will still make the 3rd quarter release (if not, it’ll get pushed to 1Q2011).  I currently do think that we’ll likely make the 3rd quarter release if progress continues at the current rate (especially since the whole graphics engine continues to evolve in tandem which, when switched on, will change the perception of how far along the game is).

What’s new since last Friday:

- Elemental 1Z Update Change Log -

* Unit Movement *

+ Fixed bug that would pick invalid destination tiles when leaving a city+ Added check in CancelDestination to fix offcenter object only if not moving in tile (using temp code set to false)
+ Added function CheckNextTile (moved CMoveCheck and set move cost from MOveToTile
+ If MoveToTile is called when the next tile has already been set to the tile being passed in, it just updates FOW instead of checking the tile and setting the position, so that it can be called after animated moving
+ Changed QuickMove to Move and added code for animated movement if the unit is visible
+ Added function MoveAnimated which contains very similar code to AnimateMoveGfx, which was removed.
+ Added cost callback AutoExploreAStarCostCallback for picking good destinations for auto explore
+ AutoExplore now will go through the rest of the tiles in the sector if the first one is not a good destination
+ Added Move cost parameter to CollisionDetection so that when it's in path check mode, it can affect the move cost based on what is in the tile (your own city tiles cost 0)
+ Fixed bug in CollisionDetection where the code was using m_lNextTileX, m_lNextTileY instead of the tile being passed in
+ Added function HitCheckObjects, made from code that used to be at bottom of CollisionDetection
+ Removed parameter bMoveInstantly from SetPositionTile and related code
+ Added check in FindPath to skip leftover moves if the destination is cancelled because it can't create a path
+ Added checks for m_bWaitingForUserResponse in FIndPath
+ Added call to CalcAStarPathToDest under UpdateDirective so that the unit can move immediately after its directive is updated

* Unit Customization *

+ Can now alter the face and eyes of your Sovereign

+ Added a bunch of IsBodyPart checks alongside checks for clothing and hair so that faces are treated as randomized backup items like hair and clothes already are, and so they don't get cleared when the unit type is cleared
+ FillItemList doesn't make a category for the face equipment slot

+ Fixed crash that occurred if CreateTemporarySceneNode failed
+ Fixed bug where items would use custom textures of other items on a character

+ Fixed some T-poses that would show up for female sovereigns (like female children) because of some doubled animations that caused it to access random animations with out of bounds indices

+ New "EYES" material added.
  - This material animates the eyes so they automatically blink
  - Blinking eyes is disabled on info card
  - Blink constants are defined in CharacterGraphic.cpp

* Event List *
+ new tooltips implemented specifically for the Event list...line up over whichever entry triggered it
   - right clicking on certain events will either select the UNIT or CITY the event refers to (still hooping this up for more events, but it should work for the main ones)
   - started converting all the seperate CReportItem classes to just use the core one...the other classes were proving redundant
   - Hit detection improved in the Event list by setting several editfields to be transparent

* Gameplay *

+ Pioneer can not longer build on top of an existing pioneer improvement

+ Removed retreat code

   - Retreat button is now Cancel button, only available to attacker.  Since you no longer move into the tile when attacking, no retreat code is necessary

+ Custom Unit Quotes and Names being auto-generated, picking from a handful of options
   - currently hardcoded...will be converting to the FlavorText system next

+ Turned autosave on by default
+ Fixed bug where ability bonus options weren't actually being applied to factions in the customize faction screen, which manifested itself by clearing all the checkboxes when the race spinner was updated (because of a UI refresh) and obviously not getting any of the ability bonuses
+ Entries used for showing stationed units and subunits in main UI don't show number if the unit has only one troop
+ AI will now check that the items it is using to design unit types are supported by the model of that unit (no more female faces on men), and will make sure that a face is always chosen
+ Fixed bug where auto-upgrading your housing would cut your population level to whatever it was without any housing, because of capping it in the middle of the upgrade.  I've fixed it for now by making sure no UI updates are called that will try to get these values and force the capping to happen, but I don't think this will always work in case some construction code ever needs to just access a resource amount in the city during that in-between time, so I think I'll add something more robust tomorrow.
+ Changed OnConstructionComplete to be called on completed improvements after they've been added to the correct vectors in the city/player, so that when stats are set to dirty they can be accessed anytime and we know they'll be recalculated to the right value

+ City hubs are now taken into account when calculating battle bonuses for stationed units
+ Unstationing or removing multiple units from an army will leave whatever unit was last selected selected, instead of just selecting the first unit in the list

+ City Hub now offers bonuses to stationed units
+ Forge and Granary now have XML tags for improvement requirements
+ Mine and Apiary internal names changed for consistency
+ Town Hall adjusted to give +2 prestige points instead of a percentage
+ Crystal now uses new Icon

+ Fixed issue with quests that required you to escort a unit back to a city not completing (the quest condition tracker was attempting to get said units by calling CWorld::GetUnitByIndex( ) with the unit’s ID, when it should have been using CWorld::GetUnitByID( )).

* UI *

+ Race Logo appear on the Unit Context window for the currently selected unit

+ City Build List: you may now select non-buildable improvements so you can mouseover their stats easier even though you still can't build them.
+Reworked zoom to cursor to zoom in along the vector pointing to the area on the ground where the mouse is pointing, rather than gravitating toward nearby objects. The camera system will need a bit of a rework to make this a little smoother.

+ Recruited champions now correctly show up in the empire tree after a load.

+  Improvements that require previous improvements now have those requirements implemented.  Example: a forge cannot be built until you build an iron ore mine.

+ tweaks to edge scrolling
+ Selecting a unit from the stationed unit list in a city will show the information for that unit

+ Fixed bug where units under fog would occasionally pop in and fade out

* Restarting a Game*

+ Starting a new game from within a game will now "work". Still some issues to be tracked down.

   - Fixing an issue where game modifiers saved their parents, which could cause an issue with reference holding.
   - The game, when uninitializing itself, will now clean up tactical map graphics, and will now properly call ResetWorld on the world.
   - Added a DestroyWorld function to world that clears data when world is deconstructed (as opposted to simply reset).
   - The world will now delete and reinitialize the event center.
   - The world will now add its listener when it is reset.
   - Added an assert to see if a unit was leaking when the world released it.
   - The loop to create champ NPC units and place them on random tiles will no longer run infinitely, and will assert after 100 runs.

* Misc.*

+ Fixed crash caused by adding patchwork armlets and a shield to the same guy (both used the same attachment pt)

+ Fixed bug where using quickstart with your prefs/faction configs set such that you ended up playing one of the core factions, your units would have all white hair and skin

+ CClothIconManager now tracks which icon sets have had icons added/removed since the last update, removing the need for external code to keep track of “dirty” icons.

* Memory *

+ Restructured CClothIconManager to use std::maps for storing tiles, rather than pre-allocated 2D arrays, resulting in a dramatic reduction of the game’s memory footprint. Previously, the cloth icon manager was pre-allocating data for each tile in the map for every active icon type, regardless of whether or not there was actually an icon at that tile. On the Beta 1Z map, which is 128 by 96 tiles and has 47 different cloth icons on it on the start of turn 1, this system would consume nearly 150 megabytes of memory. By switching the cloth icon manager over to using std::maps and only allocating memory for icons that are currently on the map, we save enormous amounts of memory. If you clear the fog of war at the start of the first turn on the
  Beta 1Z map with this new system, it uses roughly 21 kilobytes to represent all the cloth icons on the map, giving us a reduction of Elemental’s memory footprint of nearly 150 megabytes. On larger maps with a greater number of different icons the memory savings will be even more dramatic.

* Balance *

+ Lots of tweaks to costs and benefits on buildings

* Known issues *

There are some pathfinding issues and mountains aren’t showing up in FOW early.

* Is this build ready for beta 2? *

Will have to play the beta version first. Our internal build is, as you can imagine, nothing like what is in the public beta.

* How will I know if it’s ready for beta 2? *

The goal of this build is stability. If it is stable and doesn’t run out of memory then it’s ready.  If it’s unstable (crashes) or runs out of memory on you then it’s not.

Beta 1 is not about game balance. If you’re enjoying beta 1 then we have failed as beta 1 should not be remotely fun (I’m seriously about this guys because if it starts feeling fun it will create unanticipated inertia towards certain game play elements that we may radically change for beta 3 – ask anyone who’s ever been in a beta before, people get really invested in bad game concepts that they get used to).

Stay tuned!

Elemental: Why it’s important to get it right

Published on Tuesday, April 13, 2010 By Brad Wardell In Elemental Dev Journals

LostLibrary First off, we want to thank the users who are publicly supporting us on our regular and intentional delays of the beta process. We appreciate your support.

This blog is mainly targeted at the users who are contacting us privately telling us quit “delaying” or how important it is for the game to be released in August or saying that we’re being too perfectionist.

Let me address those issues with a bit of understanding about Stardock and its motivations.

Stardock is a privately held company. A lot of people don’t understand the significance of that.  So let me walk you through the ramifications of that.

1. Stardock’s success is not determined by the “timely” release of Elemental. Our software is pre-loaded on millions of computers worldwide. Our enterprise group (that makes MyColors and Fences and Object Desktop) is very successful. So we don’t have financial pressure on us to release games early.

2. With the above in mind, the release of other games is not going to be a factor on when we release Elemental. Our goal is to make sure Elemental is a great game and release it only when we think it’s a great game.

3. No reasonable person is going to argue that Elemental is like “Duke Nuken Forever” because there is an open beta program where people can clearly see the game progressing. We are confident that our beta group agrees with us on the pacing we have for the beta.

4. I believe with certainty that most beta testers will agree with me when I say that Elemental is significant in demonstrating what a modern PC-only (i.e. non-portable) strategy game can do.  It is important for us that it be done right and that means taking our time to make sure every step is done correctly.

5. And don’t worry, even when we believe the game is ready for release, there will still be plenty of people arguing that we “rushed it”. So you can rest assured that there will never be unanimous agreement on when it’s “done”.

6. We are trying our best to be responsive to user requests. For instance, we let new beta testers into beta 1Z rather than making them wait until Beta 2.  I just want to reiterate again though that Elemental will NOT be remotely fun until Beta 3. Anyone who tells you the game is fun at this stage should probably seek out help. Elemental beta 1 and 2 are NOT fun. If I discover something fun in Beta 1 and 2 I will endeavor to make sure it’s removed so that people aren’t spending too much time playing the game.

Elemental: Advisors

Published on Tuesday, April 13, 2010 By Brad Wardell In Elemental Dev Journals

Galactic Civilizations II had advisors for the players. The players could query the advisors and it would give advice on what it thought they should do.

Unfortunately, I wrote the advisors in Galactic Civilizations II and my bias was always pretty anti-human so when I say players, I mean the computer players.  Humans did not have access to the advisors. It was always considered an unfortunate necessity that the computer players had to tolerate having humans in their game since humans were the ones who spending money to play it.

In Elemental, the advisors will be back and this time human players will be able to access them for help and advice.  The idea is that, especially early game and for new players, the advisors will offer a means to walk the player through the game.  I very much want to avoid putting in some sort of “tutorial” but rather have a system where players can learn the game by AI driven advisors.