|
Conquest! 2.0 beta "officially" opened this week with deployments to the Android and Apple stores. The city map was completed this week, which was the main driver for the open beta. This map continues the design from the kingdom, with labeled buildings used to perform all city related functions (markets, church, tavern, mystic, magic shop, and port). The map will also highlight when the city gates are open or locked.  As part of the work on the city, I removed two more screens: Royal Vault (from kingdom) and Town Hall map (from city). Rather than jumping to additional screens it just made sense to add these to the main areas. This also had the benefit of reducing the size of the application (2.0 is actually smaller than 1.x). In total, the number of screens was cut in half (from 18 to 9). I'm very pleased with how 2.0 is shaping up; feedback from users has been positive as well.
I also added a few more enhancements to the client, such as hiding the "Hire Spy" option if a player's current city does not have a market. The movement point and gold costs to hiring a spy were also added to the popup to round out displaying the costs for things everywhere (only repairing ships is missing this now I think!). The "out the door" price (which includes tax) for buying items is displayed both on the market popup and the detail screen. I'm not sure why I didn't do this before but now players can quickly know exactly how much gold they will be losing or gaining when they buy/sell from the markets. The issue with trying to hire a spy was discovered during a playtesting session on Twitch by Highsight (https://www.twitch.tv/highsight). During the playback, he tried to hire a spy in a city which didn't have a market, which let to the (obvious) question: why is that option even there? Point taken, and now removed where appropriate. The walkthrough also highlighted a few more areas of work, such as some minor graphics issues and understanding what was happening in the tutorial. The tutorial must be read to be understood and after the first few screens he (like other players I'm sure) starting just clicking through it. Overall, the feedback was positive but Conquest! still needs help on usability and explaining what to do and how to win. Version 2.0 is the start of addressing some of that and work will continue once we are live. (i.e. Conquest! will never be "done"). This week I'm going to work on some of the feedback I've already received. Krees is also working on enhancements to the chat and the main menu. We are also adding a new building to the kingdom and city screens (Watch Tower or similar) where we will make it easier for players to find out about the next Seasons. 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.
0 Comments
Development of the Conquest! 2.0 user interface has begun in earnest (1.06.20 is the last 1.x release). For the initial release, we divided the game into certain key areas: kingdom, for managing keeps and taxes, and city, for purchasing goods and access to the church and the tavern. Other key aspects of the game, such as troop orders, subterfuge, and combat, had their own separate areas. Here is the current main overview screen, which shows the six key areas:  Players click the various buttons, which open up new areas. The icons at the bottom popped up functions such as viewing your log, private messages, and the in-game chat. There were 9 common areas for a player to move around (Overview, Kingdom, Fleet, City, Church, Tavern, Army, Subterfuge, Combat). While we accomplished our overall goal to compartmentalize the game into sections where like actions lived, it also introduced a navigation issue. For example, loading troops onto ships meant going from City, to Army, to Kingdom, to Fleet. We did add "jump" buttons to help but that was more of a bandaid as we could not add them everywhere. We liked the overall structure, where like actions were grouped together, but we wanted to make it easier and more intuitive for players to move around. For 2.0 we grouped all functions around 2 areas: Kingdom and City. And we moved from "flat" buttons to a 3-D overview.  Actions are now grouped within buildings in your kingdom and the city. Clicking on a building with a label reveals a new side menu.  Players scroll around the map to view more buildings (and actions). All actions in the side menu are spelled out (vs. solely using icons). Instead of 11 screens there are now 2. Overall moving around the game is quicker, as the back and forth navigation has been reduced. One interesting problem I discovered was after I added a certain number of prefabs to these new screens, the scroll speed of the map became unplayable. Using Unity's profiler, I discovered the CPU was thrashing on a task called "WaitingForJob" under the CanvasRenderer. I spent days on this issue, trying all of the suggestions. I was almost ready to chalk it up to a bug in Unity but by chance I tried one final suggestion: static game objects. From the official Unity manual: Information about a Static (ie, non-moving) object can often be precomputed in the editor in the knowledge that it will not be invalidated by a change in the object’s position. For example, rendering can be optimised by combining several static objects into a single, large object known as a batch. Once I set this option on most of my game objects, performance was restored. I don't know if this is a bug or not (I opened an issue with Unity) but I'm thrilled that 2.0 is back on track. Once the map and buildings for the city are complete, the new version will be released.
Finally, reducing the number of seasons by one had the desired effect of minimizing the time commitment required to play Conquest!. Jj conquered the Age in 18 days, which is about the right amount of time. 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. A major improvement was made to the Conquest! server this week. In order to understand it, first a minor history lesson.
Conquest! has always had the concept of a single winner of an Age. In the past, this was the player who made it to king ten times without dying. This usually took a player 30-45 calendar days, depending on the level of competition. For the mobile version, the game was modified so that land was fixed and the victory condition was changed to the first player who controlled a percentage of the total land (current 15%). When an Age ends, all players are reset, heroes and artifact locations are changed, a new secret city name is chosen, and a few variables (such as the current Age) were updated. The mobile version of the server works the same, except players are automatically carried over. In the past, everyone had to recreate their player, including all settings. Restarting an age was a manual process. Since Ages used to take so long and the level of effort was relatively low (15-30 minutes) I didn't have automating the Age restart as a high priority. Until recently. For the first time since Conquest! started (circa 1993), Age restarts are now fully automated. The process took a day to implement (and another to fully debug) but it works great. Once a player amasses enough land, they are made Titan (a special class reserved for Age winners) and an announcement is made that a new Age will be starting soon. Email alerts for those who have signed up are also sent. Thirty minutes later, the server initiates the new Age code. Files are closed and backed up to an "ages" directory. Cities and continents are reset and players who survived the old Age and recreated in the new. One of the most challenging aspects was the random generation of names for heroes and the secret city; I already had code to generate locations of artifacts. I had never written a random name generator and searching around yielded little in the way of an actual algorithm I could use. Some were simple, such as randomly combining consonants and vowels. Others were much more sophisticated, where probabilities were established that one letter would follow another. But I didn't really like either approach. In the end, I simply created a "dictionary" of word combinations and then randomly put them together. In my tests, they came out well. For some reason I thought this was going to be easier than it was. Now that no human intervention is required, the game is effectively self-running. As long as the machine stays up (and the game doesn't crash for another reason!) it could run indefinitely (in theory!). While this process is invisible to the players, it is a huge quality of life improvement for me. An improvement for the players next Age that is being discussed is the removal of a game season. Seasons currently happen 5x per day and grant movement points, attacks, food and gold production, etc. This gives players more to do but also means a greater time commitment. By reducing the seasons, and lowering the victory condition to 12%, I'm hoping to make it easier to get into the game without sacrificing real life responsibilities. I'll report back after the 5th Age ends. 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! 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:  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. 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. 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. 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. 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. 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. |
AuthorJames has been working on Conquest! since 1993. Archives
September 2022
Categories |
RSS Feed