When Conquest! was first developed in 1993, it used a very simple model to exchange data between the server and players. A player would send a command and the server would reply with an appropriate response. If a player needed additional information, they would issue another command to retrieve it. This worked well for a text-based UI.

When the UI was developed in 2016, essentially the same model was used. However, it quickly became apparent that additional information was needed to update the UI. Therefore, after a player issued a command and the server sent the initial response, the client would send additional commands to the server to retrieve the rest of the information. For example, consider this sequence:

1. Player sends Buy
2. Server sends Response
3. Client Sends Person
4. Server sends Person
5. Client Sends Review
6. Server sends Review
7. Client Sends Market
8. Server Sends Market

This solved the issue of missing ancillary information but was inefficient and meant that any updates required a client deployment.

In January of 2021, I switch from a pull to a push model. With this model the server would decide what information to send after processing a command. The above example now looks like this:

1. Player sends Buy
2. Server sends Response
3. Server sends Person
4. Server sends Review
5. Server Sends Market

This reduced the amount of network traffic and server-side processing and meant that any fixes could be done quickly without a client update. This has worked well for 2.5 years, but I have recently become concerned that data was being sent multiple times as the web of what to send and when became difficult to trace (each individual command was responsible for deciding what data to send back to the client).

I have updated the pull model to use a centralized function to examine the player structures after a command is executed to dynamically determine the data required to send to the client. In this way, I do not have to worry about a command missing something (or sending too much data). The correct data is sent automatically each time.

After a recent deployment, a player named TaxE contacted me with an unusual bug: none of the cities were showing on the travel maps! This renders Conquest! virtually unplayable. During the course of troubleshooting with TaxE, we discovered that this problem affected not just his Android device but his laptop too. Switching from Wifi to Cellular did not have any effect. I was stumped until I began brainstorming with long time player, Elric.

Until recently, Conquest! used integers to represent cities on a map in a 10x10 grid. These coordinates are sent from the server to clients as strings, where they are transformed to numbers and used to render the cities. During a refresh of the maps, I realized I needed greater precision for positioning so I switched from integers to floating points. Naturally, I changed my code: int.TryParse(Input, out Number) became float.TryParse(Input, out Number)

When talking with Elric, he asked where TaxE was located. Turns out, TaxE was outside the US where a comma is typically used as a decimal separator vs a period in the US. Using the original float.TryParse(), clients outside the US were transforming city coordinates such as 3.7 to 37, rendering the cities far out of bounds of my 10x10 grid!

A quick Google search revealed the solution: float.TryParse(Input, System.Globalization.NumberStyles.Float, System.Globalization.CultureInfo.InvariantCulture, out Number);

By forcing TryParse() to utilize InvariantCulture, which by default uses a period as a decimal separator, the numbers are now being transformed correctly.

A huge thanks to both Elric and TaxE for helping work through this one!

A reoccurring suggestion has been to have names in chat/world events selectable, so players could quickly select others without resorting to cut/paste on Windows or trying to remember on other platforms. This seemingly innocuous suggestion lead to a project which took 5 days to complete!

When the Unity version of Conquest! started in 2015, it used all standard Text, Input, and Dropdown fields. These standard fields ship with Unity and are easy to use. Unfortunately, they do not support some simple and some advanced use cases e.g. underlining or embedding links in text. The latter functionality is what I really needed to make clickable player names work.

Google and I turned up some workarounds to get links working in standard Text objects (maybe?) but it quickly became apparent what I really needed to do was convert to using TextMeshPro. I decided early on that I as going all-in on TextMeshPro and this required converting all buttons, dropdowns, input, and text fields to use the new objects. Fortunately, I recently converted many panels and popup windows to prefabs, which meant I only had to modify them once for them to be fixed everywhere.

The first thing to do was add TextMeshPro to my project, an easy task accomplished via Windows > Package Manager. Adding <link> tags to text is also easy but responding to those links was more challenging. I found these two sites to be the most helpful in getting everything configured:

www.youtube.com/watch?v=lyZuCnARNSw&ab_channel=JasonWeimann
www.feelouttheform.net/unity3d-links-textmeshpro/

Here are the namespace and object names as a reference:

• Namespace =  TMPro
• Dropdown = TMP_Dropdown
• Adding options via code: MyDropdown.options.Add(new TMPro.TMP_Dropdown.OptionData("Option A"));
• InputField = TMP_InputField
• Text = TextMeshProUGUI (if you are using canvases like I am)

Assigning the new script to my text objects was simple but I had two major problems. First, I had inadvertently unchecked "Raycast Target" on the text object, which naturally prevented the IPointerClickHandler event from being triggered. The second was invoking the function I wanted from a different class (it wasn't opening a standard URL, which I could have accomplished with Application.OpenURL()). What I had to do was create an instance of the object which contained the function:

public class MyClass : MonoBehavior
{
    public static MyClass Instance;

    void Awake()
    {
      Instance = this;
    }

    public void MyFunction()
    {
      DoStuff();
    }
}

​And then invoke the function using this notation:  MyClass.Instance.MyFunction(). There are probably better ways to organize a project to allow this, but this is what worked for me. Now, player names are finally clickable! And underlining text is pretty neat too. =)

On October 12th, Conquest! launched on the Steam platform. Like other hosting sites, Steam has its share of idiosyncrasies  but once those were worked out I was able to launch successfully. The guide that helped me the most was here: The Simple Guide to Steamworks API in Unity: Uploading Builds | by George Dutton | Finite Guild | Medium

Note that when the Steam platform first created the project for Conquest! it failed to create the default packages. After spending a day attempting to debug this myself (thinking it was a problem with the build or configuration) I opened a support ticket and learned this sometimes happen. Support created the default packages and everything starting working.
​
Adding Conquest! on Steam has seen the biggest increase in the player base ever (including when it was originally on IRC). Conquest! is still difficult to learn and the UI has some usability "quirks" so the overall retention rate is small but I would strongly recommend getting any game listed there.

I also went back and updated my submissions to Itch.io and Game Jolt. I'm not sure how much of an impact these platforms have but every little bit helps. I tried to submit to Gog.com but in their automated email back to me, they indicated an automatic pass on free games. So I'll keep looking for other platforms to list Conquest! on.

Yesterday I released version 3.18.05 of the game client which concludes 3.0 development (minus bug fixes of course!).  What started as an effort to update the 350 images in the game turned into a major overhaul with 900 new ones!  When version 2.0 was released, it reused many of the same images from version 1.0 (e.g. alliance crests, maps, troops, etc.).  For version 3.0 all but one image was replaced.

By using the same artist for all the graphics, they have the same consistency and style.  A big thank-you to Vi from 99Designs.com for his efforts in making 3.0 look amazing

We also increased and standardized the dimensions of the images.  For example, in version 2.0 the icons depicting army attributes were 30x30; in 3.0 they are 128x128.  Obviously, this makes a huge difference in the quality.  Other images were odd dimensions (e.g. 94x120 for the shields) and a mixture of drawings and photos made to look like drawings.

Additionally, I contracted with an audio engineer from UpWork.com and replaced the sound effects.  The ones I had were mashed together from various free audio sites for version 1.0 of the game.  Now all the sounds have been designed by one person and are a consistent style and quality.  Thank you Leah!

The improvements in 3.0 encompass the client and server and there are so many it's hard to catalog them all.  But here are the highlights:

Client

• All new graphics
• All new sound effects (music defaults to off now)
• Improved spy and combat reports
• No scroll screens for moving troops and land travel
• New dropdown lists for targets, heroes, artifacts (vs typing or copy/paste)
• ​Weather visible from HUD in kingdom and city screens
• Improved alliance customizations (shields and ribbons)
• View all kingdoms and markets from Watch Tower (current kingdom/city was excluded)
• ​Color coded world messages
  
• Improved in game help and prompts (e.g. arrow to indicate scrolling)
• Improved formatting and readability (e.g. numbers with commas)
• Improved device support
• Passwords are auto generated for new players
• Global messages file was reviewed and spell and grammar checked

​Server 

• Active NPCs, which play and fight back, were added
• Age modification set by winner
• Automatically generate an Age legend (albeit with somewhat mixed results!)
• Land is automatically added to the overall pools (no player will start with 0 land)
• Increased maximum and starting movement points
• Overhauled troop strengths for balance and consistency
• Hero, Artifact, Item effects were reviewed and (for some) improved
• Added additional email alerts (e.g. espionage, spells, engaging fleet)
• Two new espionage missions: Dismiss (Hero) and Remove (Artifact)
• Push vs pull model for sending data from the server to the client
• Improved server performance (stress tested with ~400 concurrent, active connections)

And for both, many, many, MANY bug fixes.  =)
 
To see the evolution, consider these 3 screens, all depicting the entry point for playing Conquest!.

Version 1: