Skip to Content

Would you design a strategy game in digital format if you could do it?

7 replies [Last post]
larienna's picture
Joined: 07/28/2008

I just want to make a small survey here. We talked recently that board game design was more complicated to publish. People have less money, board games are more expansive, physical resources are thinning out. I somewhat visioned this situation would occur when I got into the hobby.

From a certain point of view, board games are strategy game the majority of the time. There are some exception like party game, dexterity games, etc. But I think most people in this forum are doing strategy games.

Now lets dream a little bit, and let say there would be a digital platform (a set of tools and software) that would allow you to build your own strategy video game. And let say this platform is accessible enough for you to understand and use it

Would you make the switch and start making strategy video game instead of board games?

Still, some of your ideas could remain playable as a classic board game even if they have a digital implementation. That could solve most issues listed above since production cost are very low and it does not require physical resources.

That was my objective, but if other people are willing to share the same objective, I could try to figure out a way I can make a platform accessible to everybody. That would be the hardest part, and it could take quite some time. Training could help when non-intuitive interface is required. At least, from what I understand (from a previous thread), people want to learn as little programming as possible.

If such platform exists, then we could all transcend to the digital world. As for marketing the game, there are few good strategy games on the video game market. So even with below average visual, we could offer at least a good and solid strategy game. Also with automated playtesting, it's another tool that can be used to validate that our design is solid.

I want to know your thought about it.

Rick-Holzgrafe's picture
Joined: 07/22/2008
A few such platforms already exist

A few such platforms already exist. Two that come readily to mind are Tabletopia and Tabletop Simulator (TTS). I use TTS for prototyping because it's easier and faster than building physical prototypes, and I can playtest online without having to physically gather local people. TTS is a Steam app, and costs users and developers alike a one-time $20 cost; but any given game within TTS can be kept private or made public either for free or for paid play. Tabletopia is similar, but it costs more for the developer: last I looked, you need an on-going subscription to have more than one design in Tabletopia. (I have a couple of dozen designs in TTS, and can add more any time; this is the main reason I use TTS rather than Tabletopia, it's cheaper.)

I'm not real familiar with Tabletopia; I haven't used it. A drawback of TTS is that it does not enforce rules (any more than a physical game on your kitchen table does) and it's kind of clumsy to use mouse-and-keyboard to drag pieces around, flip cards, and so on within the simulated 3D environment. It takes new users a while to learn the gestures, keyboard commands, and shortcuts.

Services like BoardGameArena (BGA) do enforce rules and their user interface is very polished and easy to use. But BGA is not an "open" platform; you can't just sign up and start submitting your own designs. And even if you could, I strongly suspect that it takes a lot of technical coding expertise to make a game for BGA. By contrast, there is a learning curve for TTS but it's not that bad. You can write code to automate some actions, but for most game designs you don't have to. Once I have my artwork assets ready, I can usually put up a brand-new game in TTS in just an hour or two: it's easy to add boards, pieces, decks of cards and so on. As a design continues to develop and change, updating the game on TTS is quick and easy.

I've considered designing my own general-purpose, customizable boardgame app. I've even taken a shot at building one a time or two. But as an experienced professional software engineer, I can tell you that it's not a simple, short, or easy project—and I wasn't even trying to make mine playable over the Internet; I just wanted a prototyping tool for personal, solo testing. I never finished any of those attempts.

After saying all that, here's my answer to your question: Yes, I'd like to be able to market my designs in digital form. But I'm aware that that wouldn't solve all the problems involved in publication. If I don't sign with a "real" publisher, then I have to do all the game's art myself, or hire a no-doubt-expensive artist. Marketing is also a hurdle, because there won't be a publisher going to conventions and showing off the game or buying ad space on BoardGameGeek—I'd have to do all that myself, too. On top of that I'd be responsible for tech support whenever a user thought the game wasn't working right: I've self-published a number of apps (some games, some tools) and I have to handle tech support for those. Digital publication, sad to say, is not a magic wand.

X3M's picture
Joined: 10/28/2013

Well, I am kinda helping a bit.

And my main focus is on giving advice on most things. Also offering idea's of how to do things, solve issue's or just expand the horizon of options that a game can offer.
Call me "one of the gatekeepers".

It all starts with idea's.
And if you put them into a board game or a video game. Well, this is up to the one having the idea.

The main difference is that a video game has much more to offer. There are more mechanics that can be applied. The numbers can be more complex. The pc can actually act as a game master if you will. Guiding the player(s) in whatever they are playing.
While in board games. You often are very limited in certain mechanics. You are also limited in the numbers that are applied. But more often, the guiding of a game has to be done by a rulebook and thus the players themselves.

Now the con of video games is indeed. The programming and design.
You need to learn this.

I once had a video game, created together with my cousin (13 years old at the time).
He actually did the programming while I guarded the rules and numbers.
We had 100 players roughly and the game was playable for 2 seasons. Then someone discovered a game breaking strategy. My cousin had no time any more for fixing it. And everyone simply stopped playing it.

We had plans for a second version, allowing more etc. But clearly.... we needed the time and motivation.

So, if you want to make a video game, you need a renewed motivation. Motivation for actually learning your stuff. Motivation for monitoring the progress closely and make alternations when needed.


If you have spare time right now....
Put everything asside that you are working on. And google a bit.
See what languages are out there, easy to use for beginners.
There are programs that help you creating a new game.

It is important to get one that allows you to create board games as well. And once you created a "board game". You could publish this.

Now for a more fun part. See what can be changed in that board game. And slowly turn it into something that can reduce the input of players. What I mean is that a player doesn't have to place a pawn from A to B anymore. But this simply happens.
The moments that a player needs to do something is actually decision making.
It doesn't matter here if it is turn based or real time.

The players makes a decision to move from A to B.
The player should not be forced to DRAAAGGGG something from A to B. This should go automatically.

Maybe I am making this a tldr again. Just let me know what else you want to know, ok?

pelle's picture
Joined: 08/11/2008
What I would like (and this

What I would like (and this has been discussed in the past, at least on the bgg design forum) would be a standard game module format that would allow for game components to be easily imported into any virtual tabletop, but also easily printed somehow.

Maybe there is some hope that the format VASSAL4 settles on will do that. If components are of high enough quality for a modern screen, there is a good chance that they can also be printed for print'n'play (or exported to send to a real printer for a published game) so if there is only a good standard format for how to package images describing game components (that would work for 80% of games... I would be fine with there still being many games that have weird components that can not be included).

It is a bit of a problem now that game modules for digital games are tied to specific applications, are difficult (by design!) for users to export or import, and that there are no really easy way to convert between printable files and digital modules. I know some applications like nanDeck has some support for exporting to digital tabletop formats, but not sure how easy it would be to get an entire toolchain set up to make all components for a game that way. A long time ago I had broken support for VASSAL-export in my Inkscape Countersheets extension (but that could only handle components like cards and counters and other sheets of flat components, with no way to specify game boards or custom dice or any other components many games need).

Anyway my interest in a tool like what larienna is asking about would probably be close to zero. I would very much prefer something I can run offline, that is easy to integrate in scripts and build-systems (the way my Inkscape extensions can run from command-lines and scripts). Unfortunately the way things often go when trying to make something "accessible to everybody" is (with no exceptions that comes to mind) pretty painful to use and quite user-hostile (data locked in some cloud-service, no easy integration with version-control etc etc) so not for me.

larienna's picture
Joined: 07/28/2008
Your point of view is

Your point of view is interesting, it could interesting to download a game that is ready for vassal and printable as PnP at the same time.

I never thought about this, not sure I have a clean solution either. I was thinking about for example, having a digital and printable format, but I would have manually built both.

So far, one way that could be done this is having some sort of export system using the same game. Think of it like using a word document as core format, and exporting to TXT or PDF depending on your needs.

So my idea would be for example to have all the card information in a database. The digital version simply read the database, and display the card information the way it wants. But another program could read that same database and create printable cards in SVG. Another program could generate images for vassal, etc.

Only the digital version needs to apply the rules of the game, other formats is basically pictures to print or display on the screen. So it`s just data, no need to encode rules. A layout definition might be necessary to determine where you put the information on the card.

questccg's picture
Joined: 04/16/2011
Comment of FORMATS... Just because the "vision" feels incorrect

Instead of a MS Word document which is proprietary, I would use a JSON file which is compatible to many programming languages especially Python, Java, PHP and Javascript with HTML5. It's used for web application and is a easier to understand TXT format than CSV files (for example). That could have a FILE-based solution which doesn't require a DATABASE. Not all application require the use of a database. In this case of a "Game" with cards and component, JSON files may be simpler to use and could be edited manually (if necessary).

Now if you are talking about LAYOUT files, I agree that PDFs would be the most acceptable format. I can bring those to Staples and print them one page at a time ... (The tricky part is two-sided pages) But the problem is "cardstock", you don't have 320gsm cardstock with a blue or black core at Staples. So maybe you would need to use SLEEVES or the PDF files are meant to be used by OTHER PRINTERS.

Lastly any format for "printable" CARDS themselves is debatable. If it was JPEG, things like gradients and custom effects per layer are lost when generating the JPEG files (the layers are lost not the effects). While SVG file preserve layers they don't work as well as JPEGS when it comes to gradients and layer effects. SVGs are like Illustrator files which work good with things like VECTOR LOGOS and limited amount of colors for things that DO NOT have "gradients". Because SVG = Scalable VECTOR Graphics... This to my knowledge is the OPPOSITE of what you would want on the FINAL format even if layed-out in a PDF... Would be JPEGs in CMYK format and the PDFs could also be in CMYK and not RGB.

IDK the CARD FORMAT is "tricky". You may need to use a TIFF format which is BETTER than JPEGs and preserves LAYERS like SVG files. I've never really worked with TIFF files... Only because it's like one of the LEAST KNOWN formats for RASTER images...

Would be more complicated probably than the XML of the SVG file format...

Anyhow just sharing some thoughts on the FILE Formats.

Note #1: Why JSON??? Well it's good for "web applications". So if you are going to use the WEB and Javascript and HTML5 ... It's the best NATIVE format. And it strips away the NEED for a database. So it is a FILE-based SOLUTION which is editable MANUALLY if you are defining a bunch of cards and don't have a "editor" for each card. Using TextPad or Notepad++ it's much easier to WRITE a JSON file and use copy & paste for each card.

PDFs are self-explanatory when making LAYOUTs. The work well at ANY printers shop including Staples. But like I mentioned, you may not get the GSM quality of the paper and a core to go along which may be available at some LOCAL printers and NOT Staples.

Lastly the TIFF format is used in PHOTOGRAPHY a lot. Because it preserves high resolution images with compression but NO LOSS of quality. So for photographic images, TIFF is the go to format and I think that the format is best since it also preserves LAYERS too!

Note #2: Your APPLICATION has to be a WEB APPLICATION if you are going to play VERSUS an opponent. If not, you'll have to do all the manual communication over a networked socket and go into low-level coding for transmission of data and handling all the I/O manually.

I'm not too familiar with C#... But it may be an alternative since UNITY uses it for the 3D Rendering Engine and application development (especially web apps too)... So maybe C# might be the better language IDK. I know JAVA... Not C#, I come from the opposite side of the pond. So no UNITY for me!

Note #3: Maybe you SHOULD explore UNITY as the platform for the "development" of this HALF webapp/HALF desktop application. I mean that's what UNITY is used for ... Making things 3D and playing versus an opponent. A web app coded in UNITY with C# might be the path of least resistance since UNITY also need to manage 3D Models and Textures ... And you can code 2D Scrollers in UNITY too... So it must just various FILE FORMATS... Although this kind of project is OUT-OF-SCOPE for me, I would guess that UNITY would be the BEST "platform" since a lot of the thinking has been done and you can code in C#...

questccg's picture
Joined: 04/16/2011
Just as a follow-up

Magic: Arena (MagicA) from Wizards of the Coast (WotC) uses UNITY to power itself and you've seen that it is a CARD GAME within a COOL 3D Environment. So MY BET would be that UNITY would be the BEST platform to create something GENERIC as a platform for making GAMES...

Just google: "is magic arena coded in unity" and you'll see that WotC plan to use UNITY even more for their online game.

And you will be generating ONLINE games. So I would use something like UNITY or UNREAL (2nd choice uses C++) and develop it using one of these platform tools.


Note #1: TableTopia is developed in UNITY too... So my guess the BEST platform for YOU is UNITY. I'm pretty sure about this... Or a HYBRID like a WEB APPLICATION for assets and UNITY for the GAME itself.

Note #2: TableTop Simulator ALSO uses UNITY too... Was harder to Google for this information but I finally found this nugget:

What engine does Tabletop Simulator use?

We recommend activating Scaling, JPEG textures and Draco compression when exporting as we will be bringing the GLTF file into the unity engine to finalize it for Tabletop Simulator.

So UNITY seems to be the PLATFORM used by all... And therefore I would BEGIN with UNITY as the platform to CODE your application/game simulator.

larienna's picture
Joined: 07/28/2008
Word was just an example of

Word was just an example of how you pass from a source document to different exported documents.

No I would not put source game data in a Word document.

Sources could be relational database, json. Target could be SVG for the printables, and PNG for the digital components. There will probably be images(png, jpg) as sources for artwork.

Syndicate content

forum | by Dr. Radut