|
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.
0 Comments
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. With the completing of class abilities and skills, Krees and I turned our attention to Alliances. In the original version of Conquest!, a player could only ally with one other person (some classes couldn't form alliances at all). While this was fine I recently expanded the concept of alliances to include multiple players and members receive troops each battle (the percentage is based on the size of the alliance). I thought this would only take us 3-4 days; it ended up consuming over a week! There were lots of subtleties, including a list of alliances, searching for an alliance, member rosters, and leader administration. Krees also suggested a new feature, alliance events, which display a running list of events affected the members. We used a similar background for class commands and divided it into two halves:  Members and alliance maintenance are similar. Clicking on an alliance (or member) reveals more information:  We also started some UX cleanup, based on feedback from users. Notably, we increased the font sizes throughout the UI, fixed some scroll issues when opening pop-ups, and centered the map on your location (more on that below). Since I use my PC for testing and an Android tablet for verification, it is sometimes difficult to remember that on smaller devices the font size might be incredibly tiny (and illegible).
Not completely understanding some core Unity concepts, such as world position, I used a "magic number" to approximate the position. I tested it using a variety of screen resolutions and it works out OK but naturally it isn't good to use something without fully comprehending how it is working. If there are any Unity gurus out there who have time to explain to me what is happening I would really appreciate it! My usual source of help, Google, was surprisingly silent on the matter... On the server side I spent 2 days rewriting major sections of the battle code. Originally I had used some global pointers and static variables and I wanted to remove those constructs. There is no net effect on the outcomes of battles but the old code was "bugging" me and had to be replaced. Just one of those things. Krees and I are coming to the end of the development cycle. We have just one section remaining, Town Ownership, before moving fully to UX cleanup/prep for launch. I missed the Core Labs session last week due to a conflict and I have yet to watch the video. It covers building a budget, something I do need help with (although with just a team of two its easy to manage!). Two weeks ago we heard from Oscar Clark from Unity, who gave a really good session on scope creep. Follow the journey on Facebook or Twitter. Until next time, I hope to see you in the game. Conquest! is a client/server application. The client uses Unity and has been the subject of most of my blogs the past 10 months. I would like to spend most of this post discussing the enhancements to the game server but first let's get the new stuff for the client out of the way. The big news was completing the new pop-up images and starting on support for player classes. In Conquest!, there are 6 playable classes: Fighter, Barbarian, Mage, Cleric, Ranger, and Vampire. Each class has its own strengths, weaknesses, and playstyle. Classes are an important and large area of the game and are one of the last remaining sections to complete. The design calls for a large tome, which players will page through to view their class abilities and skills. The graphics aren't complete yet but here are the general information and abilities pages:   The skills for each class will follow a similar pattern. I really like this design and am excited to see it 100% complete.
The Conquest! server is written in C and was first created in 1998. It has evolved quite a bit since version 1.0, including enhancements to the communication protocols, game features, and stability. As part of taking Conquest! mobile I have gone back and cleaned up some poorly written code. Part of this cleanup involves the use of a lint program, namely Splint. I recently ran split for each of the source files in Conquest!. While I took comfort in the fact that Splint only identified a few minor bugs it did uncover some less than optimal code. For example, the use of snprintf instead of sprintf and strlcat instead of strncat. Note the former required the install of the libbsd library but this is readily available. Also new this week was the storing of chat and world event history. When a client connects this information is sent, timestamped to the local timezone. This allows conversations to continue in the event of a disconnect or simply the passage of time. It also allows players to instantly see the last 20 world events without having to visit the web site. The server saves these to a file when it exists so they are persisted between reboots. These features enhance the user experience and help persist the Conquest! world. All told, the code cleanups and chat storage took approximately 8 hours of development over many long nights. Grueling, but worth it. This week during the Core Labs Accelerator lecture we heard from Jeff Burton, one of the founders of Electronic Arts, who coached us on networking skills. Jeff is one of those people you want to go out to dinner with to hear his stories and I hope to meet him during demo day in Silicon Valley later in the summer. Follow the journey on Facebook or Twitter. Until next time, I hope to see you in the game. Since my last post, Krees and I finally completed the weather graphics. In Conquest!, each continent has weather effects which change hourly and affect food production, the risk of a ship being damaged while sailing, and how troops fight in combat. In the old client, a text description of the weather was sent. For the new client, we wanted to use images to represent the 11 different types of weather. For example, here is what freezing looks like:  This show also shows the new pop-up design, which use color images vs. wood carvings and reduces the size of the scroll area. We are currently in the process of retrofitting some of the existing ones to use the new design, which provides additional variety and color to the 100+ pop-ups currently in Conquest!.
As part of this new design I created a Popup Manager class in Unity to handle existing and future variations. This was a rather large undertaking, as I had spread the code for the pop-ups across all the scenes and it took a couple of days to consolidate it all to one master class. I'm not sure if this helps any with efficiency but it reduced the overall size of the code and makes future changes much more manageable. This project is my first real foray into true Object Oriented Programming and I'm getting a big dose of on the job training. The code base has gotten better over time and I'm sure I'll continue to make further enhancements prior to launch. On the server side I made some pretty drastic changes to the communication protocol used by Conquest!. Using Message Analyzer, a free tool from Microsoft which allows you to capture all network traffic, I began looking at how much data is being sent back and forth between the client and server. Conquest! uses an XML based protocol and so has tags such as "Message", "Body", etc. While XML is a great protocol for humans to read and process its wordiness was unnecessary. But rather than switch to a different protocol, such as JSON, I simply shorted all of the tags to 2 characters each and changed "YES/NO" responses to "T/F". These two changes reduced the overall message size by approximately 20%. I also continued my crusade to remove unnecessary messages and reduce existing ones. Unfortunately, these changes complete break the Windows reference client but I stopped making changes to that a while ago. In the Core Labs program we heard a lecture discussing timelines and have our first deliverable due: a production timeline for each of our games. Fortunately I have worked on many IT projects so I have some experience to draw on. Follow the journey on Facebook or Twitter. Until next time, I hope to see you in the game. Since my last update, Conquest! has seen several major enhancements to both the Unity client and the game server. The week culminated with an exciting opportunity for Conquest!. Read on! The first major piece of new functionality was the completion of the artwork for all 50 badges. Earning badges is a new feature in Conquest! (added just last year) and allows players to track their journey in the game. There are easy, medium, and difficult classes of badges to earn and they are transferred from Age to Age (if your player survives!).  I also added 20+ sound effects to the game client and changed the music from one single track to six one minute tracks. These changes have greatly enhanced the user experience, something we will be focusing on more as we get closer to completing all the art and design. The effects and music can be toggled on/off individually.
Next simple animations were added: one to show when a player's movement points or gold have been adjusted and another for alerts (such as being attacked or robbed). As with the chances to audio, these enhancements specifically target the user experience by drawing the player's eye to important events. I'm using the newer Animator class in Unity, which supersedes the Animation class and allows for the definition of state machines. I was beating my head against the desk to get it to work properly until I found this amazing post, which was well written and included screenshots. Definitely a must read for anyone starting out with Animator in Unity! On the server side, I reduced the size and woriness of player log files by combining similar events into one entry (i.e. instead of separate events for the Campaign and Defense army consuming food, there is now one). I also moved descriptions of most items from the server to the client. Prior to this change, the server would send these (mostly static) pieces of information when a related command was invoked. This reduces the load for both client and server as text, which rarely changes, no longer needs to be sent around. In addition to several bug fixes I continued removing or reducing the wordiness of messages. Finally, Conquest! was selected by Core Labs for the Accelerator program. The program is a 6 month course designed to help demystify the business side of releasing a game to the market. This was my second application and I'm excited to be a participant. More information can be found here. Follow the journey on Facebook or Twitter. Until next time, I hope to see you in the game. Since my last post, Krees (@Krees9116) has diligently been working on the troops icons while I have focused on some overdue code cleanups on the mobile client. There are many troops in Conquest!, and each requires a different portrait. There are 6 playable classes plus Bandit and Titan classes for a total of 64 different icons. Krees has done a great job giving each its own personality. Check out some of them from a market below:  We still have the Titan class left but all of the playable classes plus Bandit (for the tutorial) are completed. On the client side, I went back to some of my earlier work in Unity and applied "lessons learned". For example, using layout groups (vs. manually positions) to organize items on the screen. This will make the user experience more consistent and moving items around on the screen easier.
I also added support for checking the client's version number and directing players to a platform-specific download page for an update. In this way, I can ensure all players are on a minimum release of the client. Since the client hasn't been added to any stores yet it just redirects to the platform's main storefront. I also added support for a changelog visible from within the client. Next we will be working on the icons for the 22 heroes and 50 badges. Players may hire one hero at a time, which provide a variety of bonuses. During their adventures in Conquest! 50 badges may be earned, which carry through to the next Conquest! age (if you survive!). Badges vary from traveling to the Secret City to winning 100 battles to playing all classes. This is a new feature of Conquest! but enriches the experience for the user. Overall, I would estimate the client is ~80% finished at this time. After finishing the icons, the next major section to tackle is class specific commands. I have our end date projected as April 14th, which is just over a year since I picked Conquest! up again. If we do finish in April, development of the mobile application in Unity would have taken ~9 months. I anticipate another 30-45 days of getting everything ready before deploying as a beta release to the Android app store (iOS to follow shortly thereafter). 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
April 2025
Categories |
RSS Feed