Stew’s CS Blog

That’s right folks, I have officially joined the Online Trading Card Game Maker Capstone Project! What does this mean for you, mystery person reading this blog (aka fellow student and/or grader of this assignment). It means you can burn your Magic Cards and give your Pokemon cards away to the neighbor kids. You can stop wasting all your time pursuing the Gwent side-quests in Witcher, quit considering to buy that fifty-dollar Yu-Gi-Oh! trading card game for Switch, and stop getting your butt kicked by pay-to-win gamers on Hearthstone. It’s time to stop playing these corporate card games and start making and playing free, open-source, and paperless TCG’s!

To kick-off this new blog dedicated to chronicling the epic journey of our intrepid Trading Card Game Maker makers (I’m gonna get a lot of mileage out of the meta-jokes around creating a system for creating a system for creating cards used to create decks to create…. and so on…..), I wanted to take a few paragraphs of your time to talk about why this initiative is a cool idea. There are two perspectives to look at for this project: the User’s experience and the Developer’s endeavor. Before our team of developers embarks on the mission, I’d like to take this moment to imagine what this could be, both in terms of what we create and how we create it.

The USERS!

Ah, to code perchance to dream. If you are like me, then you’ve played your fair share of trading card games. But have you made one? I’ve tried before, but dang is it a lot of work! The part that I love about trying to invent a game is coming up with the rules, the subtle interactions and the epic cards. I’m not a great visual artist myself, but I always dream of being able to get my visual-arts-gifted friends to draw the dragons and aliens of the fantasy battlegrounds I want to create. This project would streamline the process, enabling a simple interface. The game creator menu could offer a card design area, where you set the features of the card (its cost, effect, type, stats, etc). The card design area would allow loading images for the card art, and placing functionality text as well as personality text.

There would also need to be an interface for defining the mechanics of play. Maybe there are some pre-made default templates for building your ruleset (like a Magic-like template that defaults to turn-based play, life totals for players and basic phases to turns). There can also be a more “build from scratch” system where you specify every detail, maybe in your TCG there aren’t turns. Maybe action opportunities are triggered by events and cards rather than turns and phases. Furthermore, you could set the mechanism for obtaining cards, and deck building. Is your game one where every card is available to all players? Is there some collecting dynamic to consider? What are the rules around building decks?

Finally, and most importantly, an interface for playing the games you create! Imagine being able to define the rules, craft the cards, and then click the play button. Does the system provide AI opponents or is it strictly PvP? Maybe you designed a Slay the Spire style PvE TCG! The possibilities are endless, and we probably want to provide an interface for customizing the gameplay in addition to an interface for engaging in play. All of the above brings us to the primary topic of this blog: developing the software!

The DEVELOPERS:

We haven’t spoken a word to eachother yet, so obviously this is all purely speculative, but what might the design and development of this project be like? It seems inevitable that we will want a GUI frontend of some sort, will it be browser based or a free-standing app? We will need complex databases too, that store a variety of entities, from rulesets and customization to card design and peoples’ decks and collections. Will we use SQL style databases, or the wild west of noSQL databases, or even just text files of csv masquerading as databases. How will we host the GUI and the backend? Will they be monolithic and fully integrated or built on a microservice architecture with RESTful calls to an API from an indepent UI?

Will we make a web-based app dependent on a cloud-based server, or perhaps we make the entire software downloadable, and allow users to host instances of this software locally or through their own servers. Are we building a highly adaptable, customizable piece of software that we we let others customize and adapt as they please, or do we build something curated and controlled by our team so that its features and functionality remain streamlined? Do we run the whole project as Free/Libre Open Source Software or do we keep it as our perfect little pet project, safe from the contributions of the wider community?

If you want to know the answer to these questions, like I do, you will have to stay tuned for the posts to come on Stew’s CS Blog! Now officially dedicated to documenting the story of creating an Online Trading Card Game Creator.