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.
0 Comments
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. Happy New Year! Work on Conquest! continues at a good pace in the new year with two more areas focused on: Questing (complete) and Fleet Maintenance (nearly complete). Looking at the list of remaining items finds Class Maintenance, Misc Icons (troops, badges, etc.), Alliances, and City Ownership left. The first two are quite large, especially the Class Commands which is where each of the 6 playable classes in Conquest! execute their class specific commands. But more on what we accomplished. In Conquest! there are 7 Quests players may undertake: hiring a hero, enlisting signature troops, searching for magical items, searching for an artifact, gathering components to cast spells, attacking a horde, and eliminating a bandit camp (the tutorial). The design called for a "map" of the area around a player's kingdom, with each of the quests represented by a specific location: Hiring a hero and searching for an artifact require a player to have the specific name or location gathered from the mystic. Once a quest is selected, a pop-up prompts the user to start the quest: All quests but the tutorial are single commands; that is, they only require one click to complete them. The tutorial is a series of steps designed to introduce new players to the game by having them visit several areas in the game, culminating in an attack against an NPC. Unlike other attacks, this does not break a player's protection. The tutorial can only be completed once. Fleets in Conquest! were added after release of the game to support multiple continents. Players can establish kingdoms on each of the 3 continents in Conquest! and manage independent kingdoms (very few items are shared). Initially, players could have just 1ship but this was expanded to 8. Coupled with the invasion command, which allows players to bypass structure limits on the number of troops they can field using troops onboard ships, maintaining a fleet became essential. Fleets can be used to strategically strand others on particular continents. If you do not have enough money to buy a new ship you could be struck for a while! Ships can also be used to transport goods and troops between your kingdoms, which is useful to jumpstart a new kingdom or hide assets. There were 9 ship designs originally but I trimmed this to 8 recently. I also renamed some of the designs to better reflect the medieval period. Naturally the screen has a nautical theme: Conquest! randomly generates a name when a new ship is purchased but players can also rename them. Ships can be damaged by naval battles or the weather so there are options to repair them as well. All of the screens are similar in nature (the icons are still being worked on): Naturally there were several changes to the game server to support the new designs. In particular, the removing of messages designed to add "color" to a text based game which now serve no purpose in a graphical one. I anticipate a major overhaul of all of the messages once we finish the UI design.
I also started looking at audio resources to add to Conquest!, such as alerting a player when they are attacked or when they find a magical item. I haven't moved forward with this yet as there is still much work to do on the graphical side. Follow the journey on Facebook or Twitter. Until next time, I hope to see you in the game. Happy Holidays! It has been an exciting year for Conquest!. It started out in March with an email suggesting taking Conquest! mobile and is now a working Unity client ~75% complete. To think that this time last year a graphical client client didn't exist at all and the server hadn't been worked on since 2005 is amazing. I anticipate launching 1.0 of the client in the spring of 2016. Huzzah! Since my last post Krees and I have hit several major milestones. Chief among them, completing combat. All of the other work to this point is to prepare a player to attack others. During combat, each player may have up to 4 armies participating as well as ships. This brought challenges in how to effectively display the information while keeping it legible. We divided the results into three tabs: Spoils, Enemy Troops, Casualties: All of the information is displayed and allows a player to quickly ascertain the losses and gains and jump to other parts of the game. Troops can be selected to view more information, such as combat attributes. I decided not to clutter the screen with the enemy's formation; this can be viewed under subterfuge. Eventually battles may be animated this will suffice for a 1.0 version. Chat was another major accomplishment. Conquest! began on IRC and chat was an integral part of the game. When Conquest! moved away from the IRC platform this functionality had to be replicated and so the server now supports a rudimentary chat client with global and alliance channels. While not as rich as some chat clients it allows players to quickly communicate with one another. During the course of play, Conquest! will make announcements to the world, such as battles, promotions and demotions, and Housekeeping. These messages are available under the chat window as well; the messages below correspond to the screens above: There were several additional enhancements made to the client. In the lower left of the screen is a portrait of your advisor. This used to bring up a small window to view announcements from commands. On the suggestion of a tester this was made into a full-size pop-up. Additionally, I moved messages from being displayed in the advisor window to the active window. I also tightened up the way the client moves between scenes as events occur to save user clicks. Finally, I went through the earlier screens made in Unity and matched the design of the later screens to ensure continuity.
We also made good progress on Questing. In Conquest! there are seven quests players may undertake, from fighting highway robbers (the in-game tutorial), searching for loot, or fighting a barbarian horde. The design calls for a map with several locations: your current city, dungeons, wildlands, etc. with each representing a quest a player may undertake. All of the client code is complete but the graphics are still in progress. We should have this done for the next post. The server saw many enhancements as well, including shortening some of the tutorial messages, the removal of two commands ("search" and "password"), and collapsing several messages into one. I look forward to 2016 and the 1.0 launch of Conquest! mobile for Android and iOS platforms. Follow the journey on Facebook or Twitter. Until next time, I hope to see you in the game. Over the last couple of weeks, Krees and I completed Subterfuge. This is one of the most important areas in Conquest!, as it allows players to view the information regarding others. It was challenging from a design perspective because it combines information from several screens into one. Lets dive into the details. The first screen is the landing page, which sets the mood and allows players to Spy, Hire a Spy, or Perform Espionage. Players can only have one spy at a time and are can only be hired in cities which have a spy market. In addition to using spies, magical items and certain classes have similar capabilities. All of these options are handled in this one area. Eventually I could see using different graphics to represent class abilities but these will suffice for now. These screens use the same scroll motif used extensively in the client, so there were no challenges implementing the overall design. Displaying the results, however, is where we had to get creative to display all the information while making it usable. Here is the Overview tab, which combines information from the HUD, Royal Vault, and some miscellaneous information (Liege, Alliance, Spy, Fleet). The row of "shield" icons are the player's badges and will be replaced with distinct icons (on the roadmap once we finish other sections of the client). This is new functionality, as badges did not even exist when we still used text based clients. Here is the Army tab, which combines Combat Stats, Settings, and a page similar to Move Units: I was able to re-use the method for generating a formation based on the string returned from the server, which aided in the development of this page. Clicking on a troop icon brings up a new page which shows the individual details. In Conquest!, there are six different abilities troops may have, in addition to attack/defend statistics: Ambush, Multiple Attacks, Range, Regenerate, Shield, Swarm. Some troops have these abilities innate, while magical items or artifacts can grant them. Additionally, these statistics and abilities can differ between a player's defense and campaign army. All of these details are captured on this page. This is the same screen used to display a player's own troops (under Move Units). Espionage allows you to perform a wide variety of missions against another player, ranging from burning crops to stealing magical items. These missions do count against a player's attack total but allow you to gain assets without combat. I'm especially excited about the two missions added this year: Forgery, which allows land to be taken, and Raid, which allows you to steal magical items from a player's vault. As the design of subterfuge completed, the population screen was refreshed to use the same graphics: This screen shows 10 random players on the same continent as your player and is the primary way other targets are found. A pop-up menu here allows you to jump to the combat or subterfuge screens or use a magical item on the other player.
Server side changes from the past couple of weeks including breaking out troop abilities into individual parameters. Before, the server would send one comma delimited string representing the abilities. This was fine for text based clients, who would just pass that string along to the user, but puts undue burden on a GUI client trying to figure out which icons to display. Incidentally, I have not retro-fit the reference Windows Forms client I made earlier this year so it is now acting a bit squirrely. Up next, we are going to work on the Class and Hero icons. These will not add new functionality but continue to enhance the overall experience. Once those are done we move to the cornerstone screen, Combat. 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
December 2023
Categories |