Solar Vengeance 8

In development, this new release will once again target Windows.  An early development screen shot!

iWar II (WinWar II) Production

Here's a sneak peek at iWar II, the successor to WinWar II, and also a sneak peek into my development environment on the Mac.

Over the next few posts I intend to describe different aspects of iWarII game play, and how it's shaping up overall.  In this post I'll focus on production.

Like I envisioned a few weeks (or was it days?) ago, you no longer will simply select what units to produce, click a "build" button, and presto!  Now, you more realistically divide your incoming resources into the different unit types available.  See the list of units along right right, with sliders next to each one?  You use the sliders to control how much of the incoming resources toward producing that unit type.  The little dials next to the sliders show you what percentage of that unit is completed.  If you distribute your resources among several units types, we start getting realistic build times for things like battleships, measured in a few years.  Of course, you can pump all of your resources into a single unit type, in which case said battleship could probably be produced in six months or so, depending on your inflow.

There's a pretty sophisticated resources production engine running under the hood here.  All your zones have a value, which determines how many resources they produce.  The resources are then automatically "shipped" to the closest factory zone.  The farther away the factory zone is, the more resources lost due to shipping inefficiency.  Shipping over sea zones if 5 times as costly as over land zones.  The most beautiful part of all this is that it's completely under the hood, and the player won't need to manage any of it.  However, the players who bother to learn the game will be able to benefit from their knowledge.  For example, prudent players can build factories in other zones to increase their production efficiency.  Of course, these factories themselves are items to produce, so they take some time to build.

Divide and Conquer!

This morning sees the completion of some unit management features of the game.  You can divide units by selecting your force counts with the sliders, or the "Half" button, and then tapping the "Divide" button.  The selected Unit nicely divides into two, and the two new units slowly move a few pixels away from each other.

To re-group, you can click the zone itself, and then tap the "Consolidate" button.  All the like-type units will nicely move into one stack, and merge into single units.

Another thing to notice here is how the Commander of the Army is being reported, just above the mini-map.  Armies will fight at a substantial bonus when they are close to a Commander.  Commanders will also help Armies rally and more quickly overcome fatigue.

My thought have turned to how you will raise new forces in the game.  In older versions you simply selected what you want to build and that was that.  But what if it took a realistic amount of time to build units?  It took 2 to 3 years to build a Battleship during World War II.  For game purposes, maybe I could speed this up to 1 year.  But imagine the tough choices that emerge when you have to plan that far ahead?  Building major units is no longer a snap decision, but something you'd really agonize over.

iWarII Developments

Every day adding a few new zones to the world, tweaking the unit selection and movement, establishing the values of the land zones.  iWarII development has some good momentum!

From the screen shot here a few things about the new release are apparent:

• Each Major Power will begin the game with a number of Commanders, randomly generated.  Commanders provide strong leadership bonuses to land forces.  The closer a land unit is to a Commander, the greater the bonus.
• Commanding your forces will be a simple matter of touching them on the map and dragging them to where you want them to go.  More complicated things, like splitting and combining forces, will be handled via menu buttons.
• We have a fog of war, and zones outside your visibility range are darkened.

I'm quite excited about the random Commanders aspect.  Rather than Montgomery facing off against Rommel in Africa, the UK player might have his Field Marshall Jeans facing off against Gebaumann and his armored units in Algeria, and US General Pello might be tasked with protecting the Philippines against Japanese invasion.  Each Commander will have a number of randomly generated stats that will determine their effectiveness, and capacity to improve.  Commanders will also gain experience over time.  Losing an experienced Commander will thus be a serious setback.  A new Commander will eventually be spawned at your capital to replace the one lost, but they will begin with zero experience.

Getting Apple's Linker to Cooperate

If you came to this entry from a Google search for "cocos2d archive crash doesNotRecognizeSelector", you've come to the right place!  I've just spent the past 2 hours figuring out why my iPad game ran fine for me, but was rejected by the app store due to a crash.

Lesson one: Test your app in Release mode!

Building in Release mode as opposed to Debug mode causes more compiler optimizations to occur, and can reveal unexpected and hard to track down bugs.  You can save yourself alot of trouble by detecting these during your development, before you submit your freshly minted app for approval.

At first I was puzzled by the rejection, since I could not duplicate the error when I clicked the Proceed button.  After some research, I realized I had to put an archived build onto my iPad using iTunes to reproduce the issue.  I did so, and sure enough, a crash after pressing the Proceed button!  I've since learned that just running the app from within Xcode is good enough, as long as you target your Scheme to run in Release instead of Debug mode.

Look at the crash log above.  So, why is the code apparently calling a Selector that it doesn't recognize?

I finally tracked this down to the Linker eliminating the CCGLView class from the build, because it incorrectly thought it wasn't being referenced.  This caused any reference to methods called on CCGLView to throw an exception, doesNotRecognizeSelector.  I'm not completely clear why the Linker came to this conclusion, but I was able to coerce the Linker to include the class by adding one line of code at the start of the CCTextureCache.m method:

[CCGLView class];

This line was enough to convince the Linker to include the class, and the crash no longer occurs in Release mode, and not even in an archived build that I copied to the iPad.

Time to resubmit to the app store!

World Taking Shape

With Solar Vengeance wrapped up and submitted to the iTunes App Store, I've begun working on a version of WinWar II for the iPad.  It only makes sense that I title the App "iWarII" since I've moved from Windows to iOS development.

Treading familiar ground here again by developing my MapSet Editor tool in conjunction with the game itself.  We start with a smattering of zones in Europe and a couple of sea zones, and will build out until the whole world is completed.  This time I built in a nice feature into the MapSet Editor that lets me load reference images to correctly establish the shapes of the nations.

Ideas for game play itself are also brewing.  I want iWarII to be focused on managing your forces, and your commanders.  Each nation will have a number of randomly generated commanders, complete with portrait images and randomly generated, but reasonable sounding, names.  Each commander will be able to issue a number of orders to units in their vicinity, and units will fight more effectively when they are closer to a commander.  Units will fight best when a commander is actually attached to them.

The commanders will represent probably the most important resource in the game, with their limited capacity to issue orders.  You'll have to move and manage them efficiently as you execute your battle plans.

A Tale of New Brains

In the latest incarnation of Solar Vengeance, this time written in Objective C and targeted at the iPad, I'm adding a few new computer Brain opponents to spice up the competition.

The most recently completed Brain is called Maximizar, and tries to get an early jump in resource development by building an early Refinery StarShip.  Refineries are one of three new StarShips types in this version, and they will double the value of any Resources deposited onto them by Freighters.  Once the Resources are at a Refinery.  But Refineries, like BattleStations, can build StarShips themselves.  Also, like BattleStations, they have a fixed value of 6 Engines.  However, Refineries don't have Hull to absorb damage, so they are relatively fragile platforms.

In the new SV, you don't explicitly select which Brains you want to fight.  Rather, you set a "Brain Calibration" level to control how tough you want your opponents to be.  The setting ranges from "Training" (where you go up against instances of Beginner only) to "Easy", "Moderate", "Hard", and  "Extreme", which introduces beat2k's masterpieces of StrategoV (converted by me from his Stratego4 source code) and Organism.  I rated Maximizar a challenge level of "Moderate" on this scale.

Speaking of StrategoV - believe it or not I managed to finally convert the 8,000+ lines of C# code to Objective C after a few false starts, some sweat, and some numb fingers.  Thank god for Search and Replace in Xcode!

The next new Brain I created is named Athenus, and follows a more straightforward play style, using WarShips, Drones, and judicious use of InkSpots and Startillery.  I rated Athenus a "Hard" on the above scale, although it has managed to hold its own even against Stratego5 and Organism.  It's kind of a spiritual successor to Argus (who also appears here, unchanged), but is much tougher.