I've recently become quite interested in conversions between video games and tabletop games, especially wargames.
I've been recruited by a large publisher to propose a book about wargame design that will first be about video games because that's where the big market is. On the other hand, there aren't many video games that are real wargames, at least in the definition I'm going to use, which requires games where reasoning is the primary requirement for winning the game, as opposed to the athleticism that's necessary in shooters and real-time strategy games. In fact, the book will probably be called “Strategic Wargame Design” because I need to limit the topic, so as to cover it reasonably in not much more than 100,000 words. Tactical games, whether video or tabletop, will be practically excluded. E.g. miniatures will get about 500 words in the entire book.
So I was happy to find that Shenandoah Games was at WBC. They are group of people who have been involved in tabletop games for many years who decided to form a company to make video games that are essentially conversions from tabletop games for the iPad. Why the iPad? First, it's a very large market. Second, it provides a convenience of use that attracts many people and is particularly suited to the kinds of short session games that are now very common in the video game world, where you play a game for 5 minutes and then do something else and then play the game again for 5 minutes, perhaps later in the day or on an other day. Their first product is a Battle of the Bulge game. (World War II is as popular as all other eras and settings for wargames altogether.)
The company actually creates a paper version of a game before they program it for the iPad (and some iPhones). Unfortunately, this means that the strengths of the computer for realistic wargames are ignored. For example, the computer is obviously stronger for fog of war than the tabletop. It is also stronger for command-and-control simulation than the tabletop, because the computer can keep track of details that would be onerous for tabletop players, and that ought to be hidden from the players. But there's always a dichotomy in wargames between what's actually realistic - war is a “big mess” - and what's fun to play as a game. Wargame players like to control what happens, they like to feel that they succeed or fail because of their own actions. Yet in war there's an awful lot of chance, as epitomized by the poem about a nation being lost for want of a nail in a horseshoe. So we can present the wargame player with a big mess that he tries to sort out, and that might be attractive to the improviser style of player. But for the planner style of player (more in the chess player mode) this is absolutely horrible. Perhaps that's one reason why I prefer strategic and grand strategic rather than tactical games (for the most part - I like old D&D), because as you go to a higher scale there's less messiness.
Perhaps I ought to explain what I mean by "messy". In a real war, a commander barely knows what's going on within his immediate sight. He doesn't know how well his units are going to actually act under fire, he doesn't know where most of them really are, he doesn’t know where the enemy is for the most part, he doesn’t know how well the enemy units are going to react under fire, he doesn’t know how well his commanders are going to follow orders, he doesn't know how well his commanders are going to react to changed situations when they receive orders that are an hour old or a day old, and the situation is changed from what the overall commander understood - or he never understood it to begin with owing to all these limitations.
It's one hell of a big mess, and I haven't even thrown in supply problems and problems of cooperation with air forces and navies and large-scale units that are not under the command of the particular general. Successful generals have to be very flexible, though paradoxically they need to plan a lot before the action. And to be successful they need "Yomi", the ability to read the minds and intentions of their opponents. Yet this is not what the minimax player is particularly interested in, and frequently is not what the planner is interested in.
(For more about styles of play see my book, or read an online version: http://fortressat.com/blogs-by-members/3216 )
Shenandoah chose to be able to create a paper prototype that would be very closely emulated on the computer, despite the limitations this imposed on the computer's ability to reflect the reality of the big mess. In Battle of the Bulge there is no fog of war, there is no calculation of movement of orders and successful or unsuccessful understanding of orders, of orders getting lost, orders being ignored, subordinates being insufficiently competent (or quite brilliant), and so forth that would emulate the reasons why command and control problems occur. Instead, they try to emulate the way a commander may not be able to control everything by using “activations,” but these are activations that the player chooses rather than activations determined by pulling random chits out of cups or being dealt random cards. So in each day of the Battle of the Bulge, the player chooses in his turn one area that has not yet been activated, then he can move all of the units in that area wherever they choose to go. Battles caused by the movement are then resolved. A random interval of time passes and it's the opponent's turn to choose one area and move. No area can be selected more than once in a day. The command and control difficulties really come into it because of the passage of time after each move. The day may end before all the player's units have been able to act.
The game includes supply lines. It also recognizes that the Germans literally ran out of gas and reflects that at the appropriate time, by choosing a German unit that cannot move that day, and it recognizes that the weather changed and made things very difficult for the Germans owing to Allied air superiority.
The other advantage of this limited activation design is that there is relatively little downtime between play by one player and play by the other player. It's a back-and-forth choosing of one area at a time and moving a few division- or occasionally regiment-sized units. This also simplifies what the computer needs to calculate, such that the developers have been able to get the Battle of the Bulge to work on iPhones down to the 3GS, with a few minor changes because the small screen. The program also works on all iPads. It's also possible to use the computing power in conjunction with iOS to provide a computer opponent or "AI" for those who aren't playing against another human. The AI doesn't need to deal with much change because the opponent has only been able to activate one area since the last turn of the computer opponent.
This also makes it easy for play through the Internet. A player can take his turn and send it to the Apple Game Center whose use comes free with iOS, I'm told. The turn goes to the opponent's computer where it executes on his iPad, and he can then take his own turn and send it back to the first player.
iPad/iPhone owners are willing to pay much more for apps than Android owners, with less piracy as well. Shenandoah is able to sell their game for $10, more than typical mobile apps but much less than a typical tabletop or well-known video game.
I was able to talk at some length with Shenandoah producer Jeff Dougherty at WBC. They come from the boardgame side and their primary market is boardgame players, although buyers tend to be somewhat younger than the wargamers we see at WBC, and they get more people from the video side than one might expect.
Jeff explained a technical reason why they don't use fog of war. It turns out that the "model view control" method of programming (http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller ) means that it's a lot harder to program fog of war that I thought.
As related to wargames, in this method of programming the "model" is all the information the computer needs to be able to act, the "viewer" shows the particular player what they can see, and “control” is what the player does to manipulate the game. To have a computer opponent you effectively must have a separate viewer for the computer opponent, because otherwise it uses the model itself, and then has access to information that a player shouldn't have. In other words, if you use fog of war the programming becomes more complicated.
A Complete Digression:
Some readers might be interested in the following. The first draft of this post was "written" as I was driving from WBC to my home in southern North Carolina. I dictated it to a Sony digital voice recorder that has been recommended for use with my Dragon Naturally Speaking voice recognition program. When I got home I transferred the file to my desktop, ran it through the transcription program, and then edited it and added to it as necessary. Why would I do this? Well, when you become a senior citizen your efficiency in simple tasks like typing begins to deteriorate. In addition, I have arthritis in my fingers, which is a big part of the problem. Though I used to be a demon typist, I would much rather talk to the computer, even to the proxy of the voice recorder, than type. Voice recognition is still far from perfect, even on a quad core I7 processor with 9 gigs of RAM, but it's not too bad. And it is ever so much more relaxing than typing. Last of all, of course, I can't be typing while I'm driving. But when the traffic on the Interstates is light as it was on part of the trip, I can dictate while I drive.
This dictation takes some practice, but I've used Dragon NaturallySpeaking quite a bit. It's not like writing at a computer, however, as I don't see what I'm saying, whereas when I use Dragon Naturally Speaking at a computer it recognizes what I say and shows it on the screen almost immediately. When I'm talking to the voice recorder I have nothing to show me what I've said in the past. But it's still a lot better than nothing.
My brief, free, audio-visual class Introduction to Game Design is now open at
https://www.udemy.com/brief-free-introduction-to-game-design/
My book “Game Design: How to Create Video and Tabletop Games, Start to Finish" is available from mcfarlandpub.com or Amazon (paper or Kindle). (Books-a-Million has an eBook version at http://bit.ly/PQQqh3.) It's currently discounted on Amazon to less than $26 for the paperback.
I am @lewpuls on Twitter. (I average much less than one post a day, almost always about games, not about other topics.) Web: http://pulsiphergames.com/
Comments
Interesting Post
It seem that many of my design are inspired from video games, mostly because I started as a video strategy gamer. I played Mostly turn based games made by Koei that I managed to call database games.
But It seem that converting Vg as BG so is not very easy and it feels like trying to put an elephant in a shoe box. Like I posted in another thread, the first 80% is easy to compress as a board game, but the last 20% takes more time than the first 80%. Which kept me thinking that instead of wasting time compressing further, why not stop now and make a video game instead.
I know that face book games does a lot of that and I find it very annoying. In fact, I don't think a war game is suitable for a 5 min game since it generally involves a lot of thinking and maneuvers. Still, the idea strike me recently that some people would only want to play 5 min, and I was thinking on how I could offer a mode that would last around 5 min. Endep up making some sort of puzzle game (with a war game) called "wrecked it all" where the opponent does not move, but you need to destroy all or the most unit in 1-3 turn with the units you have. So same war game, but with a puzzle approach.
It's a good thing to know. I am currently thinking of making at least 1 video board game using Java with LibGDX which support 4 different platform: PC, Android, HTML5, Apple. Still, you need to buy a monotouch licence for making apple games which I think cost around 100$. But if the sales are higher on apple, it could be worth the investment.
Interesting, some games on XBOX live does not even sell for 5$, cool if a 10$ game on I pad works.
One of the reason I am writting in this comment is that there is an idea of mine which is inspired on the following video war games (Conflict(NES), Advance Wars(GBA), dai senryaku(XBOX-PS2) that I would like to implement it as a video game instead of a board game. And one of the reason is fog of war. I somewhat managed to make a playable game without fog of war while still be annoying to manage dozens of units and dice rolls as a board game. But the idea to use fog of war actually killed the game because I was changing the game too much (that is the last 20% I am talking about). So instead, I thought it could be better to implement it as a video game, while keeping most of the board game compression (for example, unit has only 2 HP marked by fliping the tokens like in a real board game).
Development time is still and issue in making video games, but at least I'll save time wasted on designing that missing 20% to make the game fit as a board game. I think I should try it at least with one video game to see how the experience end up.
I could use the no fog of war solution like described above. One solution is the move 3-5 units per turn. But one of the problem with a modern warfare game is that some unit shoot so far away (ex: cruise missile at 18 hex) that your opponent has simply no chance to avoid such attack but keeping itself out of detection. Scouting units also becomes useless. Then again, you could say that artilery and cruise missile must be able to detect the ennemy to target them, so that would make scouting useful. So the player always see the units, but not the units. maybe that could be a solution to my problem. We will see. (Definitely, I get good ideas while writting)
It reminds me of memoir 44 where you could not play the whole battlefield. The problem I have with that is that sometimes, some units could not do anything for the whole game. They just sat there doing nothing and getting shot which would have neevr occured in real life. This is why I would prefer a move X units per turn. Because you cannot fight on all flanks at the same time, but you can chose which flank is more valuable than the others. The "Conflict"(NES) video game did that, and the "Super conflict"(SNES) maps always had 3 fronts, so when you needed to move 3 units, it was much more convenient to focus on one of the flank at a time, and when you started to gain control on it, switch your actions to another flank.
Turn based strategy should be easier to implement online. It's a matter of if you display all the opponent's moves at the same time, or if you display them while is he doing them. The first will create less synchronisation problem but will take much more time to resolve than the second one. One of my friend that multiplayer network conenction is the biggest source of bugs and problem in video game programming. So simplifying it or removing it is the best solution.
I am not quite sure about it, it's just a matter of passing a parameter to a class that display a different map and return different value when queried according to what the player can see. So it's 1 map generating 2 different output when asked to do so.
Interesting, I sometimes find that writting takes a lot of time, so talking could go faster. Except I am not sure if I could explain correctly everything in one stroke. Else the other problem I can see is how good it can recognise my english since I am a not a native english. I remember that some words in skyrim were not recohnised with the XBOX Kinect. Else one of my friend use that to take notes when cooking, but they does not get transcripted like you did, so no voice recognition.
Here is an old picture of the war game I had in design that I might release as a video game instead. The unit design looks similar to "Conflict".
http://bgd.lariennalibrary.com/uploads/Mainsite/GameIdea/GameIdea2010032...
Enjoy!
Funny
Developers are often quick to blame the architecture when a problem is difficult to solve. I think fog of war makes for a completely different approach to pathing and decision making for the AI, but MVC is not the root cause of programming overhead. The data that represents knowledge of the map state (i.e. under fog or not) belongs in the model, not the view. Placing the AI on the other side of a view is an amusing thought exercise.
Sounds like a cool book project. I'll look forward to it. I've backed into a similar place not for wargames, but family games that I first started thinking about for the iPad and realized that design and playtesting and that ball of wax is much smarter starting with a physical game. As I have content that will be on cards in the board game, the potential to manage an unmanageable amount of cards on the iPad is the root appeal.
Another interesting angle is whether/how something can transition from board to stand alone app to freemium app.
About the fog of war
Another comment about the fog of war. I think it is an hard thing to implement in a video game but not for MVC reason. I posted a thread a while ago asking for insight:
http://www.boardgamegeek.com/article/13069252#13069252
The problem is that fog of war movement require validation while moving on a certain path. Here is the explanation:
When there is no fog of war, you show the player all the possible options where he can move to and then move the unit to target destination. The validation process is done by showing all the possible movement choice. During this process, you can apply any rules like zone of control, stacking, etc.
With fog of war, either you move a unit 1 hex at a time to update the possible movement options of the player after each hex moved, but that has the drawback of making movement tedious.
Or either the player give you a target destination which has not be validated. Not you cannot only validate the destination because that would revel the ennemy position, but if the destination is blocked by other units, movement would not have been possible. So you must trace a path to destination and then move the unit 1 hex at a time and validate the movement. Stop when the unit reach destination or when a collision occurs with another unit or with for example an artillery attack in overwatch.
That is that makes fog of war much more complicated to manage. This is why I came up with a solution of displaying ennemy units without showing their information so that movement validation could be done first. For infantry I came up with the idea that ennemy units can stack and that are not blocked or does not trigger a zone of control. Prefenting the need to validate infantry movement and be capable to have a 100% stealth unit.
Else, I am thinking more to remove fog of war, but make long range unit only target detected units.
I am not sure, but I think the best games to develop as a video game are games with a simple rule set but that could be expanded with a lot of data. CCG seem to have this structure. The basic rules are relativaly simple, but you can devellop tons of cards afterward. Still, CCG can be a trap because new cards could require additional coding, but you have a working game relatively fast making the release of the game easier.
With my war game above, I wanted to use a similar technique. The core of the game is in fact moving, producing and attacking units. There is not that much other rules to it. Not all modes could be implemented at release, but modes are generally different map setup and victory condition, they don't require much additional coding. But the nice part is that the game can be easily be increased by simply releasing additional maps for any of the modes. I don't need tons of maps to make the game playable, and adding modes and maps does not add much extra programming.
So it could be another method to keep the amount of coding low while offering a lot of gameplay options and replay value. Personally, I consider that the programming aspect is the most complicated part that requires most of the developement time. By keeping that as low as possible could be the key to make a video game in a short amount of time. So short rules with few exceptions.
For me a great design is the
For me a great design is the big part. Programming is the lowest of my concerns, because I've been doing it for so long.
Yea, no CCG for me, cards are rule light and variety is more about flavor and replayability over complexity.
Follow-up
It seems to me that small screens are better suited to map games than to card games. Especially on smartphone screens, the cards are too hard to see unless you look at only one at a time, and one of the benefits of real cards is that you can see several at a time. The zooming capability of small screens suits maps/boards better.
Tablets and smartphones are also more suited to two-player games than multi-player, I think.
I am looking at some quite small, generic 2-player wargames of different kinds that I designed 30+ years ago, and find that they might be more interesting with fog of war than they were without.
The 3 turn based video
The 3 turn based video strategy games I know that implemented Fog of War are:
Advance wars (GBA) (not always fog of war)
Dai Senryaku (XBOX, PS2)
Commanders: Attack of the genos. (XBOX 360)
You might want to take a look. Attack of the genos is the only game where you cannot see the layout of the map. So you need to explore a bit like war/starcraft. But the worst part is that attack of the genos does not remember what you have previously explored.
fow
There are lots and lots (hundreds, most likely) of computer wargames that implement fog of war. More of them than do not really, even games that are not quite wargames like Civilization have fog of war, and of course almost all real-time strategy games as well. All games I can think of do interrupts movement if a unit tried to walk into a previously hidden enemy unit (often with some bad thing happening like being ambushed). Works very well and there is nothing difficult about implementing it.
There are even some interesting ways to do quite good double-sided fog of war in board games. They could have done something really simple like a block wargame, or just play with inverted cardboard counters, to get 80 % of the benefits of fog of war for 2 % of the cost, and still be able to playtest on the table-top.
As has already been said, that MVC excuse is rather lame. The game world being simulated, with units moving around and what the AI does etc etc belongs down in the Model, far, far away from the GUI. I'm a bit suspicious about how well those guys have separated the GUI from the game engine itself though, because if they did they would have an Android port out by now. My guess is they have Apple-specific and GUI-related code everywhere and are locked in pretty hard to that platform (but I hope I am wrong).
That Bulge game looks great though. Bought it for my gf's iPad and played it a few times. It just happens that I am allergic to Bulge games in general. If they make one with a more interesting theme I will probably play that more. The lack of fog of war is no big problem because so many allied units start off-map anyway and since I'm too lazy to keep track of enemy reinforcement schedules anyway they all appear out of nowhere to surprise me.
BTW lewpuls' book is very good. Lots of very useful, practical advice. Also very interesting to read about that speech-to-text-tool.
Quote:There are even some
I have not thought about this, but block games simulate my idea of seeing enemy units location but not their information.
I don't know what they used to code, I know libgdx use java which makes it very portable. In fact only 6-12 lines of codes needs to be added to support another platform. Maybe not all libraries/framework have such flexibility.
larienna wrote: I don't know
I don't know what they used to code, I know libgdx use java which makes it very portable. In fact only 6-12 lines of codes needs to be added to support another platform. Maybe not all libraries/framework have such flexibility.
Actually Java (including libgdx) requires a great deal of magic and commercial third-party hacks to run on iOS. It is not a very portable language compared to something like C or C++ or JavaScript (or by extension any portable language that is easy to integrate in one of those three; which is unfortunately not Java until there is a small and free JVM comparable to the Lua runtime). My choice for any boardgame conversion would be JavaScript+HTML5 (or one of the many, many free game engines that run on top of that, to make it a bit easier, like one from this long list: http://html5gameengine.com/).
Seriously off-topic though. :)
Interesting to read about
Interesting to read about unsuitability of Java for portability, since the whole point of Java, originally, was to have a highly portable language, something that would work on "any" platform. Which contributed to how slow the language runs.
Shenandoah may not be interested in porting to Android. Android users are in general much less willing to pay for apps, and more likely to pirate them. So they may have decided it just isn't worth the trouble.
Quote: It is not a very
I read everywhere that C++ is not that portable and the whole point of using java for phone app is that it allows the app to run on different hardware instead of recompiling it for each phone model out there which would be unthinkable.
I also want to make development easier and faster by not using C++ to avoid all the problems that comes with it. Apparently, the designer of C++ said something like:
"It easier to shoot yourself in the foot when using C rather than C++. But when you do shoot your self with C++, it's the whole leg that explodes"
As for Apple app requiring more stuff to run, I don't know. From LibGDX website, you only needed a monotouch license. But I have not put my hands into libgdx coding yet.
------------------------------------------------------------------------------------
Another point that I seem to forgot to mention about complete fog of war games is that most of the time, it implies reloading a game at least once for each new map. It has happened to me multiple times when you do not know what kind of opposition to expect and place yourself in a position beyond recovery forcing you to restart the game. This can be pretty frustrating to users especially those with short attention span. While if I could see the position of the units by not know their information, it would reduce the possibility of placing yourself in a bad position because I know where the ennemy is.
Another thing I thought for a perfect fog of war was that the infantry does not appear on the map which would require a perfect forg of war. But since infantry does not move a great number of space (probably 2-3), I could ask the player to move the unit 1 space at a time and it would not be as painful to do than other units who could move 5+ spaces. It would remove the need to apply a path to movement.
I am currently playing Dai
I am currently playing Dai Senryaku, so all the problems with fog of war comes up to my mind. One of the problem is the possibility to move a unit in a certain position where you thought it could attack but end up not beign able to. The problem is that you cannot take back your move because you already have revealed the fog of war at that step.
In advance war, there is no problem because most unit attack adjacent units, and all units with range attack can only attack OR move. So they already know in their starting position if the ennemy can be targetted.
In dai senryaku, some range units can attack AND move, but there are also various levels. So you could place your unit on the wrong level and not be able to attack your enemy.
This is why it could be important before validating the movement to show the possible units that could be attacked when moving into that location. This will prevent the player from doing a useless movement.