Download Game


Built using the Unity game development engine, Space: CQB is a science-fiction themed digital collectible card game (DCCG), a style of game that features large collections of cards for players to collect and use to compete against others, where the player competes against an AI opponent of varying difficulties in order to acquire a variety of cards to add to their collection. A match is comprised of a best in three series, where the first player to win 2 games wins the match. Each match is played on a randomly selected board, where each board has a different environmental modifier that can affect both player and AI.  Players will be able to have a maximum of three custom decks so that they can strategize deck builds to account for these modifiers.

How do you play?

When starting the game, the player will be given to option to load an existing account, which tracks a player’s collection and deck builds,  by providing a username and clicking on the login button. If starting out for the first time, the player can click on the new player button, input a username, and select from the available starter factions. After either creating or loading an account the player will be given the choice to play a match, manage their collection, or quit the game.

The management screen [4], will display on the left the cards remaining in the player’s collection that have not already been assigned to one of the three decks. The right side of the screen shows the currently selected deck with a dropdown menu at the top that can be used to swap between decks. By double clicking a card in either the deck or the collection, the card will be moved to the opposing side. Between the collection and deck displays is a series of statistics about the currently selected deck.  When ready to proceed, the player can press the ready button at the bottom of the screen.

When choosing to play a match the player will be presented with a screen that shows them the chosen board and modifier, as well as letting them choose the deck they would like to play with. Once the player has made their selection, they can press the deal cards button to begin the match.  A match is made up of three rounds where the opponents will alternate turns after making a choice of playing a card or passing the remainder of their turns for the rest of the round.  Each player has a points counter that sums the unit power of each of their played cards. A round is won by the player with the greater total points. The winner of the match is the player that has won two rounds, or the one with the greater number of rounds won by the end of the three matches.  The winner is rewarded with a card that has a greater chance of being a card they do not already have, while the loser is given a chance to win a card that grows until they win a match.

The cards are broken up into five classifications, each with a limit to their base maximum power: Support(0-3), Fighters (1 – 6), Corvettes (7-10), Frigates (11-15), and Capital (15-20). Each class of card will have cards that have some special ability, either a buff to friendly cards or a de-buff to opponent cards.

Build Tools

I built S:CQB using Unity, having had prior experience with the development engine I was more comfortable using it instead of trying to find and learn a new engine. Unity is a robust development system that allowed me to keep a logical structure within the game scenes as well as having numerous compatible GUI (graphical user interface) elements available through the Unity Asset store.

I made use of Paint3D as well GIMP to make modifications to the ship art and other visual elements that make up the current visuals of the cards. Paint 3D was used to extract details from images that I had wanted to change, see the change in color to the power and abilities tokens on the cards [2]. GIMP allowed me to combine visual assets into single images as well as changing color values. 

Visual Evolution

Development Progression

The development of Space: CQB began as an offshoot of a previous card game framework that I had begun in Software Engineering, a recreation of the Witcher 3 card game Gwent which also influenced many of the gameplay mechanics of SCQB. Initially, the game was intended to feature multiplayer gameplay. Unfortunately, this implementation became untenable, leading me to decide to take a step back and fully implement a single player experience, from which I could begin adding multiplayer, time willing.

The first major milestone after the change-over to single player was spent creating a Game Master script that did as the name suggests, it is responsible for determining in what order actions are supposed to happen, with a little time spent for modify a few key pieces of script to not require networking features.  By the first group demo, a player was able to place cards onto their dedicated playfield and have the opponent respond. While a player could finish a match, it was not guaranteed to work 100%, issues would crop up with the player’s turn state not changing when and as it should [1]. At this time, it was pointed out to me that the GUI, graphical user interface, assets, (i.e., buttons) were not following the aesthetics of a futuristic space game that I was intending. As such, on the days that I was not able to get satisfactory progress done on the coding aspect of the game, I focused on acquiring new visual assets and modifying them with (Paint3D and GIMP) to function as I needed [2].   

The next milestone that I began to focus on was the ability for the player to have a persistent account so that any additions and modifications to their decks/collection could be tracked. During this sprint I went down three, possibly 4, different routes trying to figure out a way to have an account behave the way I needed it to throughout the entire game. I ended up settling with an account object that acted as if it were static, having the system destroy all other iterations of the object after the first one was instantiated. With how Unity handles this, if I had a scene with an account object when the game began, the first account would persist throughout all the scenes with the original information. In conjuncture with the account object, I decided on using Unity’s native JSON libraries to transcribe into a JSON file, all the information in an account: player name, cards in collection, and cards in all three decks.  To facilitate the player being able to have an account, I had to create a login screen to allow for account retrieval and creating [3], as well as a main menu [4].

Following persistence and its ability to record changes made to decks, I focused on deck management. I created a management screen [5], which lets the player see the cards they have left in their collection, and the cards that are assigned to each active deck. This screen reports on statistics about the currently selected deck such as: current max base power, number of cards currently in the deck, the number of cards with abilities, and the number of cards without abilities. The deck size limit is enforced in this screen, ensuring that a deck is large enough to meet minimum and maximum requirements.

The second to last major milestone focused on fully implementing environmental/card modifiers, updating the visuals of the cards for better visibility, and creating a second faction worth of cards. [7] is the original version of the cards created during the prep stage but due to input from play-testers, the cards went through a re-design which spawned three views of each card [8]: back, playable, and manage. Playable views are what a player sees during a match, while manage is seen in the management screen. By the end of this sprint, 2 minimal factions were implemented [9] [10].  After the last group playtest, ability description pop-ups were added to the playfield which would explain the modifier when the cursor hovered over a card or board token.

To finish the last sprint within the project’s timeframe I focused on creating a rudimentary decision tree for the opponent player. Before, it would draw a random card from its hand; the expected outcome from the new decision tree would be for the opponent to react appropriately to the cards in its hand and to the cards that the player has put down.

Continued Development

The next developmental sprint that the project would go under would be the reintroduction of networked communication allowing for player vs. player matches. Originally removed due to the lack experience with Unity’s networked features and only the most basic underlying gameplay mechanics, it was decided that single player would be the first focus of the project.

In addition to multiplayer, minor milestones would be set for cards, the game boards, and audio. For the expansions of the cards, I would focus on the introduction of a greater variety of cards, card rarity, hero cards, and faction leader bonuses. The boards would see a type of minor environmental modifiers that would be shared between the boards, and that could be active in addition to the board’s primary modifier. The audio milestone would be focused on implementing audio assets for special effects and a soundtrack.


I would like to thank my capstone advisor, Dr. Eric Kaltman, and the rest of my fellow capstone group. Your feedback and playtesting highlighted major areas needing improvement. I would also like to thank my playtesting group on discord, your criticism helped refine the aesthetics of the game into something I wouldn’t have been able to do on my own. Finally, I want to thank the Unity support community that always had an answer to even my most obtuse questions.


As anyone can imagine with the continued policy of distance education implemented due to COVID-19, there came plenty of obstacles that students needed to adjust to or overcome; I was no different. This previous semester brought with it plenty of issues that I needed to deal with ranging from personal to academic. When focusing on this project, the development saw few positive impacts while the negatives added another layer of complexity.

Within the limited number of positives that COVID brought to the development process was increasing the number of available hours in a workday, as well as increasing the number of play-testers that I had access to. While I created a work schedule for the week, primarily 3-4 hours a day from Friday to Sunday, the asynchronized nature of most of my classes this semester allowed me to work on the project whenever I had a breakthrough, instead of having to wait till I could get back to my main computer; eureka moments happen. Unfortunately, being forced to stay at home brought with it cabin fever; as such I began joining more discord groups so that I could socialize with people to the best of my ability. From these groups I was able to put together a cadre of play-testers to give me feedback on the game, as well as finding bugs for me to address.

While there were some positives due to COVID for the development, the negatives effected the development more than I would like to admit. As with the aforementioned cabin fever, there were days that I had to force myself to work on the game due to lack of motivation; this led to more areas that I would have to revisit to fix mistakes and bugs. The single largest negative that came from COVID is the lack of face to face interaction with my advisor and fellow developers. I feel that this disconnect during our gameplay demos and check-ins lost us, as developers, important feedback, and experience.  

The development of my game progressed due to a couple practices that saw me through my biggest roadblocks. The first was that I worked on it during short bursts, the previously mentioned 3-4 hours a day with a breaks during, but always with a clear goal of what that work period was to accomplish, even if I was not able to complete it. The second was that I celebrated completing milestones, giving me a sense of accomplishment so that I would tackle the next with enthusiasm. The next was letting my subconscious work on problems that I was currently stuck on by going for a run or doing something not at a computer, not sitting there beating my head into the desk. By following these practices, and a few others, I feel that I have accomplished a great deal this semester. While I regret not being able to implement networking, a more diverse collection, and audio, I feel satisfied with what I have created.   


Jason Isaacs · May 8, 2021 at 4:02 pm

Hi Roger,
Nice job on the look and feel of the game. The graphics are amazing. Do you plan to seek a career in game development?
Prof. Isaacs

    admin · May 8, 2021 at 6:55 pm

    Thank you for the comment. While I am looking more into other fields, video games have been a passion of mine since I was a kid. In the past decade I have progressed from playing them to creating modifications for them and have recently branched out into trying my hand at creating one from scratch.
    Roger Lorelli

Leave a Reply

Your email address will not be published. Required fields are marked *