|
This week saw the addition of two screens under Kingdom maintenance: Vassals and the Vault. Each of these posed some unique challenges in Unity. Once a player reaches level 4, other players may select them as a liege when creating a new player. One liege may have at most 4 vassals. Vassals provide a bonus to food production for their lord and in return receive an income bonus. Additionally, small bands of Militia will aid either the lord or the vassal while defending. A new feature added for the Unity client was the ability for a player to email an invite to their friends to become a vassal.  The server already contained a few email capabilities so this was expanded to support the new email for vassals. RIght now, the email just directs players to a web site which will (eventually) provide instructions on how to download, install, and become a vassal. Eventually it would be nice to have everything done in one click. I'll have to save that for a future version. Since a player can have 1-4 vassals, I created a Vassal class in Unity to store the results from the server. Once received the client will determine which prefabs to show and hide the rest. Unity makes all of these pretty easy so once the basic structure and code was in place the rest was simple. Also new was the addition of using Canvas Groups in Unity to disable the background buttons. Before I was setting the active property to true/false, depending on whether a pop-up was displayed. This worked OK but is not a typical user experience. By setting the interactable flag to false, Unity shades the buttons and prevents users from clicking on them. Nice! There are 3 different kinds of loot in Conquest!: magical items, artifacts, and heroes. Magical items are common and can either be used or sold at the magic shop for gold. Artifacts and heroes are much more rare and there is a fixed amount of them in the game. A player may only have one artifact and one hero. All of your loot, plus the badges you have earned, are available for maintenance in the Royal Vault screen.  This is a new screen, even though it uses the same background as Kingdom maintenance. There are 50 magical items and badges so a grid layout was used; the max page is determined dynamically, based on the number of items you have. Any artifact you own always appears in the first slot. Eventually, there will be a unique icon for each artifact and item. Any hero you have is displayed on the second tab, along with a description and an opinion the hero has of you.  And finally, the list of all badges and which you have earned; this screen is still a work in progress but eventually there will be a unique icon for each.  On the server side, a few changes were made to support these screens (such as the aforementioned email invites). I removed the "release" command and collapsed all Vassal related commands under one umbrella command ("Vassal"). I can't decide if I should do that for all actions or not i.e. have just a few commands with many variations. I also added the descriptions of items, artifacts, and heroes to the output from the server. This is expensive in terms of data so I may move instead to having them stored on the client. There are advantages/disadvantages to each approach. Finally, I added support to see another player's badges and the type of troop to the army listing. In most cases a player's troop type will be the same as their class, but there is a hero you can hire which changes that. Additionally, this might be a feature I want to expand in the future.
The Kickstarter campaign is in its final week. Please consider supporting us 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.
0 Comments
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:  The Kickstarter support has taken a noticeable dip. I do plan on continuing development of Conquest! once the campaign ends. Please consider supporting us 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 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. This week saw many major changes to the server. The server has a centralized parser, which handles figuring out the request from a user and calling the appropriate function to execute. The commands are stored in a sorted array and a function pointer is associated with each one. Prior to the change, the server would save the player who initiated the command, regardless of the outcome of the command. This is fine for small numbers of players but Conquest! needs to scale once we launch a mobile client. Now, the server will only save if the command has an impact on a player's stats. This is especially critical for commands such as "Person" and "Review", which are purely for informational purposes but called frequently.
The next change had to do with how commands are checked. Most commands in Conquest! require movement points to execute (this represent time) and some are class-based. Prior to the update, these items were checked in each function. I modified the command structure to include the cost and class restrictions and these are now checked in the parser. This reduced duplicated code (the server supports over 100 individual commands) and makes it easier for me to maintain these items going forward. There are some exceptions, for example some commands use a player's level to determine the exact cost, and these are still handled individually. Neither of these changes have an impact on the user experience but make the server better. The last major backend change deals with how player logs, private messages between players, and journals are stored. Before, I used the player's name and two different functions to handle logs/private messages and journal entries. Now I have one central function which handles all three and a standard naming convention using the players unique ID. There were several changes which do affect player experience, the first relates to Vassals. Conquest! supports the notion of Liege/Vassal, whereby a new player can choose to server under a Lord (or Lady). This allows players to choose their Faction, Continent, and Class at the start of the game. Prior to the change, you could have up to 16 Vassals; each new year Vassals would send a small amount of food (5%) to their Liege in exchange for a small amount of gold (2%). During battles, Lieges and Vassals would send small amount of troops to aid one another; this feature can be toggled on/off by the Liege. When I revisited the math, the numbers were ridiculously low: if your liege had 500,000 gold a vassal would receive 10,000 gold per day. Assuming 4 vassals, each with 3000 food, a Liege received 600 food. Neither of these amounts are significant at all. So I capped the number of vassals to 4 and for each Vassal a Liege receives a 5% bonus to their food production each Housekeeping (HK, currently 6x per day). For each level their Liege is above 3, Vassals receive a 5% bonus to income each HK. This equates to nice bonuses for each and does not take away assets from either player. Aid during battles remains the same. On the Unity client front, Steffon rearchitected how incoming commands from the server are processed. This is key because the the client has to respond to not only commands initiated by a player but also things like world event messages or chat send by the server. This new architecture is a good foundation for the client. Finally, on the crowd funding front we have picked a target date of September 7th to launch the campaign. This is contingent on having the artwork and a playable Unity client ready but should be achievable. Until next time, I hope to see you in the game! This week saw many small improvements to the Conquest! game engine. A portion of these have no impact to how the game functions, such as standardizing constants used in the code, removing global variables, or collapsing like functions into one. The engine itself is written in C and over time had gotten "messy". The past several months have been spent not only adding new features but doing quite a bit of house cleaning. Some of the new things this week include 8 magical items for players to quest for: Book of Prayer, Robe of Vermin, Potion of Invisibility, Bracers of Defense, Lens of Detection, Rogue's Dice, Horn of Fog, Stone of Weight. This brings the total amount available to an even 50. Magical items are loot in Conquest!; most (38) are beneficial in nature, the rest are cursed. Items can be sold for gold and are an important way for new players to build wealth or assets early on. The exact descriptions of all the items can be found here. Several artifacts also saw a boost in power. I also corrected the way troop bonuses are calculated and sent to the client. With the exception of one bonus given by the Alchemist hero, the bonuses you see when looking at your army are what you will use during combat (before these bonuses were not displayed properly until combat). Summoned armies, such as barbarian hordes, are now balanced instead of strictly being based on the player's army composition. This was done to prevent certain classes from being able to fight the horde risk free due to certain combinations of troops. The total in the summoned army is still based on the player's army. I removed support for two commands this week: "spy conquest" and "spy conquest list". The former used to show 10 random players on any continent; the latter, showed a list of the total number of players on a continent by level. "Spy Conquest" has been supplanted by the "population" command (which shows 10 players on your continent only) and "conquest list" wasn't very useful (and the client didn't support it). These were some of the earliest commands created in Conquest! but over time not needed. The total number of commands the server understands is now 129 and I may remove a few more to tidy things up. Finally, effects of weather are governed by how much of a continent you control: the higher the percentage, the more likely a weather event will affect your kingdom. On the client side, there was lots of good work done by Steffon and Krees this week. Steffon is working on a prototype of a mobile client in Unity, with art and design from Krees. Steffon has the login page working with the new design and it looks great! Once Krees finishes designing the new Kingdom, Travel, Combat, and Subterfuge screens we will have everything in place to launch a crowd funding campaign to complete development. Until next week, I hope to see you in the game!  After approximately 3 weeks, a winner in the Conquest! Mobile UI Design contest was chosen: congratulations to Krees for his winning design. The design fits with the theme of the game and brings a much needed graphical interface to the game. Check out a sample:  In other exciting news, a former player and C# developer ("Archelf") has started working on a Unity based platform for the client. He already has the client connecting to the game server and is able to send/receive data. The next steps are to incorporate the designs from Krees with the Unity client to build a working prototype for the crowd funding campaign to bring it all together. I've been working on a modest budget which should get us to the finish line. Very exciting!!!
On the server side, I added rotation for player logs. Before, they would just grow and grow, but I've now capped them to 128 entries. I also modified tithing for Clerics and Rangers to 20% and 15%, versus a hard cap. I added the "Summoned" and "Bandit" types to the configuration file vs. having them hard-hard coded. Quest characters will also increase their surrender percentage by 5% for every defeat. One of the more interesting changes this week was to "rock/paper/scissors" or troop counters. In summary, Infantry < Cavalry < Flight. Ranged attacks do more dammge to infantry and flying units, but less to cavalry. This has the effect of making army compositions and formations much more important and should lead to some fun outcomes. Until next time, I hope to see you in the game! |
AuthorJames has been working on Conquest! since 1993. Archives
October 2021
Categories |
RSS Feed