Medieval Strategy War Game Development Blog - Conquest!

All About User Experience

7/30/2016

Conquest! has always had problems retaining new players and User Experience (UX) has been my primary focus the past month. Part of the issue with retainment is the complexity of the game. This complexity manifested itself with a UX that only diehard fans of the game will dedicate enough time to learn its intricacies.
The UX improvements started with "The Basics", a set of instructions which would display when a player entered a new section for the first time. For example, here is the one for Combat:

"The Basics" can also be reset under the settings menu so players can review them again if necessary. Further improvements included reducing the scrolling when using the in-game chat, including enemy casualties in battle reports, and a better layout for the alliance settings.
This past week, at the urging of a new player named "Jj", I finally got around to adding the movement point and gold costs to most actions. A simple thing to be sure, but one I strangely resisted. Here is an example showing how much it costs to pray for honor:

And here is another which shows how much it costs to quest for your signature troop:

In the past I had resisted adding these to the game for two reasons. First, I wanted the flexibility to change them (which, ironically, I rarely do) without updating the client. Secondly, some of them are calculated and I resisted putting this logic in the client. I didn't say they were good reasons...
A majority of actions now display this information (I can think of 3 which don't; I'm still figuring out how to display the information). Rather than hope for the best or asking around, players now have access to this vital information instantly.
Jj has also been kind enough to create a Tumblr page for Conquest!. This new page, combined with the Wiki that AgedWizard and Deathmagnet have been working on, provide Conquest! with the best documentation it has had in its 23-year history. Thank you!!!
Another addition this week is the ability for players to delete entries from their journal. The journal tracks promotions, establishing/losing kingdoms, markets which are favorable, heroes and artifacts, etc. It is limited to 100 entries and will automatically overwrite older ones, which could lead to the loss of some important information. Players can now manage this better by deleting unwanted entries:

Finally, we introduced new class portraits. The old designs used pictures of the various classes, while the new uses symbols:

I'm working with the designer to add more color and remove ambiguity from the UI. This will be a slow process but I'm excited at the possibilities.

Sign up for the Conquest! mailing list here and follow the journey on Facebook or Twitter. Until next time, I hope to see you in the game.

Conquest! is Live!

7/2/2016

After ~8 months of development and beta, Conquest! is officially live and has already completed 2 Ages! It has been a busy month since I last posted.
The Reddit AMA was a success and generated a huge uptick in users. A big thanks to the Reddit community and Nicholas Laborde from Raconteur Games for helping me get it set up.

Since the go-live I have released an average of 1-2 builds/week. Some have been bug fixes but the majority include enhancements to the user experience. These have included "The Basics", an expanded tutorial-like system of help screens for new players, interactable journal entries, additional jump buttons to quickly navigate to other parts of the UI, updates to the tutorial, and several spelling errors corrected! Here is a shot of one of the new tutorial screens:

Since introducing the first "Basics" pop-up several releases ago, I have noticed a slight uptick in the number of new players completing the tutorial and that was the inspiration for creating eight additional ones.

Some new enhancements to the game include 8 new badges, 2 new artifacts, improved tracking of player statistics (jousts won/lost, naval victories/defeats, etc.), and an overview popup which shows a balance sheet style view of your kingdom:

The community has been growing slowly, with a mix of veterans from the original game returning and new players who have made it past the steep learning curve. The new alliance system, which allows up to 10 players to join together, has been a big help to old and new players alike. It's one of the enhancements to the game I'm most proud of.

In fact, this is probably the biggest lesson I've learned from launch: do not underestimate user experience, especially with a complex game. What seems intuitive or logical to one person (me) may be odd or downright confusing to another. I believe there is a mix of art and science here and I'm still learning it. Thanks to all the beta and current players who have helped make the game better by making suggestions.

Conquest! also has a new wiki page. It was created by a new player, AgedWizard, and has some very good information regarding strategy and tactics. It is located here. AgedWizard and RobinHood are also working on some gameplay videos, which will also help garner interest.

To celebrate the launch, I created a "Build the Realm" giveaway and the winners were announced on June 17th. It was a successful campaign and I intend to create more of them in the future.

Sign up for the Conquest! mailing list here and follow the journey on Facebook or Twitter. Until next time, I hope to see you in the game.

Countdown to Go-Live: ~100 Hours to Go

5/27/2016

In approximately 4 days, Conquest! will be officially released on the Android and iOS stores. I delivered my final builds today, albeit not without some minor bugs, and they are queued up and ready to go. I don't want to take the chance of resubmitting because Monday is a US holiday and I want to release Wednesday @ 8am CST sharp. They are minor formatting issues, so it can wait until the first patch.

I have already created the configuration files for the server which has new names for: Artifact locations (based on some of the great beta testers Conquest! has had), heroes, the secret city, and the secret component. Once the game launches all players will be wiped and it will start with a lone player in the game.

I started a version 2.0 list on the forums, based on work Krees and I have discussed as well as player feedback during the beta. I don't have a timeline for a release; it will largely depend on how well version 1.0 does.

This week saw many changes to the server, some based on my observations during beta. The NPC hordes now scale based on a player's level: 1-3 = 50%, 4-5 = 75%, 6-7 = 100% and 8+ 125%. This should make it easier for new players to establish a footing and makes fighting them much more predictable.

Aeolous cast an Alter-Reality (AR) spell and it was a great test; AR randomly assigns a class and level for all players. Unfortunately, it revealed several issues. All combat broke (formation bug again) but I was able to get that resolved. The larger problem was a flaw in the spell itself. Since promotions are based on percentage of land controlled and AR didn't alter that many people were demoted each season, since they had level 2 or 3 land but were made level 5 or higher. This was not an issue before last year as the game would simply "create" land so you were not demoted.

Now AR only modifies a player's class, levels remain the same. It may not be as interesting as before but it's better than having everyone in a constant state of demotion until they return to the appropriate level.

There were several quality of life improvements as well. I added a push notification for movement points earned every 15 minutes. This was actually very simple and left me wondering why I didn't add it sooner. Additional improvements included a message if you have already promoted this season, transfer all failing mid-way due to insufficient MPs, and adding the level abilities are unlocked to the Book of Skills.

I also removed an odd game mechanic where spies didn't show signature troops. I've long forgotten the original purpose behind this but when you are attacking surprises are never good (the troops are shown when you attack). Similar to fixing the horde size, this should make battles more predictable.

Over changes included overhauling the code for invasions to make it more consistent not only in terms of the movement point cost but also how it works behind the scenes. Originally it was calling the commands for sail, engage, and attack as if the player initiated them. This made for some redundant checks and duplication of code. With the overhaul, the functions are called (not the commands).

To further increase the diversity of the player classes, the odds of success for questing for signature troops and praying at the church is now based on player class. For Barbarians, the odds are affected by the ratio of battles won to battles lost. For Vampires, it is based on the time of day (the closer to midnight the better). All other classes use honor, but to a varying degree (Clerics require more than Mages). Finally, there were changes to many of the in-game messages to make them more consistent.

Overall a very busy and very good week. I'm really looking forward to the next "debut" of Conquest! June 1.

Sign up for the Conquest! mailing list here and follow the journey on Facebook or Twitter. Until next time, I hope to see you in the game.

Countdown to Go-Live: ~3 Weeks to Go

5/13/2016

With major development wrapped up, I've been focusing on fixing nagging issues and bugs prior to the code freeze on May 25th. After the code freeze only critical issues (showstoppers) will be addressed, as I have to allow enough time for my builds to be approved by Apple and Google. There were several additions this week, for both the client and server, so let's dive in.

First up, the inclusion of using the unique identifier provided by Unity to identify devices. When Conquest! was on IRC, the server used the IP address of the player to identify possible duplicates. With WiFi and cellular connectivity, IPs change frequently and are no longer a good indicator of a duplicate. Conquest! has a general rule that only one player is allowed per person and this enhancement will help enforce the rule.

I also added capability to the server to save the last combat report. This report allows players to see the outcome of a battle which occurred when they were offline. The server records all world events to a text file which can be viewed here. This log is rotated at each New Year Season.

Hordes were renamed from "Weak", "Mediocre", "Strong", and "Mighty" to "Small", "Medium", "Large", and "Huge" to better reflect their size (50%, 75%, 100%, 125%). I also capped reinforcements to Small (except when artifacts are used) so they will be more predictable. Player's can view their own reinforcements from the Combat screen and those for other players when spying. I also increased the minimum amount of land each continent will contain when a new age is started. This increases the land players have to control for promotions, since these are based on a percentage of the total land on the continent.

Timezone issues were also addressed. Seasons occur at a player's local time and all log and chat messages are normalized to that timezone. I discovered there was an issue handling DST times, which meant these normalized times were off by an hour. This should now be corrected and the client will also periodically send an update to the server, in case the timezone changes.

Several commands were removed from the server. Most of these were maintenance commands used by owners ("Titans") to show information about the game or other players. The functionality was moved to a single command. I removed the "reprieve" player command, as this information is now displayed when you spy on another player. Finally, I was also able to remove several unused global variables which were hanging around for some reason.

The tutorial was moved from a separate data structure to the player structure. This simplifies the creation and storage of tutorials and also prevents "orphans". The tutorial itself was expanded to include several more hints and information about the game, based on user feedback.

A special thank you to the community at BetaBound.com who have provided exceptional feedback. If you are a developer looking for help I would strongly encourage you to check them out.

Sign up for the Conquest! mailing list here and follow the journey on Facebook or Twitter. Until next time, I hope to see you in the game.

Closing the Gap

4/29/2016

The focus of the past few weeks of work on the client have been twofold: continued cleanup and preview requests.
After overhauling the help, which included adding pictures and improved formatting for the text, there were some typos and inconsistencies which needed to be fixed. Based on feedback, I also expanded some of the messages displayed when the tutorial is active. I will also be adding a button to get back to the tutorial screen at any time (right now it is only accessible once).
Additionally, I started soliciting requests for Conquest! to be previewed. As part of this process, I enlisted help from several members of the Core Labs accelerator program to comment on the viability of the game and to help me craft a concise message.
The next item on my To-Do list is to update the manuals available on the web site. These were thrown together a while back and need to be tightened up and expanded to make them useful. I'll begin this process by looking around for similar online manuals to see what worked (and possibly what didn't).
I re-learned a painful lesson in QA this week, as I released a build without thoroughly testing everything and managed to break the tutorial. At least we are still in Beta.
On the server side, I re-balanced some of the troop types, corrected a few bugs, and make two major changes regarding the breakdown of casualties during battles: first, incoming casualties are spread amongst armies based on the ratio of that army's side to the total fighting. For example, if you have two armies fighting for you and one has 700 troops and the other 300, the larger one will absorb 70% of the casualties. Similarly, when individual troops take casualties the damage will be spread based on the ratio of the troops in that current rank. So if you have 70 Knights and 30 Soldiers in one rank, the Knights will absorb 70% of the damage.
Prior to this change casualties were divided evenly, which didn't make a lot of sense.
I also rebalanced the Ranger class to have food spoilage and reduced the effects of tax rates on food production and birth/death rates.
Follow the journey on Facebook or Twitter. Until next time, I hope to see you in the game.

iOS TestFlight and Improvements to Multi-Platform Support

4/15/2016

This week, I worked on getting an iOS build of Conquest!. I was putting it off until now because I knew there would be some challenges. But I had no idea how difficult the process would be in comparison to building for Android (or even a Mac).
My first stop was Apple's web site, where I paid the $99 to become an iOS app developer (yay!). Building for Android, PC, and even the Mac platform is free. But at least it is good for a year.
My next hurdle was lack of a Mac computer. Apple requires a Mac to compile, sign, and publish iOS builds. Ironically, I can build Mac versions of Conquest! on my Windows PC without this requirement...
After some research online, I rented a Mac from MacInCloud.com. They offered a 24 hour trial period for $.99 and 3 hours of Mac time per day for $20/month. Perfect! I was able to sign up and RDP into my Mac within a few minutes.
When you build for iOS in Unity, it creates an XCODE project, which I had to transfer to my Mac via Dropdown. I created a zip file for the build and noticed it was 500MB, which took several minutes to upload. Since I was in full test mode I didn't want to wait for long upload times so I did a little digging into the project Unity created.
It turns out, that Unity uses IL2CPP as its scripting backend for 64-bit builds (iOS version 8+) and this includes a 1GB library file. Furthermore, I noticed the date/time did not change in between builds, so it seemed like this was just being copied over from a different location. So, I removed this library file from the zip (which dropped to < 90MB) and copied the file back once the project was loaded to Dropbox. As I suspected, it built fine so I could upload the project without long wait times.
Next, I had to request and generate a certificate and create a provisioning profile for the Conquest! app. The Unity web site has some great instructions and with those instructions and Apple's, this turned out to be the least painful part of the process.
After building the project on "my" Mac, I generated an Archive and uploaded the file to the Apple's web site. It should also be noted that the entire process is tightly coupled with your iTunes account.
Apple takes ~15-30 minutes to process each upload. After that time, it is available for internal testers (I seemed to be limited to just one of these). The build is also being reviewed for Beta, which took 1-4 hours each build. This step is crucial because you cannot distribute to external testers until the Beta build is approved.
To Beta test an iOS application, one must install Apple's "TestFlight" app. After installing that application, I was able to download Conquest! onto my iPhone 5s and run it. Whew!
I could not figure out a way to share a link to Conquest! in TestFlight; it appears email distribution is the only way. One nice feature is Apple will notify users when a new build is available. Going into the TestFlight app on your device allows you to download the upgrade.
Unfortunately, I'm not completely out of the woods yet. Apple has reported that Conquest! is over the 100MB download limit. After doing some research, I decided to opt out of a Universal app and only build for iOS 8+ 64 bit devices. This cut over 100MB out of the size.
Furthermore, I discovered that textures in Unity are only compressed when in the dimensions are a power of two (POT) i.e. 512x512, 1024x1024, etc. This warning message is displayed but I never paid much attention to the size of my build since the Android one was ~80MB. Krees and I worked to make all the backgrounds a POT and this reduced the build size by 12MB.
Even with these changes, Conquest! is still ~15MB over. There are more textures we are fixing, which should bring us under the limit. Otherwise I'll have to start removing music.
The other major news this week was an overhaul of certain screens in Unity to make them more platform independent. This was accomplished by working with the anchors on each panel. It took ~8 hours but now Conquest! is playable on almost any device (I still have some work to do for iPads).
Finally, I decided on a general release date for Conquest!: June 1st. This should give me time to finish the remaining cleanup items and allow for plenty of Beta time.
This week in the Core Labs Accelerator program, we learned about successful marketing and PR strategies. Definitely something I've always needed help with!
One important milestone is Conquest! surpassed 100 players for the first time in 10 years. A big "thank you" to all the Beta players. Overall, this has been a great week!
Follow the journey on Facebook or Twitter. Until next time, I hope to see you in the game.

Conquest! Open Beta Begins

4/8/2016

After ~8 months of development, the Conquest! mobile client has finally entered beta! What started as an email from an IRC player ("Hey, wouldn't it be great if Conquest! went mobile...") is now a fully functioning Unity based client! Woot!

This is an important milestone and it would not be possible without the following people: Krisztián Juhász (art and graphical design guru), my understanding wife Amy, and the following folks who offered encouragement, suggestions, and motivation: Steffon Scott, Eric Scott, John Bergin

There is still much work to do as we shift from building features to working on usability. As it stands right now, the client has some major issues in that area.

Conquest! is a complex game with many features and it is easy to get lost or stuck asking "Now What?". Part of this stems from poor marketing; Conquest! is not a single player game with a multi-player option. It is a multiplayer game only. The NPCs in the game do not attack and are only generated "upon request". Finally, getting the word out and finding people who will stick with it (warts and all) is challenging. I'm still targeting a summer release but it will be a busy spring to get the client ready.

Some new items this week include a redesign of the Move Units pop-up, based on beta feedback. Instead of using input boxes we are now using sliders to move troops:

Blue represents the amount of troops in the defense army, red (not shown) the amount in the attacking or campaign army. The two buttons at the top allow for troops to be moved en masse from one army to the other.
Another major project, which took ~8 hours, was going through all the Unity pre-fabs in the game and making sure they are all aligned and positioned the same. I have always used pre-fabs to build UI elements (i.e. I've never instantiated them via code). This is great for a WYSIWYG building experience but means that this validation was quite time consuming (I rarely position items at runtime and there is very little animation in Conquest!).
I also added tips in several more locations to help navigate the world and learn how to play.
Another new feature was adding a filter to the player journal:

The player journal logs milestones of your journey and can grow to multiple pages. The filter allows you to quickly find just what you are looking for (such as artifact locations or heroes).
Finally, Krees and I completed development by adding support for town ownership. I consider this feature "controversial" as it will be difficult to balance. The concept is that once players reach the maximum level for their class, they can purchase a city. This allows them to alter prices, open and close the markets, and even change the name. It has the potential to allow owners to quickly amass large amounts of gold and troops, which could be unbalancing. We will have to keep an eye on this one.
On the server side, the main change was ensuring the signature commands, which used to expire at the top of the next hour regardless of when they were activated, last the full hour. I also continued to shorten messages so they were easier to consume on a mobile client.
In our last two Core Labs sessions we discussed making good game pitches (to publishers or investors) and predicting and taking advantage of future trends.
Follow the journey on Facebook or Twitter. Until next time, I hope to see you in the game.

Alliances, UX cleanup, and battle code updates

3/30/2016

With the completing of class abilities and skills, Krees and I turned our attention to Alliances. In the original version of Conquest!, a player could only ally with one other person (some classes couldn't form alliances at all). While this was fine I recently expanded the concept of alliances to include multiple players and members receive troops each battle (the percentage is based on the size of the alliance). I thought this would only take us 3-4 days; it ended up consuming over a week! There were lots of subtleties, including a list of alliances, searching for an alliance, member rosters, and leader administration. Krees also suggested a new feature, alliance events, which display a running list of events affected the members. We used a similar background for class commands and divided it into two halves:

Members and alliance maintenance are similar. Clicking on an alliance (or member) reveals more information:

We also started some UX cleanup, based on feedback from users. Notably, we increased the font sizes throughout the UI, fixed some scroll issues when opening pop-ups, and centered the map on your location (more on that below). Since I use my PC for testing and an Android tablet for verification, it is sometimes difficult to remember that on smaller devices the font size might be incredibly tiny (and illegible).
Not completely understanding some core Unity concepts, such as world position, I used a "magic number" to approximate the position. I tested it using a variety of screen resolutions and it works out OK but naturally it isn't good to use something without fully comprehending how it is working. If there are any Unity gurus out there who have time to explain to me what is happening I would really appreciate it! My usual source of help, Google, was surprisingly silent on the matter...
On the server side I spent 2 days rewriting major sections of the battle code. Originally I had used some global pointers and static variables and I wanted to remove those constructs. There is no net effect on the outcomes of battles but the old code was "bugging" me and had to be replaced. Just one of those things.
Krees and I are coming to the end of the development cycle. We have just one section remaining, Town Ownership, before moving fully to UX cleanup/prep for launch.
I missed the Core Labs session last week due to a conflict and I have yet to watch the video. It covers building a budget, something I do need help with (although with just a team of two its easy to manage!). Two weeks ago we heard from Oscar Clark from Unity, who gave a really good session on scope creep.
Follow the journey on Facebook or Twitter. Until next time, I hope to see you in the game.

Server Code Cleanups and Player Classes

3/11/2016

Conquest! is a client/server application. The client uses Unity and has been the subject of most of my blogs the past 10 months. I would like to spend most of this post discussing the enhancements to the game server but first let's get the new stuff for the client out of the way.
The big news was completing the new pop-up images and starting on support for player classes. In Conquest!, there are 6 playable classes: Fighter, Barbarian, Mage, Cleric, Ranger, and Vampire. Each class has its own strengths, weaknesses, and playstyle. Classes are an important and large area of the game and are one of the last remaining sections to complete. The design calls for a large tome, which players will page through to view their class abilities and skills. The graphics aren't complete yet but here are the general information and abilities pages:

The skills for each class will follow a similar pattern. I really like this design and am excited to see it 100% complete.
The Conquest! server is written in C and was first created in 1998. It has evolved quite a bit since version 1.0, including enhancements to the communication protocols, game features, and stability. As part of taking Conquest! mobile I have gone back and cleaned up some poorly written code. Part of this cleanup involves the use of a lint program, namely Splint. I recently ran split for each of the source files in Conquest!. While I took comfort in the fact that Splint only identified a few minor bugs it did uncover some less than optimal code. For example, the use of snprintf instead of sprintf and strlcat instead of strncat. Note the former required the install of the libbsd library but this is readily available.
Also new this week was the storing of chat and world event history. When a client connects this information is sent, timestamped to the local timezone. This allows conversations to continue in the event of a disconnect or simply the passage of time. It also allows players to instantly see the last 20 world events without having to visit the web site. The server saves these to a file when it exists so they are persisted between reboots. These features enhance the user experience and help persist the Conquest! world. All told, the code cleanups and chat storage took approximately 8 hours of development over many long nights. Grueling, but worth it.
This week during the Core Labs Accelerator lecture we heard from Jeff Burton, one of the founders of Electronic Arts, who coached us on networking skills. Jeff is one of those people you want to go out to dinner with to hear his stories and I hope to meet him during demo day in Silicon Valley later in the summer.
Follow the journey on Facebook or Twitter. Until next time, I hope to see you in the game.

Weather, New Pop-up Design, and Network Traffic

2/28/2016

Since my last post, Krees and I finally completed the weather graphics. In Conquest!, each continent has weather effects which change hourly and affect food production, the risk of a ship being damaged while sailing, and how troops fight in combat. In the old client, a text description of the weather was sent. For the new client, we wanted to use images to represent the 11 different types of weather. For example, here is what freezing looks like:

This show also shows the new pop-up design, which use color images vs. wood carvings and reduces the size of the scroll area. We are currently in the process of retrofitting some of the existing ones to use the new design, which provides additional variety and color to the 100+ pop-ups currently in Conquest!.
As part of this new design I created a Popup Manager class in Unity to handle existing and future variations. This was a rather large undertaking, as I had spread the code for the pop-ups across all the scenes and it took a couple of days to consolidate it all to one master class. I'm not sure if this helps any with efficiency but it reduced the overall size of the code and makes future changes much more manageable.
This project is my first real foray into true Object Oriented Programming and I'm getting a big dose of on the job training. The code base has gotten better over time and I'm sure I'll continue to make further enhancements prior to launch.
On the server side I made some pretty drastic changes to the communication protocol used by Conquest!. Using Message Analyzer, a free tool from Microsoft which allows you to capture all network traffic, I began looking at how much data is being sent back and forth between the client and server. Conquest! uses an XML based protocol and so has tags such as "Message", "Body", etc. While XML is a great protocol for humans to read and process its wordiness was unnecessary. But rather than switch to a different protocol, such as JSON, I simply shorted all of the tags to 2 characters each and changed "YES/NO" responses to "T/F". These two changes reduced the overall message size by approximately 20%. I also continued my crusade to remove unnecessary messages and reduce existing ones. Unfortunately, these changes complete break the Windows reference client but I stopped making changes to that a while ago.
In the Core Labs program we heard a lecture discussing timelines and have our first deliverable due: a production timeline for each of our games. Fortunately I have worked on many IT projects so I have some experience to draw on.
Follow the journey on Facebook or Twitter. Until next time, I hope to see you in the game.