This week the graphic designer, Krees, and I started work on the kingdom maintenance screens. We completed 4 of them throughout the week: Basic Settings (Kingdom name, Win Message, Corpse, and Vacation), adjusting your tax rate, buying/selling keeps, and enlisting peasants into your army. Most of these are used only once or twice but we are chipping away at the functionality. The last two screens under Kingdom are Vassal maintenance and the Royal Vault. The latter will be challenging, as there are 50 magical items players can obtain with a wide variety of effects. Additionally, some can be used, others can't. Some take arguments, such as a Player's Name or City, some don't. I don't have the design yet but I'm anxious to see it. Here is the new basic settings screen:
Another import add this week was the inclusion of the Advisor (bottom left). The Conquest! game server processes all of the commands sent to it by clients. Until all situations are handled by the Unity client, the Advisor will contain the text of the response from the server. Some checking will be done by the client, to minimize the number of error responses. It is also a great tool for debugging. We also added a players total peasants to the HUD. The HUD now contains all the essential information a player needs to quickly check on the status of their kingdoms. Here is the new Buy/Sell structure screen:
These new screens were relatively easy to add, as I created a structure while working on the army screens which is fairly easy to replicate. Unity makes it easy to copy/paste Game Objects from one scene to the next. Once I have the base structure in place, this pop-up window for example, I swap out the controls I need and in just a few minutes the prefab objects are done. Similarly, I copy/paste the accompanying C# code and voila, a new working scene. For example, take the Advisor object. I created all the GUI elements under one GameObject, so I just need one cut/paste to create the UI prefab. I created an Advisor class, which stores all the UI elements and the code necessary to update the pop-up and the message indicator. Once I got it working on the Overview scene, it took a few minutes to have it on the others. Here is the new Enlist screen:
As you can see, these screens are just variations on one another. We have not yet started work on any of the buttons on the bottom of the screen (Alliance, Population, etc.). Prior to tackling these I would like to move to the City screens, since this gets us a little closer to a playable build. There was just one small fix to the game server this week: a bug fix when sending over a certain help command without being a player in the game. This actually crashed the server so this was a good find.
Finally, here is the adjust tax screen:
This week saw me tackle the hardest item (to date!) in Unity: formation maintenance. In Conquest! players have the ability to define groups (or ranks) for their troops. Troops in the front lines engage before those in the rear. Troops with range can strike first from any formation. This allows players to line up their "meat shields" to protect the (generally) more fragile ranged units.
The design in Unity called for a drag & drop interface, with groups dynamically added and removed. I found a few tutorials on the new UI system in unity, which allowed me to get the drag and drop functionality working relatively quickly. However, dynamically creating the group graphics and moving the icons took 2 days!
Most of this time was spent on Google, trying to wade through all the available documentation remotely related to my needs. In the end, the biggest block was detecting where the mouse was when the user let go of an icon. As easy as it seems now, this caused quite a bit of issues for me. Eventually, I created a new project and went with just one icon. Then I remembered that by default, Unity draws items from the middle, expanding both sides evenly. In order to detect the leftmost edge I had to divide the center position by 2 and likewise for the rightmost edge. I'm sure there are better ways of handling this but it worked!
The layouts of the group boxes are a little off but overall it is functioning! After I got it working I took the APK file to the Test Droid cloud and the layout was all wrong. Back to Unity. I adjusted all the anchors (I had largely left them at the default due to being in a hurry) to correct the formatting issues. Another test and this time my screens looked ok. I went back to the other screens and corrected the anchors there too.
The Army screen received a new background this week. The camp is now much more visible and really brings out the buttons. Thank you Krees!
I also spent some time correcting some other minor formatting and coding issues. One of the advantages of getting something working is now I get to go back and fix all the items I did while in development mode. The army screen is now mostly complete. We will move on to the Kingdom screens next which will provide additional challenges (I'm looking at you Fleet Maintenance!).
On the server side, there were just two new items: formation sends the troop numbers vs. the names (which made parsing the format much easier) and accepts a new command ("DEFAULT") to restore the game default. I anticipate making additional changes to the engine as it transforms from serving text based clients to mobile ones.
The Kickstarter campaign picked up a few new pledges but we are a ways off. Please consider supporting Conquest! with a pledge of any amount: http://kck.st/1LTthng
Follow the journey on Facebook or Twitter. Until next time, I hope to see you in the game.
This week saw the launch of the Kickstarter campaign. We are seeking to raise $11,000 to accelerate the completion of the client. Thanks to Eric S, Eric M, and John B for their generous donations! You can check out the campaign page here: http://kck.st/1LTthng
I made great strides with the Unity client this week. I continued to clean up some old code and added quite a bit of functionality, including two new army screens:
The background image is going to be re-worked so it is during the day but the bones are in place. The second screen handles all the functions on the right (Training, Movement, Disbanding). The challenging aspect of this screen was simply scrolling the panels and the added complexity of having 3 of them. Fortunately, I found a great video tutorial on Unity's site which had step by step instructions on how to complete it. There may be some minor tweaking but overall I'm very happy with the results:
One of the advantages of using a tool like Unity is built in functions to aid in development. One of the key ones I found this week was "PlayerPrefs". This class allows you to store information, such as name and password, on a devices local storage and retrieve it later. In just three lines of code, I had this information stored and could easily retrieve it. When I was writing the reference client in VisualStudio, I used a file based mechanism and had to open/close the file, write the data, etc. While learning Unity has been challenging at times, items like this offset some of it. Thank you Unity development team!
One odd thing which has happened is my HP Slatebook 2 is no longer rendering the images in the game (they appear all black). At first I thought this was an issue with the build but I found an Android test site (cloud.testdroid.com) and the game plays fine there (slow, but good for a simulation). I'm still investigating this one.
On the server side, I made two small changes. One was to remove parenthesis included in a message sent to clients. This was a legacy behaviour, as the server was trying to format for text based clients. The second change has to do with attack time. Previously, you could only attack once every 15 seconds. This was meant to give defender's time to react. However, the timer was based on the attacker and not the defender! This meant that as a defender I could be attacked 10 times in a row, by different players, leading to the dreaded "ganking". Now, defender's have some time to react.
Follow the journey on Facebook or Twitter. Until next time, I hope to see you in the game.
It began in early 1993 when two high school friends, James Bennett and John Leth-Nissen, who enjoyed creating their own pen and paper games were introduced to a new medium, Internet Relay Chat (IRC). Both had spent time dialing in Bulletin Board Systems (BBS) using 14.4K modems (eventually 28.8K and beyond!) and played Multi-User-Dungeons (MUDs). But these systems were typically regional, required accounts to play, and limited the number of people who could connect simultaneously. They also had a tendency to disappear and would be crossed off a printed list of phone numbers.
IRC was different. Thousands of people connect connect at once. Channels were formed where like minds would gather and chat (or argue!) with people from all around the world in real time. There was lag and disconnects but it was amazing! There were already games on IRC using automated programs written in script called "bots". But these were limited to poker or word games. We started talking about building a persistent world war game and "Conquest!" started to take shape. Once we figured out how to generate random numbers, development began in earnest.
I lived in St. Augustine, Florida at the time and John in Daytona Beach. Most Saturdays I would drive and meet up with John where the two of us would pour over Conquest! code for many hours. The scripting language was very similar to UNIX scripting and learning the idiosyncrasies took time. But after approximately 6 months, Conquest! 1.0 was released on #Conquest on efnet. The reception was incredible.
Players from all over the globe joined to compete against one another in the world we created. There was just one class, one continent, and no cities. There were bugs and "nerfs". But the action and gameplay drew players in. Shortly after the launch we immediately started working on enhancements. The game started as one bot but before long the player base outgrew it. The code was split into server and client processes; eventually, there were 4 clients to keep up with the load!
The IRC bots were inherently flaky and I coded an elaborate system to attempt to keep them all in sync. There was quite a bit of drama when the server went to save data; if the process crashed or lost connectivity hours worth of battles could be lost. There was drama in the game as well, as alliances were formed (and frequently broken!). The politics in the game would rival anything in the "real" world.
In 1995, the first Conquest! "Gathering" was held in Orlando, Florida. Approximately 15 players met face-to-face to share our war stories, triumphs, and defeats. It was thrilling to finally meet these great people in person. Three more Gatherings were held, in Chicago, Dallas, and Las Vegas. I met some amazing people and am still in touch with some of them today.
In 1998, the game had finally outgrown the IRC script and I began converting it to C. This was quite an undertaking (it took approximately 6 months) but dramatically improved performance, scalability, and reliability. The architecture remained a client/server model and over the years I experimented with different clients, such as Web, and Instant Messenger (before AOL changed the protocol!). I could never get a good graphical client written, however, and that was the direction I had always wanted to take Conquest!.
In 2005 or so, I left the game to pursue other interests. I released the binaries and the game continued to run in one form or another for several years. I never forgot about it and early in 2015 a former player approached me about taking Conquest! mobile. This re-ignited my passion for the game. I opened up the server and corrected many wrongs (how was this stuff ever working?!?). I created a new web page and built a reference client using Windows Forms. And I partnered with a graphic artist, and Steffon, another former player, to design and build a Unity based client. Finally, Conquest! was getting the medium it deserved.
It's less than 24 hours before the Kickstarter launch. No matter what happens I have enjoyed the ride and look forward to the next chapter.
A big Thank You to all the players who have made Conquest! great over the years: Pierre, Rommel, Gog_Magog, Cym, TazQ, Aethelred, FRobOS, Ravenfire, Belief, Kanyslupa, Prenex, Kioras, Netwalker, Xelindrya, Vhaeraun, Kyld, the Star clan, Archelf, STARBREEZ, LadySunF, Wolfsbane, Shaylan, Hitsnorth, lesla, Perrin, LordRemok, SeLTiC, Baggy, and many, many others.
Follow the journey on Facebook or Twitter. Until next time, I hope to see you in the game.
This week saw final preparations for the Kickstarter launch on September 7th. This included last minute updates to the campaign page and submission for review (it was accepted!). I will probably be wordsmithing the page up until the last minute before clicking the button to launch. On the page we have a video (a "live" action demonstration of the game plus an interview with me), a Unity prototype for Android, a reference client for Windows, and many screenshots. Here is the latest prototype for travel:
We are attempting to raise $11,000 to complete development and fund the remaining graphic design. It's nerve-wracking and exciting at the same time!
On the server side, I made some adjustments to the random kingdom/ship name generators (removed some of the felines from the latter; somehow it didn't seem right to have "Angry Cat" as a ship name). In Conquest! battles were typically over in 1-2 days (rounds). I wanted to extend them a bit so I adjusted most attack values for troops down by 50%. This will require further adjustments but they are now about where I think they should be. Additionally, cavalry and certain large units (such as Fire Drakes) take 2 housing now (versus 1 for infantry). Instead of loading up on 1-2 units, players will have to balance cost (in food or gold) versus how much housing space they have available. Units which require food still only need 1 but adjusting this is another option to explore.
I also added a new espionage command, "Raid". This allows players to raid another player's vault and steal 1-3 magical items. Success changes are the same for "Forgery" (which allows you to steal a small amount of land). There are quite a few espionage options now and I'm excited to see these explored within the game. Finally, I made some minor adjustments to the output of certain commands for the clients (such as adding whether a unit can be trained and when spying you can see the total number of magical items another player has, etc.). These don't add functionality but will make things a bit easier when the client goes to implement these features.
On the Unity client front, Steffon continues to make great strides. We have 4 working screens now: Loading, Login, Overview, and Kingdom. There are a few minor defects but nothing major. The Android APK file will be available for download once the Kickstarter campaign launches so folks can see what we have been up to and the vision for Conquest!.
I'll be posting regular updates on the progress of our campaign. To get involved, spread the word on social networks or donate to the Kickstarter campaign. As little as $1 helps bring Conquest! to life. And if you decide to donate more, you might be able to name a hero or even a continent within the game.
Follow our journey on Facebook or Twitter. Until next time, I hope to see you in the game.
This week saw several commands modified for increased flexibility and updates to the way vassals and lieges receive aid. In Conquest! a player can have up to 4 armies fighting in a battle: their own, troops sent by an alliance, and two summoned armies (such as barbarians or packs of animals). There are class abilities, heroes, magical items, and spells which can grant summoned armies. Having multiple armies not only increases your firepower but they also absorb casualties. If your main army retreats the battle is over so having these additional armies is a tactical advantage.
Prior to this change, all but the alliance and class-related summoned armies worked for attackers only and a target had to be specified when summoning the army i.e. "Use Amulet PlayerX" would summon a pack of animals and attack PlayerX immediately. These hordes could not aid you when fighting hordes to gain land. Now, when a player does summon an additional army, a flag is set and the very next battle, whether it is an attack or defense, the horde will join in. This opens a wide variety of tactical possibilities and allows a player to stage multiple armies prior to launching an attack. You can also stage these for defense.
Similarly, magical items which granted bonuses, such as a Shield of the Wind, were one used immediately when attacking another player. Now, this bonus is granted for the next battle and can be combined with summoned armies. These hordes and bonuses are currently only valid for the very next battle but in the future additional effects could be granted where they last for x number of attacks or defenses.
Last week I discussed the changes to Vassals and Lieges regarding food and gold generation. This week I modified how vassal aid works. Instead of pulling very small amounts of troops a player's army (too small to make a noticeable impact), the game will create a Militia army to aid a Liege/Vassal. The number of troops is dependent on the level of your Liege and/or the number of vassals you currently have. Players still receive a small percentage of the spoils when their Liege or one of their Vassals wins a battle.
On the backend I added a player's class and numeric level to messages sent when a player is attacked/attacking and the population command, which lists 10 random player's on a continent. These values will be used by the Unity client; for example, here you can see the player's level displayed in the battle results:
I also spent a couple of days rewriting major sections of the battle code. As with any development, over time bits and pieces were bolted onto the main structure which caused for duplication and/or inefficiencies in the code. This rewrite addresses some of them. For example, I used to have two functions which created summoned armies: one for troop based, one for creatures (such as dragons or packs of animals). Fundamentally they did the same thing so by combining into one function I can standardize how they are created (now all summoned armies are created by one function) and ensure ease of maintenance.
On the Unity front, Steffon continues to make good progress on the Client. The login and overview screens are functioning with the new architecture and he is now working on the kingdom screen. For the Kickstarter launch on September 7th, we hope to have a downloadable, playable version of the Unity client to demonstrate these screens.
Until next week, I hope to see you in the game. Follow our journey on Twitter or Facebook.
James has been working on Conquest! since 1993.