EDIT: This content has been moved to the wiki. Please see this article: http://wiki.warlight.net/index.php/Creating_single_player_levels
Phase 22 is the biggest release of WarLight since it ported to Flash! First, business:
WarLight will be going down on Wednesday, January 5th at 1am PST (9am GMT) for up to an hour. Please plan accordingly for any fast games that may get interrupted during this 1-hour window.
During this time, WarLight will be upgraded to Beta Phase 22. Once the deployment is complete, you can view all of the changes on the Change History page.
Personalized Game Templates
Once phase 22 is live, whenever you create a customized game, WarLight will ask you if you’d like to save your game settings as a template. You can then use that template to easily create games with the same or similar settings.
Not only will this ease the burden of creating new games, but it will also allow you to share your settings with other players. Each template will have a URL associated with it that you can give out to let other players use your templates.
Phase 22 will also allow you to create new templates/games with the same settings as any existing game, whether they were created with a template or not. This allows you to easily create rematches, or create templates from the games created by other players or games you created before templates were available.
Being able to save your game settings as templates is great, but when combined with custom scenarios, phase 22 really opens up a lot of new doors.
Once phase 22 is live, game creators can elect to forego the built-in map distribution system and enter, territory-by-territory, exactly how they want the map to be distributed.
This gives game creators an incredible amount of power, and opens up all new styles of gameplay. For example, game creators could:
- Give players handicaps, such as starting one player with fewer armies. This is useful for introducing WarLight to a new player, or when veterans just want to give themselves additional challenge.
- Hand-craft a strategic map so that bonuses that start with wastelands in them are worth additional armies per turn, giving incentive to take down the wasteland.
- Finely-tune a 1v1 map by picking which territories are available for players to pick, or making less-desirable bonuses start with fewer neutral armies, or placing wastelands in strategic positions.
- Create a Godzilla scenario where one player starts with 10,000 armies, and 20 other players are teamed up to take them down.
- Many more – the possibilities are endless!
Design your own single-player levels
If you think about custom scenarios and game templates, you’ll realize that they give you the power to do everything the current single player levels do. In fact, the existing six single player levels are being made into templates!
This opens up a wealth of possibilities. Perhaps you’ve always wanted to play level 1 reversed – where the AI is about to get Europe and you start in Australia. Or maybe you want to try the Europe challenge as Russia instead of Britain. These templates can even be used in multi-player, which means you could do the Europe or Insane challenges cooperatively with a friend!
Not only can you customize the existing six single player levels to your heart’s desire, but you could even make your own from scratch, and share them with other players using the templates feature. I may run a single-player level design contest, where the winners can have their levels included into the game.
This post continues revealing new features in Phase 21. Read Part 1 if you haven’t.
Real-time games get a clock!
Another addition in Phase 21 is a timer that counts down in the top-right corner of the screen:
The timer counts down to the boot time configured for the game, so it’s always clear how much time you have before you risk being booted. The timer will continue to run even after submitting your orders, that way you know if you have enough time to re-do them if you notice a mistake.
While the clock is a small addition, just increasing awareness of the boot timer should go a long ways towards reducing the number of times players are booted unexpectedly.
Phase 21 will bring the addition of the blockade card, which you can think of as a less effective abandon card. The blockade card works much like the abandon card, except the blockade card happens at the end of your turn instead of the beginning. This means any attacks, airlifts, or other actions happen before the territory changes into a neutral and increases its armies.
The advantage of using the blockade card in lieu of the abandon card in your games means that, on offense, you won’t have to worry about your large stacks getting devastated. Since the blockades happen after attacks, your offensive stacks can freely move around without hitting any unexpected neutrals.
The blockade card is great for people who like the abandon card’s ability to block off pathways around the map, but don’t like the abandon card’s ability to decimate opposing armies. Since the latter strategy is so powerful, it means that in some cases, abandon cards would mostly be used as a way to take armies away from your opponent by abandoning the spot they were about to attack. This meant that there were few abandon cards left over to create blockades.
The blockade card is a little more difficult to use than the abandon card. When playing a blockade card, it’s very important to ensure you still own the territory you’re blockading at the end of your turn. If you lose the territory you played the card on, the card will have no effect and you don’t get the card back. Therefore, it’s recommended that you play this on territories that you know you won’t lose, such as those that don’t touch an opponent or that are sufficiently defended.
Even though Phase 21 is mostly about open games, the blockade card was thrown in since it was fairly easy to add. It should be a great addition, and I think it’s far better suited for 1 v 1 matches than the abandon card is. In a 1 v 1 match, the ability to take your opponents armies away with a well-predicted abandon is extremely powerful. This puts a lot of emphasis on predicting where your opponent will attack, which I don’t like. I’m going to make a big 1 v 1 tournament using the blockade card to test this out – post a reply if you’d like to be invited.
Wrapping up the last big feature of Phase 21 is automatic games. This is an experimental feature designed to help new players have fun with multi-player right off the bat. WarLight will automatically create games made up of open seats, and ensure new ones are created whenever the existing ones fill up. This means there will always be a game available for new players to join.
This also demonstrates part of the reason why the Open Games tab was created (covered in part 1). Since there will always be at least one open game, it doesn’t make sense to advertise them on the top of the My Games tab like they were before.
For the initial release, there will only be three automatic games. These were picked to give the feature the best chance of success – if these work out well, more may be created in future releases. If they don’t work out well, they may be removed.
Two of them are Strategic 1 v 1 games – one real-time, and one multi-day. 1 v 1 games should work well for automatic games since they’ll fill up and start fast and collusion isn’t possible. The third is a multi-day newbie game, which uses open seat prerequisites to ensure that only new players can join. Since veterans are kept out, the skill level should be more appropriate, helping new players to ween themselves onto multi-player.
It’s an open game extravaganza! First, business:
WarLight will be going down on Wednesday, December 15th at 1am PST (9am GMT) for up to an hour. Please plan accordingly for any fast games that may get interrupted during this 1-hour window.
During this time, WarLight will be upgraded to Beta Phase 21. Once the deployment is complete, you can view all of the changes on the Change History page.
Open Seat Prerequisites
Once Phase 21 is live, WarLight will allow game creators to specify prerequisites that players must meet in order to join open seats in their games.
Here are some examples of prerequisites game creators could specify:
– Players must get booted in fewer than 10% of their games.
– Players must have completed at least 10 games.
– Players must have an average move speed of less than 1 hour.
– Players must have been a WarLight member for at least 30 days. (no newbies)
– Players must have been a WarLight member for fewer than 30 days. (newbies only)
Players that don’t meet the requirements you set won’t even see your game, and therefore won’t be allowed to join it. This will help players get matched up with the kind of players they’re looking for.
Separation of real-time games and multi-day games
Until now, WarLight multi-player games have been mostly geared towards play-by-email speed of play. These kind of games usually play one or two turns per day and play out over the course of a few weeks. However, some people prefer a more rapid style of play, where games are played in real-time.
Both styles of play are supported by WarLight, but there is room for improvement in the current model. For example, new WarLight players often have a hard time distinguishing between these two types of games. Veterans know to check the boot time when evaluating whether or not to join a game, and the low-boot-time warning certainly helps, but these are cumbersome to discover as a new player.
Most players have an expectation for how fast multi-player games will move before they enter. Either they are used to single-player games which play out quickly and therefore expect real-time multi-player games, or they see the e-mail notification feature and expect a multi-day game. Sometimes, new players get into a game that isn’t the speed they expect. This causes a bad experience for everyone involved – either they get booted if they’re waiting on an e-mail of a real-time game, or they whine about the turn not advancing when people don’t play immediately in a multi-day game.
After Phase 21, WarLight will categorize games into one of these two categories. This will help set expectations for new players. When players create a new game, they will actually be asked whether it is real-time or multi-day:
This will constrain the boot times that can be used, and also help players pick the correct type on the new open games tab.
Open Games Tab
The little advertisement on top of the My Games tab will be replaced with a dedicated tab to open games:
The first time a player navigates to this tab, WarLight will give a short explanation of what real-time and multi-day games are and ask them which they seek. This will ensure that players always get the speed of game they’re expecting, and should cut down on some of the boot issues players run into in open games.
The My Games advertisement worked well for drawing players attention to an open game, but it wasn’t very usable since it didn’t show any settings about that game and wasn’t practical when there were lots of open games. Further, the whole idea of not appearing when there were no open games created a lot of confusion. When there were no open games, it was impossible for new players to understand how to go about joining open games – this was a very frequent pain point. Further yet, open seat prerequisites make calculating your open games a more time-consuming operation, and it doesn’t make sense to do this on every refresh of the My Games tab.
More features in part 2 of this blog post!
Beta Phase 21 is still a ways away, so don’t get your hopes up. But I wanted to share one change I made tonight since it’s on the top of my mind now.
Under the multi-player tab, there are these two pesky tabs named “Current Game” and “Current Tournament”. I’ve never been happy with them.
There are several things I don’t like about them:
1. They don’t show up until you first visit a game or tournament. Typically tabs don’t dynamically appear, so this is probably a bit jarring when it’s noticed. (Although I bet most people don’t notice.)
2. Their names are not descriptive. Sure, Current Game makes sense when you’re looking at a game and you see the tab is highlighted. But when you’re on a different tab, seeing a tab named Current Game doesn’t make any sense. Long-time players will remember that this tab used to be called “Last Game”. This has the opposite problem – it makes sense to go to the last game you played, but if you’re looking at a game, why is Last Game highlighted? At one point I considered dynamically renaming it, but I decided against it in fear it would be even more jarring.
3. All of these tabs take up extra horizontal space. With both Current tabs, the Sound link, and the Design Maps tab (which only shows up if you’re a WarLight map creator), you need a browser 1144 pixels wide to see everything! This provides a poor experience for those in low resolutions. It’s important to remember that 1024×768 is still a very popular resolution. But it’s not really as bleak as it sounds, since most players won’t have the Design Maps tab or be in tournaments.
The horizontal space issue is fine as long as I don’t need to add a new tab here. But a feature I’m working on for Phase 21 calls for a new tab. Uh oh. Adding more would make it far too wide. Something’s got to go.
I thought a lot about how I could save space here. I could move Create Game to be a button instead of a tab (that would make it more in-line with tournaments, which is a plus). I could move Design Maps somewhere else (it doesn’t really make sense to be under multi-player anyway). I could abbreviate “Tournaments” (why must that word be so long?). I could squish everything together. All of these solutions have their own unique problems.
But ultimately I just kept coming back to the “Current” tabs – they’re taking up almost 40% of the space on that tab bar, and I’ve never been happy with them for the reasons cited above.
I thought about getting rid of them completely since they’re not strictly necessary to play. However, they are useful in a few situations. The time I use them the most often is when checking out a bunch of games in a tournament. The “Current Tournament” makes it easy to switch back and forth.
So maybe keep “Current Tournament” but ditch “Current Game”? It’s not as needed, but I still fear is that people have grown accustomed to using Current Game. I know I have. As a species, we suck at changing our habits, so I’d like to keep both if possible.
In the end I decided to move these out and make them buttons instead of tabs:
Making them buttons instead of tabs may not seem like a profound change, but it actually has subtle advantages. These buttons can be hidden when their click would not make sense – both before you visit a game/tournament, or when you’re already looking at a game/tournament. Hiding tabs wouldn’t really work out since shifting all of the tabs around would be too jarring.
Further, since they can be hidden instead of “activating” when visiting a game/tournament, their text doesn’t suffer from issue #2 described above. This will make it clearer to new players exactly what this does, and how to use it.
Best of all, it frees up valuable space under the multi-player tab. Yes, this does create an even worse horizontal space issue on the top tab bar. However, that’s not nearly as bad in this case, since neither of these buttons are strictly needed to play the game. If we have to push something off, it’s much better to push off “Recall Last Tournament” than “Create Game” since the latter gets used far more often. Even in 1024×768, you can still see the “Recall Last Tournament” button enough to click on it. You may not be able to read the words, but it’s still functional and you can still tell what it does by reading the tooltip text.
While it’s not perfect, I’m happy with the change.
One of the new features that was introduced yesterday was Banking Boot Times. This feature replaced the old Sliding Boot Times feature. While they act fairly similarly, Banking Boot Times gives more control and should be much easier to understand.
The problems with Sliding Boot Times
Let’s start by understanding what the problems were with Sliding Boot Times. Sliding Boot Times averaged out a player’s play speed for the last 10 turns, and then compared this average with the boot time to determine if a player was bootable.
One problem with this approach is that it could cause a long delay if a quick player stopped playing. For example, if the boot time is set to 24 hours, and a player takes their first 10 turns quickly (say, within an hour) then they would not be bootable for over 10 days! While it’s good to reward a player who plays quickly, giving them 10 days in a 24 hour game is too much.
This naturally leads to making your boot timers lower than they would be without Sliding Boot Times. For example, if you set an 7 hour Sliding Boot Time, this makes the maximum boot time becomes 67 hours. This is more reasonable, although still a tad high. But the bigger problem with this strategy is revealed in the early turns of the game. If the game happens to start right as someone is going to bed, they’ll be bootable before they wake up. A 7 hour Sliding Boot Time works in the long run, but is too low for the early turns.
To combat this, Sliding Boot Times gave extra leeway for the first ten turns of the game. Basically, it “filled in” any missing data points with half of the boot time. While this solves the above issue, it also created a lot of confusion around the feature as players often saw early boot times that were significantly higher than they expected.
I thought for a while about how to solve these problems. Some good ideas were suggested on the forums, but I also wanted to make sure that the system was drop-dead simple to understand. I wanted to avoid anything with complex math formulas, since I want players to always feel like they know exactly what is going on (principle of least surprise). This is one place I failed when I first made Sliding Boot Times.
Banking Boot Times solves both of these issues. When banking boot times is enabled, whenever you take a turn under the boot time, you “bank” some of that time. You can then spend some of this banked time to go over the boot time in subsequent turns. The game creator can also configure what percentage of the difference that players bank.
Let’s look at an example. For now, let’s assume the game creator configured it to bank 100% of the time. If the boot time is set to 24 hours, and Sally takes her turn after 20 hours, she’ll bank 4 hours. This means that, for the next turn, she could wait until 28 hours have passed before she’ll become bootable. Any time she waits over 24 hours, she eats into her bank. So if she takes 27 hours on the next turn, she uses three of her banked hours and her bank is reduced to one hour.
You can always see how much time a player has banked by opening the nudge/boot dialog and clicking the “speed” link.
The game creator can configure what percentage of the difference is banked on each turn. For example, if the game creator sets the amount banked to 25%, then Sally would have only banked 1 hour instead of the 4.
Since players gain banked time at a reduced rate, and spend it at the full rate, this makes the swings in maximum boot time much smaller. This solves the first problem stated above. Game creators can use this to configure exactly how much swing in the minimum / maximum boot times they want to allow. Doing this made the early-game leeway provided by Sliding Boot Times unnecessary, so that’s gone completely. This solves the second problem stated above.
One way at looking at this is that Banking Boot Times configured at 0% is the same as not having the feature on at all. On the flipside, Banking Boot Times configured at 100% is the same as the old Sliding Boot Times feature (minus the early-game leeway). Since you now have the ability to specify the percentage, you can decide how much you really want your boot times to be affected.
Also, note that any games that previously used Sliding Boot Times were converted to games using Banking Boot Times at a 50% bank rate.
I’m open to any opinions about what you think about the feature, or how you’d like to see it improved. Let me know!
Hurray for new features! First, business:
WarLight will be going down on Thursday, November 25th at 6am PST (2pm GMT) for up to 2 hours. Please plan accordingly for any fast games that may get interrupted during this 2-hour window.
During this time, WarLight will be upgraded to Beta Phase 20. Once the deployment is complete, you can view all of the changes on the Change History page.
What’s in Phase 20, you ask? Well, here’s a sneak preview…
AI replaces booted/surrendered players
You asked for it, you got it! The #1 voted feature on the UserVoice forum is finally here! Game creators get two new options:
– Players turn into AI controlled players when booted
– Players turn into AI controlled players when surrendered
Game creators can choose one or both of these. These are useful for a few scenarios. For example, in big FFA games, an early surrendered player previously meant that adjacent players now had an advantage. Not only do they not have to worry about that player invading them or continuing to grow, but sometimes they can easily sweep through and gain new land. When AIs replace surrendered players, this somewhat negates this advantage. Of course, AIs are unpredictable (and almost never better than a human player), so it may also cause some fun chaos
Also, it’s important to note that the AI really does take the place of the player that it replaced. This means that if the AI somehow ends up winning, that player gets credited for a win. This is useful in another scenario, the one where you’re cruising over the planet and on the verge of winning, but – oh no! – your power goes out or you can’t stay to finish out the game. No problem! If your opponent boots you, they’d still need to beat your AI replacement. If you really were on the verge of winning, your AI will finish the game out for you with ease, which we’ll all appreciate when it means we can move to the next round of a tournament.
Don’t worry, I haven’t forgotten about that other pesky UserVoice item, “AI replaces booted players. Game is over when AI is the only opponent.” Sometimes you don’t want to have to finish off the AI manually. For you, game creators have yet another new setting:
– AI players surrender when only one human remains.
When this is enabled, the AIs will pop up surrender boxes as soon as the game gets down to only one human player (or one human team in team games). The remaining human can choose to have fun slaughtering them, or just accept the surrenders and end the game right away.
But wait! There’s more…
Of the features that aren’t in the game yet, this is the most-asked-for small feature in the history of WarLight. Some people really don’t like having to wait for their surrender to be accepted. Well, good news! You can now configure your games to have surrenders happen instantly, without needing to be accepted by anybody.
There’s a few other new nuggets in this release too that will remain surprises for now.
I often get asked what kind of technology was used to build WarLight. WarLight’s server components are written in C#, and the Flash client is written in haXe utilizing Adobe’s Flex 4 layer for layout / buttons / sliders / checkboxes / etc. All backend data is stored in a Postgresql database running on Ubuntu Linux, while the website is served from IIS 7.5 running on Windows Server 2008 R2, both hosted on virtual Rackspace Cloud Servers.
WarLight’s maps are originally uploaded in SVG format (as every map designer knows), but they’re immediately converted by the server into a custom map format built for WarLight. This format is optimized to be quickly loadable by Flash, which makes loading games much faster than if they tried to render out the SVG directly.
WarLight’s communication protocol is custom written, as well as its object serialization protocol. After all, WarLight was started as a for-fun hobby project, and re-inventing the wheel is fun!
I’m a big believer in automated testing, and I’ve worked to have thorough coverage for WarLight from the very beginning. Before every release, WarLight goes through an extensive automated test pass that takes several hours. The idea is that the tests cover as many possible use-cases as possible. Any time a new bug is found in WarLight, I add a new test to cover it and this ensures the issue never comes up again.
Some of these tests use the Selenium web-testing framework to actually automate the browser and the Flash client. Here’s a short sample of what some of these tests look like when they’re running:
Having the WarLight testing being automated is essential. Due to the vast number of settings (and permutations of those settings) that WarLight games can have, it would be nearly impossible for me to do big changes or to refactor code and still be able to release WarLight with confidence that the game will still work. However, with the tests I can simply run them all and get a level of confidence that all of the features work. The tradeoff is that this makes each feature more time-consuming to add, since I not only have to write the feature but I also have to think up and write all of the tests that ensure the feature works.