Salvaged journal of the unfinished Project Redline

The following are a series of posts on my first attempt at a physical card game. The game remains unfinished, but I've decided to save the posts out of... nostalgia? Not quite sure. Regardless, the following is everything relevant in order by date.

8/25/18:

I learned 3 key things this past week:

1. Lists of publishers accepting submissions are surprisingly unreliable. A Google search turned up better results for publishers than some of the lists I found.

2. Some of the publishers who are accepting submissions won't even look at your game unless 4 or more people can play it.

3. Many publishers expect a video submission from a playtest session.

Because of point 2 and 3, the lack of response I've gotten from the places where I did submit Redline (literally 1 response), and the fact that my game incorporates 4 decks, I'm stepping back from submissions for the time being. I don't think I have an excuse for focusing only on developing a 1v1 rule set when the potential exists for 4 people to play at once. Plus, I want to see what a 4 player free for all looks like.

I've recently acquired a tripod for my cellphone. The plan, moving forward, is to check all my cards for 4-player compatibility and then film a test session. I will also be filming and posting an explanation of the game rules.

In unrelated news, I may try enabling the Wix social features. Maybe. Depends on how much I get done this weekend.

 

 

 8/31/18:

I'm afraid a critical issue was found in my most recent playtesting. The Speed Track, a component I added to the game to help control explosive Speed and make the tracking of everyone's status easier, makes the game completely unfun when everything is going your way. I've made some changes before to try and compensate for this. However, one of my testers suggested I simply cut the component completely from the game, and I decided to give the alternative a shot.

My cards currently aren't balanced for the new system I have in mind. However, the test I ran under the improvised system was immediately fun in a way that felt far more natural to the game. So, I've decided to make a new batch of cards that will be targeted at testing this new idea.

If all goes well, I'll re-balance all 4 of my driver decks and put out a video next week of the game in motion.

9/3/18:

I've encountered the worst problem a game could ever have. The new system I designed to track Speed in Fight to Redline isn't fun. It's keeping track of large, constantly shifting numbers in your head. I didn't notice the lack of fun so much in self-testing, but playtesting made it impossible to ignore.

I going to take something of a break. I say "something" because my brain will not stop crunching away at the problem. I'm just going to focus on other things for a week and then come back. This is the only method I can think of to rediscover the fun.

At the very least, I now know a system that tracks speed and only uses cards will need alot more work or another component. A token of some kind, like a special slide, seems like the way to go. I'll try something new next week.

9/10/18:

Today I was reminded of the value of writing out your thoughts. The following post was originally going to be completely different. However, in writing out an explanation of why my awesome new speed track is fun I realized I was literally explaining why you should be enjoying my convoluted idea.

Sometimes, players have to be shown how a game can be fun. However, in most cases, if you find yourself explaining why a mechanic is awesome it may not be. This is obvious, or it least it was "known" to me before now. Yet, here I am.

Redline is back, but currently on shaky ground. The problem is the Speed system I came up with, and that I'm calling the Speed Track.

The 1st problem is how attached I am to the Speed Track. I don't know of any other competitive card game like mine that lets you stack cards and isn't designed with Poker cards in mind. The Speed Track took Solitaire card stacking and made it awesome. It totally solved the problem of needing to include a clunky chart for who is currently winning into the basic package. This is not actually a problem, per se, and is a workaround for needing anything more than cards to play my game.

The 2nd problem is how hard it is to teach the Speed Track system. Even after my testers understood the new card layouts, they were confused by the new requirement that you exchange cards if you're giving someone a determent.

The 3rd problem is that the Speed Track doesn't fit Redline in its current form. There is no real reason why, in a race, a Player would need a catalogue of the actions of his or her fellow racers at their fingertips. Reading the Speed Track slows the game down and causes alot of confusion for new players.

The 4th problem is that the Speed Track expands the gameplay space and adds choices without being any fun to interact with. The solution I found to make Redline fun again was to add a shared Speedometer that tracked everyone's progress toward a goal value. In the process of creating the Speedometer, I made the Speed Track redundant.

All 4 of the above problems have forced me to realize that I designed a fantastic solution for a problem I don't have. This is a depressing realization, but a necessary one if I want to keep working on Redline. I have resolved to strip out my Speed Track and set it aside for another game with a theme more fitting of the mechanic.

There is one positive: I have finally accepted the Speedometer as a good solution. It's easy to use, the movement of Player markers across it provokes engagement, and the mechanic is fun. I already know this from my previous meter solution.

My post may be a little rambly as I'm a little tired. However, I wanted to get this posted for another reason: How to Eat Carrots.

Anyone who was paying attention may have noticed a game pop up on this site called How to Eat Carrots. Carrots was a silly one-off I made for a board game jam and almost decided to put serious work into. However, my feelings for Carrots were a result of premature excitement, and after testing I've decided to set the project aside.

Someday, humans may again seek to devour sentient carrots. However, that day is not this day.

9/17/18:

Fight to Redline is fun again! Even better, the playtesters I found went straight to a 2nd match without having to be asked. It's clear that the current version of Redline is more fun than any past version.

My problems moving forward are: working with playtesters to try and figure out if any of my other systems are getting in the way of fun, card balance, card text, a stupid-proof rule sheet, rebuilding 2 Driver decks to fit the current system, work on balancing Jupiter so he doesn't burn out too quick, rework Old Art so he's not too slow, and card formatting. These are alot of problems, but anything is better than stripping out and reworking my Speed mechanics again.

The biggest problems at the moment are card text and formatting. The following card illustrates this:

To be honest, I have no intention of investing too heavily into the art or design of my cards. I'm planning to sell this game to publishers, and I've been assured by multiple sources (The White Box Essays, The Board Game Design Lab podcast, members of the Austin Board Game Designers and Playtesters group, along with other sources I can't recall off hand) that investing in art would be a waste of money for me.

However, over the course of playtesting, the above card (and others) proved to be a problem because the current design obscures too much information. Part of this is due to the card format, which was designed for another version of the game, and part is due to the text of the card itself. I tried to adapt the card format to the game's current version, but I'm not happy with the result.

I hope to have at least 3 of these issues (reworking of my Driver decks for Lucy 22 and Sudo and TanTan, redesigning the card formatting) done by the end of this week. I'm anticipating the card text will take longer to fix. If I can get a rulesheet done as well I'll try and get some video from my next playtest.

Oh yeah, and my game is fun again!!!

9/23/19:

I've re-designed the layout of my cards for readability, re-constructed my 2 secondary Driver decks, and run a 3-player test. There were issues of balance and grammar. However, the biggest issue by far was that my damage system presents confusing information to players. To explain why, I'll have to explain a little of my thought process behind the game.

I see the player's Hand as the Driver's thoughts, the Field as the gadgets and maneuvers of a car, and the Deck as the possibilities of the car body. Further, damage was a system I wanted in the game from the start. So, damage currently works by forcing a player to discard a number of cards equal to the damage they receive.

The damage system by itself makes a kind of intuitive sense that my testers easily accepted. The problem lies in determining the impact of any attack.

As an example, there's a card in the game that deals 3 damage and costs 10 speed. After the cost of 10 speed is paid, the target of the 3 damage discards 3 cards from a deck that may have 25 cards or less at the time of the damage. There is no knowing what the cards will be until they are discarded, and there is no way to count the cards left in the deck without both players physically stopping the game and counting.

The end result of calculating damage in cards discarded from a deck, outside of a video game (where the number of cards left in a deck can easily be displayed), is only a vague sense of danger. Receiving damage doesn't feel bad, as I had worried it would, but at the same time dealing damage doesn't actually feel that good either. Damage, as it was made clear to me by my testers, doesn't convey clear information and occasionally even feels superfluous.

So, now I have to make a change to a system that I wanted in the game from the start, but that is actually unrelated to the primary system of speed. If my theme were a strong one, I could use it to guide me on how I move forward. Unfortunately, my guide for Redline is just speed (partially to avoid focusing too much on my inspiration, the 2009 animated film Redline), and speed is more a concept than a theme.

I've got 1 system that works, and alot of thinking to do. I feel like this would be a good point to set the Redline project aside for a little while... but there's still something there. Something gnawing at me. I want my speed card game.

 

 

9/30/18:

After considerable thought, I've decided to completely change the theme for Redline. The name of the game will also be changing. I have a name in mind, but I'm going to let it sit a week to see how it feels.

The direction for the theme is currently future dystopia. Wait! It's not like all the other dystopia, I swear! I'm planning to focus on the young of a mutated, largely destitute minority population living in a city with history that stretches back centuries. Basically, a city with alot of car scrap lying around and a group of kids desperate and ingenious enough to tinker with it.

I arrived at this theme while exploring what specifically interests me about racing. I knew I didn't want to capture forms of legal racing, and American street racing hasn't inspired me.

It was thanks in part to the following video that I found my new direction: (shot of high-way street racing, no longer available)

 

The video above captures my imagination by portraying a form of racing where obstacles are constantly present in the road. Traffic, composed of unwilling participants, controls and impedes the progress of the racers. When traffic is present, there seems little need for damage (push forward vs you might be targeted and killed) or an obvious blue-shell-like mechanic (something that just blindly punishes the lead player). The challenge is in figuring out how to use traffic as a control mechanism.

My first attempt at designing new mechanics has not gone over well. My first version of Redline used a Distance track, and my second used a Speed track, and I felt the most satisfying system for my new version (v15, how time flies) would be a combination of Distance and Speed. The result was too many moving parts.

I'm going to keep tinkering. I know I've nailed a solid direction to take the game, and there are still alot of things to try. One of my testers suggested dice, for example. Expect an update next week.

10/7/18:

Ok, I'm changing the name and theme of my main game to Psychic Scrap Racers. Psychic, mutated kids in a dystopian future who race scrap on public roads actually makes more sense to me than a bunch of weirdos in the space future or whatever who race cars they have for reasons. A major benefit of the changed theme is that the game itself is making alot more sense.

In my last post, I pointed to a video of racing on public roads as inspiration for my new direction. Testing this week has revealed a purity of focus from this inspiration that I wasn't getting from Redline (2009 anime). The removal of damage systems is freeing.

This is not to say that other ideas have not tried to creep into my design. The version of my game that I tested this week included cards that represented Traffic, as well as dice rolling. Traffic cards, though still an interesting idea to me, added extra rules and were often misunderstood in execution. Additionally, I've belatedly realized that Traffic cards, as I've designed them, existed only to offset the game-ruining effect of the dice.

Dice, by themselves, were not fun the way I was trying to use them. Aside from the Traffic cards, I had no mechanism in place that really benefited from the existence of dice. So, I tried playing a game with one of my testers that had neither dice nor Traffic.

My game without dice, with only the occasional Hot card to add speed, was actually kind of engaging. I was worried that turns where a player didn't gain speed (and there were a few), or lost distance through negative speed, wouldn't be fun. To my surprise, the tester I was playing with insisted he had been having fun regardless, as there had always been something to do.

On further reflection, turns where a player doesn't move or moves backward actually make a weird kind of sense. I've been reminded of a scene in one of the YouTube videos that inspired me, a scene where, for a split second, a racer is forced to slam his breaks to avoid slamming into the back of a slower car. The source of the video, another driver, speeds past his unlucky opponent, capturing an entire few seconds were a car in a race is forced to stand still.

I still believe I'm on the right path. I'm going to cut mechanics, add cards, and hopefully have something ready to test by Tuesday. At the very least, I'll have something ready and tested by next week.

Side note: I was exposed to the surprising difference a few rule changes can make today. The Talisman board game is one of my least favorite games of all time due to pure random bullshit. That's literally what the core of Talisman is: bullshit, due to a high level of negative randomness culminating in adventuring that is more chance than skill. Most runs leave you failing repeatedly because a card or roll says so.

So, imagine my surprise when I got to play a "fun" (mileage may vary) version of Talisman: Runebound. Runebound incorporates many of the same randomness (and a semi-painful board setup) of Talisman, but gives you a choice in your encounters. You're not forced to fight or face anything until you choose to.

I recommend comparing Talisman and Runebound, if you have the opportunity to do so.

10/14/28:

My update is going to be a little short this week. Testing and reworking your game within less than 48 hours, while working full time, is not something I'd recommend to anyone. The short prep time I gave myself plus stress outside the game equals burnout. Still, I did get some good testing in.

Through testing, I learned that I've temporarily lost the ability to create a useful rule sheet for new players. However, I've got a solid page of notes on everything that caused confusion, so I know I'll easily have a new rule sheet ready when I next test. Also, I learned the refinements I made after last week's testing have resulted in a game that's fun for new testers.

I'm positive I'm working with a solid base. After the last 2 versions of this game, just having a solid base is exciting. I'll have more next week.

10/24/18:

Apologies for the delayed update. Between voting, the Austin water authority shitting itself, and various personal issues, I haven't had a lot of free time this week.

I've taken a little extra time in testing my existing system, and the result appears to be a successful backbone for a game. In addition, I'm finally working out the balance of card effects. The Speed, discard, and draw effects are just nowhere near as annoying as, say, a card effect that places 1 player immediately behind another.

The problem now is how to move forward. Different testers have repeatedly expressed how much they preferred the decks to be the same (my 4 test decks have remained the same throughout testing of this new game play system). However, it's obvious that there's not enough randomness to keep the game interesting if it remains in its current state.

The possible solutions I'm wrestling with are:
-Make 4 different decks, each with a hero card, and potentially add in an Event deck for variation.
-Keep the decks the same, add hero cards, add instructions for building decks, and potentially add in another component like a card body.
-Redesign for more randomness.

Of the above ideas, I'm currently leaning most toward keeping the decks the same. The biggest reason for this is my experience with TCGs (Trading Card Games), which often increase the amount a player has to learn by featuring multiple factions. I'm struggling to keep my game simple, so avoiding factions may be the best way to do so. However, there are some problems that immediately come to mind.

The 1st problem is adding rules for deck building. Deck building would occur outside of the main game, and so may be a set of rules that don't distract from the game. Of course, that means I have to add more rules and more complication on what cards are allowed and when. The biggest challenge would become ensuring that players can build a variety of viable decks after learning the game.

The 2nd problem is tied directly into the 1st: adding deck building components makes my game look like a TCG. I don't want to make a TCG. I'm an inexperienced designer trying to make something simple, and a TCG is complexity and business overhead I just don't want to deal with. Additionally, it's my understanding that publishers hate getting pitched TCGs from designers like me.

I've got more to think about. I'll tinker around and post an update next week. Go vote! 

 

11/21/18:

Firstly, I'm going to be moving my usual updates from Sunday/Monday to Tuesday/Wednesday. Most of my updates have been structured around a local board game testing group that meets on the weekends and some weekdays. The weekend meetups are ending, so I will be focusing more on the weekday meetups.

Additionally, I'm hoping to begin experimenting with testing through BoardGameGeek. I'm nervous about throwing my game out into the Internet, but more testing is always better. I'm going to give myself until the end of the holidays, or January 2019, to add some basic art and complete more testing on my own.

I'm currently in the process of gathering clip art for Psychic Scrap Racers. The biggest complaint for the game has been the complete lack of art, and I've had some of the cards in the game long enough to justify adding something. Test cards will remain without art to avoid distracting myself with mindless clip art googling.

The biggest update I have in regards to Psychic Scrap Racers is that I'm adding Event cards back. Event cards were a planned component from the beginning, and they add some of the randomness I was looking for to spice up repeated play. Thematically, I also enjoy the idea of racers encountering heavy traffic, drunk drivers, bike gangs, and more as they illegally street race around a dystopian city.

Driver Identities are out for now. The game has become about your machine, and Identity cards just don't fit when I think of all the yous there could be. I am considering adding vehicle body types, though. Motorcycle vs car vs truck. I'll have to test it.

So, short update today. I had a bit of a crisis of purpose the day after I resumed work on Scrap Racers. I've known that I'm extremely unlikely to release a commercial product before 2019, but for some reason it didn't really hit me until this past weekend. So, I set my Sunday as a free day and just played Dark Souls 3 while I processed whether I want to keep doing this.

I want to keep doing this. Until next week.

11/28/18:

My next bout of testing has been delayed due to the gathering of test images, the designing of a new Distance Track, and the printing of 3 copies of each card for 4 players.

I've purposely put off the gathering of test images, or imagery on cards that helps to convey and immerse test players into the world of the game, as long as possible. Gathering card art is a distraction from designing mechanics. However, now that my mechanics are fleshed out, the biggest complaint I get is the lack of pictures. I love card art, so I get it.

Gathering art for each of my unique cards probably took me an hour. It's good practice to time yourself, at the very least to figure out your overall labor cost once a project is complete, but it was Thanksgiving and I couldn't make myself care. I expected the process to be easy, and I was surprised to find it was not.

The card Rabbit is a rare example of when I easily and quickly found an image that perfectly conveyed what I wanted. I was surprised by how difficult it was to tease compelling racing imagery out of Google's results and, as in the card Played Possum, it was far more common to spend more than 5 minutes sifting through boring results for 1 gem.

On a side note: Played Possum is a terrible name, and I'm very much trying to think of a better one.

There are a few cards where I had to settle for something that is only close to what I envisioned. The above cards, Catch Lost and Active Defense, are a good example of what happened when I wasn't even sure what I was looking for.

Catch Lost is a fun card mechanically, but that image is literally only there because I like it. Active Defense makes some sense (the original image, which I had to slim down to fit, was of a shield. Combined with the snarling, possibly living lion head, the shield seems the very definition of an active defense), but all I get from the splitting head with a skull is a sense of death.

I'm not convinced all of my imagery fits the game, but I am convinced that a publisher will want to change everything I do. So, I'm going to continue focusing as little on it as possible.

The Distance Track took a sizable portion of time because I used its creation as an excuse to experiment with GIMP. Making the Distance Track in Photoshop would've taken me only a few hours, but in GIMP I had to re-learn how to do alot of things.

My current Distance Track design is above. It's not great, but I can't blame GIMP for that. I'm just not an artist.

The most interesting thing about making the Distance Track was learning some of the little differences between Photoshop and GIMP. Photoshop allows for easy layer management, while GIMP requires you to chain layers together for some tasks. Photoshop has tools to generate 2D rectangles and circles that will automatically fill with color, while GIMP forces you to stretch out rectangle and circle selections and then fill them manually. In a word, GIMP has a tendency towards tedious extra steps. However, GIMP is not unusable or particularly awful, and it's free.

I'm probably going to stop paying for Photoshop and stick with GIMP. Maybe. Still thinking about it.

Now, the reason I printed 3 copies of every card for 4 players is because I want to test some deck building. I have this idea of producing more randomness by including extra cards with the game that players can user to mix up decks. Of course, this requires that every extra card add value or be as valuable as the base cards.

I'm not convinced deck building is the way to go. However, testing more cards gets me closer to the original ideal of there being 4 unique decks, and having this as a fall back could only be a positive.

At the moment, I'm stuck cutting out cards. I haven't even gotten a chance to test the game with Events. I expect to have more testing done next week.

12/4/18:

Have you ever played the card game War? It's a horribly simple game, typically played by 2 players, where both players draw cards from face down decks. That's it. There's almost no potential for strategy because no information is stored outside of piles (score and deck piles, mainly). Players simply flip over the top cards of each deck, and the highest value wins.

Why am I writing about War? Because, when I say I had a moment this weekend when I was terrified my game was turning into War, I want you to understand what I mean.

I had just formulated a means to introduce more randomness by removing individual player decks and having only 1 deck. This approach also has the advantage of making a card game simpler to set up and understand. I played a few tests of this central deck concept, and it seems a decent direction to take the game. Unfortunately, I also became convinced I was oversimplifying my game and making it too much like War.

Psychic Scrap Racers will never be as simple as War, thankfully. The ability to gather cards into a hand and select the card you wish to play will always be more complexity than War can manage. However, as I found myself considering ways to make the game simpler, I began also to consider why I was even making a physical board game in the first place.

The truth is that I'm not a big board game player. I'm not one who often enjoys being a physical piece of game engine versus playing within one. I prefer to play games alone, and I like an easy set up. I'm not above tearing my computer apart to get something working, of course, but I don't always want to go that far.

So, what am I doing making a physical game? Aside for design practice, I don't have a good answer. I don't really understand the culture of board games, and I've had little inclination to immerse myself more than necessary. I think that means it's time to make a change.

The biggest issue with Psychic Scrap Racers right now is randomness. There's not enough of it. The solutions that come to mind are:

1. Remove separate decks and have only 1 central deck.

2. Embrace the strong LCG ("Living" Card Game) influence.

I like Solution 2 the most, and the biggest catch is that no sane publisher is going to be OK with it. LCG design is expensive and, while I assume a publisher might have a better idea, I find myself wanting to move forward with it. The option then is to cut down on the expense. Basically, make a video game.

Of course, I made a chart of pluses and minuses to be sure. Video games are what inspires me, not board games. I know more about the video game industry. Digital products can be sold effectively forever, while physical supplies must always become unprofitable or run out. Publishing a video game is something I'm not afraid to do myself.

There are strong downsides, the biggest being paying for an artist and potentially a programmer, but the costs are actually kind of exciting when associated with a video game. Not so with a board game.

I've begun drawing up a list of what I would need to get done. The estimated time required is 50 weeks, which is just shy of 1 year. I'm going to go ahead and bump the estimate to 1 year.

I could be about to go off on an unhelpful tangent. Yet, I'm still working entirely for myself, with no real dependencies so long as I keep my day job. And, I will be unquestionably getting programming experience out of this. Best of all, I'm excited!

12/11/18:

I spent my free time this weekend setting up an Outline in Unity. Player deck goes here. CPU deck goes here. Distance Track goes in the middle.

I initially assumed a card game would occur in the 3D/2D space afforded by Unity, and I built my layout accordingly. However, I ran into an issue of readability and organizing the cards into an array.

By readability, I mean that cards in the above view would be too small to be readable. By Array, I mean that I wanted to avoid Lists this time as Arrays appear to have more controls in Unity.

It appears I may have been thinking about the problem all wrong. I went looking for instructional videos, and came across several that were about building card games exclusively in the Unity UI layer. This is the best series I've found so far: (unity drag and drop tutorial, omitted)

 

I didn't have time to try anything from my research this weekend. Additionally, this series by quil18 ends before going over how to construct Deck mechanics, so I'll have to figure that out separately.

Things have gotten slow. And, I'm writing for myself on a site that I don't really advertise to anyone. However, for the sake of my creative discipline, I will continue to post weekly.

12/19/18:

Labor tracking is a point of great enlightenment for me. I've yet to put in more than 4 hours in a single day into the digital version of Psychic Scrap Racers. At the same time, since I began labor tracking 2 weeks ago, I've put over 14 hours into the project in total.

I don't know if these numbers are good or not for someone who is working full time. A part of me is a little upset that I haven't managed 6 hours at least once. I know much of this is due to the requirements of the medium. Digital games, due in a large part to programming, are objectively harder to create than physical board games.

However, I still strongly believe I have what it takes to realize my design. All I have to do is pace myself. I know that I can walk the line between putting in the work and resisting burnout, because I've done it before.

I've written 2 books in my life. Neither is very good, because I resisted feedback, but the process of writing taught me what perseverance looks and feels like. You don't have to write a book to discover perseverance in yourself, but there is no substitute for doggedly pursuing 1 task for years. There really isn't.

Today, this is what I have to show for my labor:

My previous image was far, far more colorful, so I'll explain what I have here:

1. Working hand mechanics.

2. The ability to draw 2 from a deck.

3. Text that is not Unity-standard blurry.

4. Enough screen real-estate to finally fit my entire game board onscreen.

I've learned alot following tutorials. That's Unity's real advantage, as far as I'm concerned. Many engines are better, in my opinion, at many of the things Unity does. For example, I think Unreal is a better 3D engine and there are many 2D engines that are completely free to use for commercial purposes. Unity's default text is so, so, so very awful. However, no other engine has the same level of documentation, user questions, and tutorials. For card games alone, I've seen too many posts asking for help that only receive "learn to program", "here's a tutorial that uses another engine or a language you won't need", or "I don't know" responses. Ugh.

Currently, I'm focusing on aligning my game board so that it still works in play mode, and on crafting a card template that I'll be able to push card text and imagery into. I'm holding off on individually crafting every card as a prefab as a last resort. Expect an update next week.

1/1/19:

Happy holidays.

Christmas didn't slow me down as much as expected. I did encounter a logistically complicated but ultimately simple issue that burned a few hours. Any work is still work though, as far as I'm concerned.

Essentially, a script that I borrowed from that quill18 video on hand mechanics in Unity broke as soon as I modified my camera view. I've had a problem of space ever since I began this project, and I thought changing my Canvas component (the foundation of Unity's UI layer and the space I'm building in the game in) from Screen Space - Overlay (UI objects will be on top of everything all the time) to Screen Space - Camera (the Canvas holding the UI may be moved a set distance from the camera) would grant me more space. The space I did get wasn't enough, and I couldn't figure out how to fix the script. I changed the Canvas back to Screen Space - Overlay, but to my horror the problem remained.

Always read your errors. I spent 2 hours trying to fix the script, and when I finally took a hard look at the error I was pointed to a component I've never heard of before and have never seen referenced anywhere. The component is "Canvas Group," and as soon as I added it I could drag and drop cards in my hand again (looking back at the video, it looks like quill18 adds this component at some point, not sure what happened with mine).

I ran more tests of Unity's awful script. I located a component called Text Mesh Pro, but even that doesn't look that great in game view. Here's a comparison:

I've settled with Text Mesh Pro for now, but I'm not happy with it yet.

The majority of my work was spent in a study of how other existing digital card games are handling space and text. Specifically, I examined Hearthstone, Yu-Gi-Oh!, Lightseekers, Shadowverse, and Magic Arena.

Every one of the games I examined had a few things in common:

1. Written card effect information was not expected to be read unless a card was selected or moused-over. Yu-Gi-Oh! was the most extreme example of this. The game I referenced, Legacy of the Duelist, retained the exact ascetic of the cards while displaying them at such a compressed resolution that attempting to read them could only hurt your eyes.
2. Most of the games only show the card Art and Name. Shadowverse didn't even show the names of cards once they were in play. This makes sense, because people are better at recognizing and associating imagery than they are at quickly processing text. I'm sure there's a study somewhere that says that, anyway. I'll find and link something later, maybe.
3. Only the most vital information is shown to the user in bulk. Specific information must be acquired by selecting a card. This has the advantage of only weighing down the attention of a player when they need to learn or remind themselves of the effect of a new card. For example, cards in the Hand in Hearthstone show only Cost, card Art, and Name, while cards on the Field only show Art and Attack and Defense if relevant (no card effect or name).

Referencing these 3 ideas, I successfully shrunk my cards and field components down until I had room for 5 players. I was told during testing that 5 is the highest number of players my game could support, and I'm not sure if I could fit 6 on screen, so 5 is my current target for maximum number of players at one time.

The next step will be to build a pop-up card script for every time a card is either moused over or clicked (probably not both). My game is very card effect heavy, so the ability to display my cards in as big and readable a way as possible will be key. I didn't have time to figure out a deck script, so that will be my next step after I figure out the pop up card thing.

 

 

1/15/19:

After working weekends for a month and thensome, I finally feel like I've got something I can show off a little bit.

As you may guess from the gif, the game is nowhere near complete. The list of To-Do is still so long I'm not even sure if I've reached a half-way point. There remains everything needed for AI, deck building and the screen that will be required for that, tool tips, modes (story, training, whatever), options, and a frontend/start screen.

However, I'm someone who believes in celebrating accomplishments, and the ability to see the full details of a card that you mouse over is the biggest thing I've accomplished yet. The coding portion was difficult, yet I managed it without borrowing any code. Additionally, in the process of completing the full-details card, I completed hard coding all cards into the game and the creation of the smaller card gameobjects (seen in the hand and play areas).

The multiple smaller cards may eventually be a problem. The big card is 1 game object, and mousing over the smaller cards pulls information that changes what the big card will show. It appears that, for card games, most programmers advise doing something similar for the small cards. Essentially, they claim it would be more efficient to create 1 small card that is modified by external scripts and duplicated.

If you think you can manage such an approach, I encourage you to do so. I, however, went with what I believe to be the easier option as my goal is to create a prototype. The end result, i.e. a deck of cards that may be randomized and pulled into player's hands, appears the same. If the game attracts fans when it's released for free, I'll look into hiring a few professionals.

The code for drawing cards and compressing the cards in hand (not shown above) still works, thankfully. Additionally, I've set up a basic Actions tracker with a separation between players (shown) and the generation of starting hands (shown for player 1 but not shown for player 2). I'll be focusing on ironing out player turns, and the phases of turns, next before tackling card effects and AI.

I'm happy to report I was struck by a painfully obvious realization while I was working on all this. I'm not using all of the game design space I could be. Specifically, I've made no cards that actually interact with player position on the Distance Track. Somehow, the idea of exploiting the odd and even numbers on the Track, or something similar, just never occurred to me. I hope to make new cards from this realization.

I'm extremely pleased with where Psychic Scrap Racers is at. Unfortunately, my work output is going to slow down for the next 2 weeks. 1st, there's PAX, and 2nd, there's taxes. I always like to get my taxes out of the way as early as possible, and if I can get all my documents in order by golly I'll get it done this month!

Expect an update next week.

1/26/19

Every time I go to a con, I'm simultaneously exhilarated and devastated. Exhilarated from exposure to so many new and interesting concepts. Devastated because I'm left feeling so very far behind. I listen to developers talk about dedicating huge portions of their lives to a project, seemingly for hours every day of every week, and I feel ashamed.

I don't understand how other developers function. Maybe if I did, if I somehow got more direct exposure, I wouldn't feel like the amount of effort they dedicate on a daily basis is superhuman. Everyone has limits, after all. I just wish I could know how close I am to running into mine.

So, I spent the first few days post-PAX trying to figure out if my current schedule is the best one for me. It's designed around the needs I've discovered within myself and the concerns of my boyfriend, who at one point threatened to leave if I kept working so much. I've decided that, from the data I've collected and further conversations with my boyfriend, I've got room to make a change.

The primary goal for switching my schedule to game design only on the weekends was to exploit the uninterrupted 8 hours I would have on both Saturday and Sunday. To date, I have never once gotten a full 8 hours of game design in on either day. Chores, groceries, exercise, and boredom have all contributed to only ever getting 8 hours on Saturday and Sunday combined.

The biggest determent to the work is the boredom. I'm confident it comes from unfamiliarity, or forcing myself to program and make art when I'm neither a programmer nor an artist. I remember weekends, when I was working on physical board game projects versus digital, where I would get up on Saturday (typically around 7 or 8), work in my office on a design until lunch (12 or 1), then get right back to work for at least another 4 hours. I believe that, if I was more familiar with programming or art, I'd be able to work longer. Unfortunately, I have no data to back this up yet because I'm not often motivated to record my time when working on board games.

With the assumption that I will be able to work longer when I become more familiar with certain tools, and with the data that shows I've never once fully utilized my weekend time since I started recording my time in December of 2018, I've decided to move all of my game design efforts to 2 hours every weekday. This would leave me time to eat, maybe exercise, and maybe do a few chores, after coming home from work, in addition to having the entire weekend as free time.

I'm going to try and track this new schedule for the next few weeks, until I'm ready to draw conclusions. So far, I can say that 2 hours every day may be a perfect amount. I can also say that only programming for 1 hour, as opposed to programming for the full 2 hours, feels alot like failing to climax. Like your partner asking you to slow down when you're close, throwing off your rhythm, or like when you're really close and all of a sudden your partner cums and quits on you. Basically, it's awful, so I'm not planning to try and do art and programming in the same day any time soon.

Speaking of art, I've begun sketching some card imagery. This is important because my digital Psychic Scrap Racers prototype cannot use imagery from the web and be published anywhere. There're simply not enough good public domain car racing images that fit my theme. Also, please be aware that I'm not a very good artist:

For now, I'm hoping to simply convey a feeling. The eventual goal is still to hire a professional artist, I assure you.

Expect an update next week, probably on Saturday/Sunday instead of Tuesday/Thursday.

2/3/19:

My output for this past week totals slightly over 3 hours. That's an unacceptable number.

After I post this update I'm going to put at least 2 hours of work into Psychic Scrap Racers. Then, starting Monday, I'm going to give this new schedule 1 more shot. If I fail to put in 5 hours of work (or, at least 1 hour per weekday), I'll be forced to return to only working on weekends.

As of now, I have no idea how some people work full time in the service industry, then go home to a family or partner, and then stay up an extra 1 to 4 hours every night to put in more work. I have met these people, these people who attempt to consistently meet a strict standard of social interaction quality through both physical and remote means, and though they have zombie days they somehow continue to soldier on toward X goal without falling under the quality standards that are demanded of them.

Maybe such successful behavior demands a level of comfort only obtained from years of field experience. Or, maybe such individuals have a better idea of how to avoid over-investment into their current careers. Or, I could also be in the wrong job for my current goals. I know that, at the very least, I've got weekends to fall back on. That may have to be enough.

In terms of where I'm actually at with the game, I'm at the step of adding AI. I haven't added card effects yet, and there's definitely no multiplayer. My current thinking is to make the prototype single-player for 4 reasons:

1. The foundations of the game, particularly the way I've got cards and decks working, is not compatible with what I would want for multiplayer.
2. Multiplayer requires a community the game will not initially have and, should that community ever taper, the fun will be gone.
3. Multiplayer implies a level of support I'm not prepared for. For example, community building and maintenance.
4. This is an attempt at a rapid prototype, and utilizing only AI players is easier to set up and test. Moving to Alpha-stage production would require a complete overhaul of the game regardless of where it's at now.

The biggest stumbling block with the AI is how to create it. My systems are simple, so the plan is to have the AI simply calculate a value for its hand against the current board before making a play. Similar to a Monte Carlo method, but easier. Hopefully. This requires grabbing values from every card that should be visible to the AI and storing it somewhere, while avoid conflicts with a similar script I'm using to enlarge cards.

The programming is a mess. I've never done anything like this before, and I'm honestly just happy that everything is working so far. If I had to use a pure scripting engine, or an engine that holds my hand less than Unity does, I'd be pulling out my hair or worse.

I'll be back next week. Time to go to work.

2/6/19:

I started this week burnt out. I was listless at work, and when I got home I only had 1 hour of work in me. Yesterday, there was a family event. And, today, I realized I'd forgotten about a local indie dev meetup I was going to try and that I didn't care. I still had time to go, if I wanted to, but I all I wanted to do was go home.

I'm switching back to game development only on the weekends. Too much happens during the week that I need to be present for or recover from. This also means that my updates will be switching back to Monday/Tuesday/Wednesday instead of Saturday/Sunday.

I don't have much to report this week. I'll have more in my next update.

2/12/19:

SXSW is coming next month, and I now fully intend to attend SXSW Gaming. I'd actually forgotten when the event was until this past weekend, and now that I've got it on my calendar it's become something of a deadline.

I won't be bringing Psychic Scrap Racers to SXSW. The game just isn't ready yet. However, given the continued progress I've been making on the game (even during the weekdays where I was burnt out and didn't have alot of time), I believe I can get PSR to a "playable" state before SXSW Gaming starts. As of now, that's about 5 weekends to get to playable.

This is my criteria for "playable":

• The AI can play cards.
• The AI has a hand of cards.
• The AI can activate cards.
• The cards can be activated.
• The cards can be played.
• The cars on the score tracker can move.
• There is a way to win the game.

As of now, the AI can play cards, draw cards, maintain a hand. The player can do the same. However, the ability of the AI to evaluate the board is still pending, cards have no effects, and the Distance Track isn't working at all.

There has been some confusion and missteps. I'm trying my very, very best to avoid making multiple scripts that reference card information. I've been less than successful due to how the systems for reading mouse events (mouse over, drag, etc) work in Unity. At this point, I'm planning to put individual scripts on each of the prefabs I've created for every single card in the game.

It's a mess, but it's a prototype. I have to keep reminding myself it's just a prototype.

In other news, I'm surprised and happy to say I may have another board game in the works. I've been attending a monthly board game design meetup for a while, and the group has monthly design challenges to coincide with meetings.

This month, the criteria for the challenge was

Theme: Code

Style of Game: Racing

For the uninitiated: A racing board game is one where you're trying to be the first player to meet a goal. The game doesn't actually have to be about cars, or anything you'd traditionally associate with racing. The focus is on pacing, and there's usually mechanic to increase the pace as the game goes on.

The style of game didn't really hook me, as PSR is already supposed to be a racing-style game. However, the theme did.

I've been trying to think up a coding or a hacking game for a while. I'm a huge fan of cyberpunk. It wasn't until this month's challenge that I finally came up with a game design that was both cyberpunk and fun to play.

My new design doesn't have a name yet. It involves 1 board, up to 4 players, and hands of cards composed of letters. Players construct words, hide the constructed word, and then take 1 action per turn to try and score said word through movement on the board.

The result has been surprisingly engaging. I can't go into much detail yet, but I can say the first tests with strangers have been positive. There's a huge issue in that whoever goes first will always win. I'm going to keep working on the project a few days out of each month, and eventually I may actually try to publish it.

Plans for my next videogame project have also come into focus. I need to learn how multiplayer works in Unity. To that end, my next project will be the one of the easiest things I can think of: a multiplayer-only fighting game.

Yes, I did just say this would be easy. I don't mean from a balance standpoint. Whatever I make will be horribly unbalanced. However, we're talking about 2 characters in a small space with limited movesets. Technically-speaking, I can't think of much that would be simpler.

I already believe I have a good idea of what information will be sent between players. I'm going to try sending only 4 pieces of information: the name of the opponent's chosen character (at the start of a match), the location of the opponent's Hand-point, the location of the opponent's Foot-point, and a location for 1 core Body point. All else would be extrapolated by the computers at both ends from the x and y coordinates of 3 of these points combined with profile information associated with the 4th point (the character name).

This design philosophy will inform every possible action in the game. I'm very much aware this may cause problems, as I have no idea how Unity's online tools will handle this and whether speed will be a great issue. However, I see no better way to try and learn these things at this time.

None of this future planning will be allowed to interfere with PSR. Expect more updates next week.

2/21/19:

I almost didn't POST this week. Get it? Cause computers have to power-on self-test when they start and my posting of blogs is kinda like a self-review I have to do and-

This is what happens when I write in the morning.

Bad news:

I didn't make as much progress this past weekend as I'd like. There's only 3 weekends left until SXSW, and I still have to program most of the card mechanics and make the AI play cards. I've also realized I need to institute pop-up panels for some mechanics, and the whole process of making a giant card has taught me I don't know how to do pop-ups efficiently. I'll need to do more research.

Good news:

Acceleration cards are currently moving the player markers on the Distance Track! The code to get this working was actually alot simpler than I realized:

Transform temp; //trying to get temp variable so I can extract the name.

if(curPlayer == 0 && p2Acc.childCount > 0) //I fucked up, so 0 is actually p2, and 1 is p1.

{

for(int c = 0; c < p2Acc.childCount; c++)

{

temp = p2Acc.GetChild(c);

//Debug.Log(temp.name);

moveCalc(temp.name);

}

}

In the above code snippet (I haven't figured out how to effectively illustrate code in a blog yet), I:

• Create a temporary Transform-type variable called Temp.
• Check the current player (curPlayer) and whether that player's Acceleration card area has any cards. In this example, I'm checking player 2's Acceleration area.
• Initiate a for loop to cycle through in-play Acceleration cards, which are set as child objects of the Acceleration board area, before assigning data from each card (the Transform, specifically) to Temp.
• Extract the name of the card from its Transform and pass it along to another function.

As you may (or may not) guess, the 2nd function is yet another place where I've listed a bunch of card names. The function in question, moveCalc, is where I'm currently planning to manage all of my Acceleration card mechanics.

However, Distance Track movement doesn't end with 2 functions in 1 script. All that moveCalc is doing is setting information into a variable called carMove. carMove is being referenced by an entirely different script, located on the Distance Track tokens, that is responsible for moving the tokens a specified distance. In order to make this work, I had to learn how to interact with RectTransforms.

RectTransform is the Transform type associated specifically with Unity UI objects. You can pass data to them using normal Transform commands, but the results are unlikely to be what you want. The following code is what I used to set a starting position for my tokens (from a Start() function):

selfRecTrans = GetComponent<RectTransform>();

curSpotX = distNodes[0].anchoredPosition.x;

curSpotY = distNodes[0].anchoredPosition.y;

selfRecTrans.anchoredPosition = new Vector2(curSpotX,curSpotY);

Once I got this worked out (with a little help from the Unity docs), actual token movement referencing the carMove variable was much easier:

for(int i = 0; i< boardState.carMove; i++)

{

curSpotX = distNodes[spacesMoved].anchoredPosition.x;

curSpotY = distNodes[spacesMoved].anchoredPosition.y;

selfRecTrans.anchoredPosition = new Vector2(curSpotX,curSpotY);

spacesMoved++;

}

Car tokens now smoothly calculate and move 1 space for every value stored in carMove. Well, not "smoothly" per se as movement is instant. What I mean is that tokens are not stumped by moving from space 15 to 16 (these spaces are on either end of the Distance Track).

Finally, I wrapped up the weekend by writing something that blew my non-programmer mind:

public GameObject bigCardAcc;

bigCardAcc = GameObject.FindObjectOfType<StateTrack>().bigCard;

What we have here, is an example of pulling another variable straight out of another script directly into a new variable that happens to be of the same type (in this case, both variables are GameObject type). For some reason, I didn't know you could do this. It's probably not best practice. Regardless, this is the solution I had to make to solve my large reference card breaking for no apparent reason. I'm proud of it.

Gotta take your small victories. Until next week.

 

 

3/2/19:

Sometimes, the space between weekends feels like too much. I'm stuck staring at the wall of code I've constructed for this project, and I hate it. I wish I could be starting something new instead.

I assume other people encounter these moments. The reasons behind such moments (too much space between project work, stressful week, etc) don't really matter. The point is this is a time to be stubborn.

I'm going to finish this prototype because I'm going to sit at my computer for at least 6 hours every weekend until it's done. I'm not going to browse the web. I'm not going to play games. I will get water and food, and use the bathroom, but I won't leave the house until my quota for time spent on the game is done.

Code will get written, out of boredom if nothing else, and thus work will get done. Is this efficient? Fuck no, because efficiency comes from practice. From years upon years of dedicating as much time as you can to a task.

I'm probably not going to meet my self-imposed goal of completing a playable version of my game in time for SXSW. Given the state of the game, I'm going to resume working on weekdays in addition to working this weekend and the next. I'm hopeful, and simultaneously worried the project may suffer under my stress.

I will be taking the weekend of SXSW, and the weekend after, off from the project to avoid burnout. After SXSW, I will again not be working on week nights.

Fuck it.

 

3/11/19:

I've got the CPU playing cards. It isn't "thinking" or making choices yet, but it's enough to test Player 1 card effects. If I play long enough, the CPU errors out by playing every card left in its deck. It's becoming less funny the more I see it, but I haven't had time to actually start on that problem yet.

I've started on 11 out of my 23 cards, and 7 are "working" for Player 1. Basically, there's 7 cards I can play where stuff happens like it's supposed to.

There's a strong chance I won't finish something playable for SXSW, but who cares. I'm learning things like this:

public Drag.Dash cardTypeAcc = Drag.Dash.ACCELERATE;

if(cardType.playArea == Drag.Dash.ACCELERATE) { temp.SetParent(p2Accel, false); }

I can't explain what an enum is. However, I made one as part of following a script by quill18 (YouTube) that made this whole project possible, and I can confirm that the above nonsense successfully references an enum.

Dash is the enum, inside of a script called Drag, and one of the enums is ACCELERATE (used and referenced by Acceleration-type cards). The if statement is part of a for statement that grabs the Drag component from a card and assigns it to cardType. Oh, and every single card has it's own Drag script. The if statement appears to be confirming whether the variable that holds the enum's current value, playarea, matches the enum type of ACCELERATE.

This is only a taste of the mess my scripts have become, and my lack of understanding. I think it's awesome and, rather than dissuade me from wanting to continue working in Unity (which happened when I was forced to the only programmer in a group project during school), I've found myself putting more thought into my next project.

As mentioned, my next project is going to be an online-only fighting game. In that regard, this video has been very informative: (omitted GDC rollback talk)

I'm aiming for simple here, from game mechanics to everything else, and in this regard I've also been inspired by Windjammers: My (1st) fighting game will be about 1 combat style. And, it's going to be the simplest fighting style I can think of: Boxing.

I've got the mechanics I want for my next game almost completely planned out. The setting is in flux, but that's fine. Until next week.

 

 

 3/28/19:

In May, it'll be 6 months since I began digitizing Psychic Scrap Racers. That means it'll be over 1 year since I started the project. And, at this juncture, I'm positive I will not be done in the next 2 months.

My progress realizations this past weekend proved deeply immoralizing. Logically, I expected the digitization process to take 1 year. Emotionally, I was clearly unprepared. So, I paused to evaluate my next steps.

The first solution that occurred to me was to try and making something small. Take a break to throw a small project out. However, at my current skill level, it would take me a few days simply to throw something out.

From the long term prospective, and after talking with several people, I decided it would be better to just strap in an stay the course. I ended up doing just that, only inbetween lengthy bouts of playing Sekiro: Shadows Die Twice.

It was nice to sit back and play a new game I've been looking forward to. However, the bigger issue here is that I think I'm getting bored after working on Psychic Scrap Racers for so long.

This next weekend, I'm going to mix it up a little. Instead of working on Psychic Scrap Racers or attempting a smaller free-form project, I'm going to look up and follow through 1 or 2 Unity online tutorials. My next project is intended to be online, and I've never done anything online focused before. It's my hope that, outside of self education, the tutorials will give me space to work on code unrelated to cards or AI that plays cards.

In order to ensure I actually finish Psychic Scrap Racers, I will be returning to work on it after this weekend. I'll post the tutorials I find and relay anything interesting I encounter next week.

 

4/2/19:

So, my objective this weekend was to research and find a tutorial for simple online multiplayer in Unity. Specifically, I wanted to find a p2p (peer-to-peer) or client-server tutorial that would allow for 1 client to be a server or otherwise not require me to actually set up a physical/logical server in the cloud somewhere. The scope would be limited to 1v1, and I figured there had to be an easy way to accomplish this given all the indie games in the world with online.

The 1st problem I noted was that Unity is depreciating it's existing multiplayer solution, and doesn't currently possess a replacement. I could invest time into learning all or some of the existing system but, for all I know, the form of Unity's new multiplayer solution may end up completely different from what exists now. The timeline for Unity's new multiplayer, reportedly about 6 months, also happens to be both long enough and short enough to encourage me to wait and work on other things.

The 2nd problem I encountered was a lack of information for the kind of multiplayer I want to make. The Unity tutorials that I found fell into 2 camps: they either relied on the soon-to-be-outmoded existing multiplayer infrastructure, or they're targeting projects that would require large groups to connect to a server. Even worse, the alternatives to Unity's multiplayer that I could find (DarkRift 2, Forge, Photon and its various versions) don't appear to offer what I'm looking for or require heavy study-investment.

I chose Unity for my first major game project because I thought it would be the easiest program for me to work with. I'm still going to finish a version of Psychic Scrap Racers in Unity, but the multiplayer problems and my existing issues with Unity's text solutions have me highly dissatisfied.

So, it's probably no surprise that, in the midst of my searching 3rd party multiplayer solutions, I bumped into a video about an entirely different game engine: (video on Godot)

I previously encountered Godot in college, and I failed to see anything interesting at that time. However, I was intrigued by the above video, and decided to I check out other Thoughtquake videos to see if he had anything else interesting to show or say regarding Godot. The more I watched, the more intrigued I became.

Godot has a simple multiplayer solution built in. It, reportedly, handles pixel and sprite art better than Unity. And, it's open source, which is a boon for anyone who hates waiting on a fickle company for bug-fixes, or who wants to tinker with code.

I previously stated my next project would be a 1v1 fighting game. However, I may have to put that fighting game plan on hold while I learn Godot. It all depends on whether learning Godot is as easy as Thoughtquake claims.

I will return to working on PsyScrapRace in Unity this weekend. Expect another update next week.

4/10/19:

This past week, I finally had the opportunity to attend a Jeugos Rancheros meetup. Jeugos Rancheros sells itself as an "independent games collective", and I'm still not 100% clear on what that means. My worry was that it meant a room full of laptops and people with drinks talking loudly over club music. Jeugos almost lived up to my worries.

Jeugos currently occurs at The North Door, a venue that manages to pack a restaurant, a bar, a small stage, and enough space for 50 or 60 people into what appears to be a tiny hole-in-the-wall off I35. The space wasn't filled when I arrived, but there was a good number of people milling around with drinks. There weren't as many laptops as I'd expected, but there were enough setups for anyone who wanted a turn.

The theme for the meetup was a simple celebration of the fruits from the most recent Train Jam, a March event that sees game designers, programmers, and artists shut up in a train for 52 hours straight. Naturally , I hoped to meet some of these Train Jam-ies, and to make stronger my poor connection to the existing videogame design world.

I met one guy from the jam. He'd brought a VR setup, and was showing off a tech demo that was not a full game in my eyes (the "game" was simply a dice roll, where your goals and abilities are hidden or mystified to the extent that it was impossible to plan or care about what was happening). I tried to speak with him, but I struggled to communicate in the space.

I've got something of a minor speech impediment. I hate talking about it, but it tends to come up, and it's impossible to miss in loud spaces. The Jeugos meetup was loud, just as I was worried it would be, and every conversation I attempted was a struggle. To make matters worse, I'd just spent all of that weekday struggling through my customer-service job. I've managed to communicate at the cons before (PAX, SXSW), but trying to talk in a space that felt like a con after working all day was fucking torture.

I managed an hour. I tried a few games, and I managed 3 conversations in that time. None of the conversations led to an exchange of information or anything meaningful. There was a 1-button party racing game, a gravity-altering platformer about bringing ice to a planet's core, a a puzzle game about getting to a car or something, the previously mentioned VR tech demo, a Smash Bros clone, a top-down 1v1 fighting game inspired bullet hell-thing, an interesting puzzle noise card game with nothing more than a 1 to 2 minute tutorial demo, and some other projects I didn't bother with.

I left feeling like my expectations had been, unfortunately, on point, and I'm not in any rush to go back. The space just wasn't very inviting for me, unlike board game play and design meetups.

I'm still doing board game things on the side, and so far I've had fun every time I do. Board games are all about understanding the engines that drive them, while videogames are all about hiding them. I see this reflected in the attitudes of board game and video game designers, and I find myself drawn to the less-mystical, more down-to-earth perspectives of the latter.

I found myself thinking back over all this when I sat down to try and put more work into Psychic Scrap Racers this past weekend. I say try, because I didn't actually do any more work on the Unity project.

I'm shelving the PsyScrpRace digital conversion project. The whole thing has taken so long that I've thought up new mechanics to add more randomization to the game, and I still don't have enough baked into the Unity project to even test the basic mechanics! Plus, my projects folder is filling with ideas, and I hate being unable to work on any of them without jeopardizing the future of the PsyScrapRace digital version. So, I'm rebuilding PsyScrapRace as a board game.

The current plan is as follows:

• I'm going to rebuild PsyScrapRace with the new mechanics I have in mind.
• I'm going to test the new mechanics on my own and with the assistance of other board game designers.
• I'm going to create a presence on BoardGameGeek.com.
• I'm going to upload a prototype to BoardGameGeek.com and attempt to attract testers for broader feedback.
• I'm going to try finding a publisher again, and will publish on the Game Crafter if I can't. I want to get my projects out there, and I'm hoping for a little cash.
• I'm going to learn more about Godot (and, eventually, more Unity) on the side.
• I'm going to try and find a work-life balance that allows me to explore Godot and the videogames I love while working on board games.

That last bullet is going to be the hardest one. I don't know many people who've achieved work-life balance without sacrificing something significant, and I've still got the demand to earn an IT certification hanging over my head. However, I have 0 interest in giving up.

I will be back next week.

4/16/19:

This weekend, I created 2 new decks for Psychic Scrap Racers. The 1st is a driver deck with a new mechanic designed to better take advantage of the presence of an actual game board. The 2nd is a deck of cards designed to be slotted into the game board over each numbered space. The 1st deck is intended to finally test some ideas I've been sitting on for 6 months, and the 2nd deck is intended to introduce more randomness.

The process of creating both decks on a spread sheet took me around 7 hours. Printing, cutting, and sleeving for testing will take me a few hours more. Self testing and testing with other game designers will add up to days of time spent. Expanding testing will also expand the timeframe to weeks, and then months. Still, I've learned this is nothing compared to the cost in time of trying to make a digital version.

The end goal is still to find a publisher. However, as a 1st project and a board game, I'm back to being remarkably unchained by PsyScrapRace. If I can't find a publisher there are other distribution methods, and working on board games is infinitely easier than working on videogames. In fact, it's so easy and rewarding I'm working to learn Godot on the side.

To be clear, PsyScrapRace will retain priority until it's published. However, if this past weekend is any indication, I should easily have time for both board game and videogame projects like "Discovering Godot: Make Video Games in Python-like GDScript" on Udemy.

If you have any interest in Udemy courses, don't buy "Discovering Godot" at full price. The responsiveness of the instructor to questions or issues is terrible, he doesn't share the full code if you need to check for issues, his personality is annoying, and he's sloppier than free instructors I've followed on YouTube.

I don't really have a point this week, unfortunately. My head is in a weird place. I'm in what would be a perfect job, in a perfect location, for the me of 5 years ago. Now, even as good as it is, it's somehow painful. I can't really describe it. I can only say that I'm happy to know, for a fact, my future cannot be helpdesk or senior admin.

4/25/19:

I'm happy to report the core deck of Psychic Scrap Racers remains fun to play. Unfortunately, the new deck, designed to interact more directly with the Distance Track, didn't work. All of the new cards intended to provide other ways for players to advance down the Track are too slow. The new Event cards didn't quite work either, but they actually did what I hoped they would.

The Event cards, designed to fit into every single space on the Distance Track, work to add randomization to the game. Additionally, my initial testing (myself + family) has found that any card that impacts a player's ability to advance has a huge effect. As in, encountering the wrong Event card at the wrong time might actually lose you the game.

I'm not convinced that Event cards with power is a bad thing. There are games where a level of unfairness due to randomization can actually work, as in Monopoly. I should be able to think of a better example at the moment, but I can't. Point is, many board games, (including some that are considered pinnacles of the format, like D&D) have a gambling-level of randomization that implies a level of unfairness.

I'm going to explore levels of power in Event cards. I don't want things to be so random that planning is almost made pointless, but I definitely want the Event cards to add something players can find value in. Some of my current Event cards are little more than fluff on the existing gameplay structure.

I'm going to do more testing this weekend, and from that testing I want to capture pictures and/or video. Psychic Scrap Racers is firming into shape, and I want to start hunting a publisher again before I let things harden too far. I'm still operating off of the advice I received from sources I no longer remember:

"Publishers want to be involved in locking down a design, particularly the theme (figuring out what will sell), and should be brought in once a system is in place."

Speaking of theme, I don't like the name Psychic Scrap Racers. Scrap is not involved in the gameplay, and the name just doesn't roll off my tongue how I'd like. I'm going to start trying to think of a new name that fits what I've got. I don't have anything that sounds good yet though.

On the Godot front, I'm meeting some frustration. It appears you should just be able to attach a camera to a game object in order to have the player's view move when the player's onscreen avatar moves. Instead, whether because of something in the tutorial I'm following or not, I've been having trouble getting the Godot camera node to respond at all. No error, no clue, the camera simply doesn't move.

If I can't figure out the camera in Godot by the time I finish the tutorial series I'm following, I'm going back to Unity. I can't make what I want to make without a scrolling camera!

I've been putting more thought into what I want my next game project to be, and I've decided to re-attempt a project I first attempted in Unity. It's a beat-em up with 1 attack button. Multiplayer ambitions will be put off for the time being.

Until next week.

4/30/19:

My recent game testing sessions have been fantastic. The cards still work, and the new Event cards on the track have been a great way to add randomness. Even better, Events that increase Speed or move a player 1 more space when landed on (large game-changing effects) have been entertaining and engaging rather than annoying and game breaking. I've even come up with a new name for the project: Marvelous Racing Elite

Marvelous Racing Elite is not a great name, as it doesn't suggest much of a theme to me, but I like it more than Psychic Scrap Racers. There's no scrap in my game. Every other name idea I've had (Mid Night Club {Japanese racing club}, Psycho Bōsōzoku {Bōsōzoku is Japanese slang that tends to refer to a particular form of biker}, Redline Club) is either too close to an existing franchise or doesn't quite fit. So, Marvelous Racing it is.

The name isn't the only new thing I've come up with for Marvelous Racing. I'm currently testing drawing 1 as the default draw method instead of drawing 2. By chance, during my last testing session this weekend, I had everyone (including myself) drawing 1 as I'd been unable to bring a copy of the rules as planned. I'd completely forgotten about the draw 2 mechanic, and I didn't even realize it until I got home!

Upon reflection, I've realized that drawing 1 was actually very engaging. Being limited to an inefficient card drawing method as a player's default option has the effect of reducing rapid deck shrinkage, making cards that help draw more interesting, and making individual card effects more important. In my last testing session, I was finding uses for cards I'd previously ignored purely because drawing 2 tended to ensure I always had a "better" card in hand.

I'm planning to do more testing of 1 card draw. There was also a lot of using Maneuver cards as if the effects were instant, and I'm going to try testing that more. However, using Maneuver cards as if the effects could be activated as soon as they're played resulted in Maneuver cards staying in hand and almost never entering the field for longer than 1 turn. One of my testers actually complained about the lack of continuous effects and the lack of any need to actually keep Maneuvers on the field.

On the Godot front, the camera issue I encountered last week has been resolved. It turns out, if you put a camera node on anything but the root of the node you want the camera to follow, the camera won't work in Godot 3.1 no matter what you do. This is really weird, as nodes under the root player node should still be providing updated transform position information, but moving the camera to the node root was the only solution I could find. Outside of attempting to program the camera from scratch, of course.

Back to testing and learning. Until next week!

 

 

 

5/14/19:

How do you get your players to understand a theme you don't fully understand yourself? You don't.

My card game, I'm just going to call Project Redline, has a theme problem. I've been trying to talk myself into one version of the same theme after another and, no matter how hard I try, I can't make psychic street racers work in my head. The concept feels simple, like something I should be able to picture just by closing my eyes yet, every time I try, the racers and the society they live in falls apart in my head.

My players appear to be having the same issue. A few have complained that the current theme is detracting from the racing fantasy. They usually understand the fantasy as something close to regular street racing in a city at night (possibly a futuristic city), and the cards that deal with mental abilities confuse anyone who doesn't automatically think of Akira.

I will admit, the opening biker scene of Akira is one of my favorite anime openings ever. However, even in a movie like Akira, almost all of the biker racing is handled by normal kids without abilities. The abilities, when they do appear, more or less trump the mode of transportation so much that bikes become irrelevant.

There are 2 paths forward that suggest themselves to me:

1. Flesh out the world, and include more details of it in cards and the rulebook.
2. Change theme.

Given the amount of struggle I've had with my own theme for the entirety of this project, I think it needs a change. I don't have anything specific in mind, however. I'm going to contemplate themes all of this week and hope to have a new one decided on by next week.

Here's a quick breakdown of everything else that came up during testing:

The Good:

• Base mechanics are still fun.

The Not so Great:

• The board continues to be a problem. Some say it doesn't do enough, others say there's no need for a board at all so much as a string, or circle, of event cards.
• The existing card combos don't suggest themselves to players.
• The rulebook is better than it's ever been, but is not complete. 1 player suggested adding examples to make getting into play easier.

The Bad:

• Power gamers start tuning out fairly early and consistently, as they see the game as too simple. The suggestions I've received are: Shorten the game through smaller decks or rule changes, add more combos, do something to differentiate the mid and end game from the start ("The beginning feels the same as the end").
• A player who falls into 4th place rarely passes 3rd by the end, and is almost always a player who complains about their cards "not being useful."

I don't believe a new theme would magically fix all of my problems. However, themes do have a tendency to suggest solutions on their own. For example, I helped test a game recently about marrying off your daughters in a very Pride and Prejudice-inspired setting. The game had a real problem at the end, when players who had successfully been marrying off daughters ran out of options. The theme helped us suggest possible solutions: bring lesser brothers of the bachelors into play (once the bachelor in question is married), or leave marrying until the end of the game as part of tallying score (retain drama of "will they won't they").

On the Godot front, I'm happy to say I now feel competent enough to make a 2D platformer. However, additional tutorials remain, so I will keep going.

I've got alot of thinking to do. Until next week.

 

 

5/28/19: 

So, last week I redesigned my game and eventually tested it. The redesign was intended to target the problem areas of my game:

1. Heavy mechanics and Magic nerds quickly become board with it.
2. A player who falls behind early tends to remain behind.
3. The experience the game offers remains the same for too long.

I couldn't think of a solution for problem 2, but I figured the easiest solutions for problems 1 and 3 would be to add an additional mechanic and slim down the game. So, I added:

1. An ultimate card that provides a powerful effect for a high cost.
2. Reduced deck size from 30 to 20 cards.
3. Reduced track size from 30 to 15 cards.

The result felt awful. The game was now too short, and I wasn't finding the ultimate cards to be very interesting. I put the project aside, lay down on the carpet in my office, and set myself to the task of figuring out what specifically I'm trying to capture in my card game.

I no longer believe I'm actually trying to capture racing, per se. In a realtime racing environment, be it on the street, NASCAR, or a videogame, someone is always going to fall behind. Under such circumstances, it's rare for the person in last place to make a comeback so extreme as to take 1st.

Videogames tend try to add abilities to allow the player in last to make some comeback. The Blue Shell in Mario cart is the best known example. The Blue Shell also sucks, because it's simply a fuck you to whomever happens to be in 1st when it fires. Put another way, the Blue Shell's only purpose is to slow down or otherwise inconvenience the lead player to the extent that the lead player is almost guaranteed to lose his or her position regardless of racing ability. It punishes a player for being good at racing and changes the meta to be about gaming 1st place rather than holding it.

I don't have much interest in designing a system that, by its very nature as expressed in the real-world equivalent, is so inherently unfair as to make Nintendo think the Blue Shell is a good idea. So, is there an alternative for a racing game? After all, by the very nature of a race, someone has to take a lead while someone falls behind.

After extensive thought, I believe I've arrived at a new approach that will aid racers in staying neck and neck without boiling all of the interesting choices out of the game. My inspiration comes from the movie Initial D.

The live action Initial D movie, based on either the manga series I've never read or the TV series I never watched, is about street racers who use drifting to race down a mountain in Japan. The plot amounts to an attempt at a heroes journey filled with characters I never cared about. Frankly, I'd advise most people to avoid the movie.

The inspiration I extracted from the terrible Initial D movie comes from the racing sequences. Participants spend a majority of their time as close together as they can manage. The reason for staying so close is simple: The opportunity to pass another racer only comes during the drift in the turn. If the lead racer drifts too far out in a turn, and if the racers behind can manage a tighter turn, then the racers behind have an opportunity to accelerate and pass while the lead racer is still trying to straighten out of the turn. Here's a clip from the movie to better illustrate what I mean (feel free to mute, as the person who posted this video dubbed anime music over it): (omitted)

 

I have no intention of making a game about drifting. My point with focusing on the closeness of the racers in Intial D is that it's what I want to capture more of.

My past thought processes included those rare moments when a racer in the back surges forward to take the lead. However, attempting to balance in such a way as to allow for that possibility without providing even more tools for the lead player to stay ahead, or for the game to descend into randomized chaos, hasn't been working. So, as many racing movies have done, I'm cutting out the stragglers and attempting to set the players as the dueling protagonists of the race.

My initial tests on my own have been promising. I've simplified the actions available to players, and the Event Deck is now the Track Deck. The Track will be randomized with each play, and I'm aiming to make it complex enough to invite repeated plays while simple enough that players will be able to understand the board state in a glance. I'm planning on adding a bit more complexity with tokens and a special central deck instead of 4 separate decks.

I believe I'm doing something unusual in the board game space, and I can still see the skeleton of the previous versions of this project in the new design. I don't believe the actions I'm taking will make the game more generic, which is something that is always a concern when you're attempting to appeal to people.

Until next week.

 

 

 6/3/19:

Something in my post last week caused a few of my friends and family to be concerned. They felt I was potentially taking the results of my last session of group testing too seriously, and discarding a perfectly decent design in the process. As a result, I spent much of this past week thinking about both the new racing card game design, which I'm calling Pass Defense, and the design that came before, which I'm calling FTR.

I now believe I was too hasty. Pass Defense has simultaneous turns, a heavy focus on track positioning, and very little in terms of decks or cards. Players are expected to spend almost all of the game as close to each other as possible. It's an entirely different design from FTR, where players may create huge distances between each other through speed and deck management.

I've decided 3 things from last week:

• I'm going to return to working on FTR while continuing work on Pass Defense.
• As long as players are having fun, I don't care if anyone falls behind.

Since the beginning, I've been in conflict with myself over how to handle players falling into last place. Being in last place sucks so, if you can somehow strip elements of the last place out of a racing game, you've scored an easy win with players, right?

Wrong. The potential to come in last is a condition of agreeing to play a racing game. If you don't enjoy the experience of coming in last, either the "depth" of the game (framework provided by rules and a player's actual interest in exploring the limits of said rules) will draw you back in to try again, or you'll quit and go play something else.

The idea that players must agree to abide by rules they don't like in order to play has always sounded bad to me in theory. However, as a player, I've come to admit that I agree to take on such rules all the time in order to participate even in videogames. It's a necessary part of experiencing a game's design, and what that design is intended to convey. Plus, as a game, it will always stop if you say so.

If there's no safe word, you're not playing a game.

So, after finally getting myself to a place where I could stand to have a last place player, I started looking at changes I might make for FTR.

If you'll recall from last week's post, the chief complaints that bothered me for FTR were game length and complexity. In order to target this pain points, I reformed the last solid design for the game (30 card decks, hidden and randomized event cards, etc) and made the simplest changes I could think of:

1. Redline cards: These cards have a high cost for a powerful effect, and trigger a 2nd phase for as long as they are in play.
2. Phase 2: So long as a Redline card is in play, all cards that would affect Speed have +1 Speed. This affects all players, regardless of whomever has the Redline card in play. It also makes cards that would reduce speed less painful and more attractive to players.
3. 25 card decks: Fewer cards means that Burning cards is more of a threat, that the cards in the decks are more focused, and that the game moves faster.
4. All of the random Event cards are now placed face up, to help with planning.

So far, the changes to FTR are positive. Players have the potential to Burn themselves out before a race is over. Redline cards accelerate turns while a slower initial pace is maintained. Games finish faster, so any player who suffers the bad luck of Burning all of his or her Accelerate cards (the only cards that provide Speed) won't have to wait long.

Obviously, I'll need to expand to testing with people. At this point, I'm just happy to be looking forward to doing so with FTR. And, it'll be nice to have Pass Defense along to see if it's fun.

I'd love to end everything there, but unfortunately I've come up with a 3rd project. I'm under no illusion that a 3rd project is in any way a good idea, but I can't stop thinking about it!

I'm going to avoid saying much for the time being. The influences behind the idea are the Imperial Guard from Warhammer 40k, Catch-22 (the Hulu series is pretty good), and a desire to test my Godot skills in a limited capacity. The project will be a short game (between 1 and 2 hours playtime max), probably mostly drawn by myself (ugly), designed as a quick and dirty top-down shooter, and will be put out into the world for free (I may use this as an excuse to borrow assets). I'll have more to say when I've got something to show.

Until next week.

 

 

6/13/19:

I don't have alot of time for a blog entry this week, unfortunately. I built a new prototype of FTR over the weekend, tested it Monday, received email confirmation that my submission to a stream had been accepted, and I've basically been in a panic ever since.

There is a group on Facebook, perhaps close enough to call a sister group to the Austin Boardgame Designers group (ABD), simply called Dallas Designer Group (DDG). I don't know much about this group, but I do know some of the Dallas members have come down to Austin and attended the Austin meetups. And, last week, a member of the DDG posted on the ABD page that his group is accepting submissions for testing over livestream.

The feedback I got from testing Monday was great, but there were a few glaring issues I'd prefer to avoid getting duplicate feedback on:

• My game is now so fast that adding in an extra layer through Redline cards doesn't make alot of sense.
• The only thing every single player complained about was the Maneuver cards.

As mentioned above, my game has gotten alot faster. This has resulted in Maneuver cards becoming more clunky and confusing for players than ever. Several players complained that Maneuver cards were too slow for the current pace of the game. Overall, it's clear I have to do something about them.

I've decided to buff Maneuver cards and simplify how they're played. I'm using the only Redline card I ever attempted to test as a baseline (+1 Action each turn) to ensure I make cards that feel like interesting or worthwhile choices. I've also buffed the effects of the cards that reduce player speed, while buffing an Event card that increases player speed if they would lose any.

I'm not explaining myself very well, but this is literally all the time I have this week. I'll have more time for detail next week, after I've shipped my prototype to Dallas.

 

 

 6/21/19:

My newest prototype of FTR was assembled and shipped in 4 days, and the Dallas Designer Group (DDG) has confirmed receipt (I waited to post this until I had their confirmation, thus the delay). At this point, my chief concerns for FTR are:

• The time of the livestream (it's supposed to be sometime next month).
• Whether there will be any cost issues with getting the prototype returned.

I didn't think to include a return label, as I have the ability to create one and email it as a PDF thanks to FedEx. Additionally, I haven't verified whether DDG actually has a budget setup for printing off shipping labels or purchasing packaging. Thankfully, if for any reason DDG refuses to return my prototype, I will only have lost:

• 4 small meeples (general use board game figures) from The White Box.
• 100 card sleeves (4 different colors).
• The time it took to cut out and sleeve all 100 player cards.
• The time it took to cut out all 34 Event cards.

I'm thankful for the cheapness of my design on FTR. My goal is to get the prototype back in 1 piece but, if I was being rational about it, it might actually be cheaper just to purchase another 400 card sleeves and another White Box (or some other pack of components/meeples). I'm hoping everything will work out, and I've got a plan if it all goes sideways.

Now, while I wait for the livestream, I will be taking a hiatus from FTR and board game design. It doesn't make sense to continue testing a game I explicitly sent off for testing and feedback, and I've been wanting a bit of a break to focus on Godot.

I already started work on a project I'm calling A Beginning for Pointman the week below last. It's the same project I detailed in my 3 projects post; it's a top down shooter with a story emphasis, and the whole project is intended to challenge my Godot skills. This is what I have so far:

As you can see, I've successfully created a line from the player object to the current mouse position. It took me a day to figure this out with my current knowledge, which is strange to me. I figured twin stick/top down shooter tutorials would be as plentiful in Godot as they are in Unity. Instead, I had to dig this code out of random form posts:

func _process(delta):

get_player_pos()

get_mouse()

update() #required to force draw line to update, not clear why?

func get_mouse(): #turn/react to mouse

look_at(mouse_pos)

mouse_pos = get_viewport().get_mouse_position() #need to get local pos, as global fucks up

func get_player_pos():

player_pos = self.get_position() #this does appear to be the preferred way to get self pos

func _draw(): #Draw a red line from self to mouse position.

draw_line(Vector2(), mouse_pos - player_pos, Color(1,0,0), 1)

For the uninitiated, anything with a # sign is a comment or note regarding the code. As you can tell, I don't fully understand what is going on in this code.

For example, update() is a built in part of Godot I've never used or had any need for before. Yet, without update(), the game will create a line between the player position and the mouse exactly 1 time. So, a line will be drawn when you start the game, and then never move or change size for the rest of the game.

Initially, I believed the simplest solution would be a Raycast2D or a Line2D node. After all, if there's already a line in the scene, all you have to do is connect the line from the player's position to the mouse position and make is visible, right? I couldn't make that work! So, as illustrated above, I had to draw the line entirely in code.

Given how much time it took me to figure out that line, it's pretty clear that A Beginning for Pointman will not be a quick project. It's a major project, given my current skills, and I will have to return to FTR once the upcoming testing livestream is over with. So, in the meantime, I'm going to try for what I believe would be an easy win.

There is a game I've tried to make a few times that was intentionally designed to be easy. I failed to make it in Love2D because I couldn't figure out how to program the camera. I failed to make it in Unity because I believed I was ready to make a card game instead.

This weekend, I'm finally going to try and finish a completely playable version of the Ghost game!

OK, I know, it's nothing to look at yet. Here's the thing, though: what you're seeing is what I managed to get done in 2 hours on a weekday. Player scene, Level scene, an initial script, a global script, camera, and text on screen. There's only 1 problem (that will probably take me all weekend to solve): Text from the keyboard.

This is what I've currently got:

func _input(event):

if event is InputEventKey and event.pressed and input_delay.time_left :

var s = OS.get_scancode_string(event.scancode)

pInput.append(s)

update_player_output(pInput)

input_delay.start()

func update_player_output(pInput):

if pInput.size() < 6:

for i in range(0,pInput.size()):

complete += pInput[i]

else:

pInput.clear()

complete = ""

Global.POut.set_text(complete)

This doesn't work! Not because it fails to capture keystrokes, but because I keep getting duplicate inputs!

I don't know if the problem is my mechanical keyboard or how Godot handles string inputs through code. There is a node that might help here, LineEdit, but I'm going to try handling the issue first in code, possibly with timers.

Until next week!

 

7/12/19:

Card games are fucking hard.

This past weekend, the Dallas Designer Group helped me out by livestreaming a mostly-blind playtest of my card game, FTR. The stream archive may be found here:

https://www.facebook.com/dallasdesignergroup/videos/908234109511312/

(I tried embedding the video in this blog, but the Wix site hosting service doesn't appear to like Facebook video. You should still be able to view the video without a Facebook account)

The Dallas designers touched on almost every complaint I've received (the Maneuver cards remain hard to understand if I don't explain them, the text and terms need work, nobody likes moving backwards in a racing game, etc), put voice to some of the complaints that seem to've only existed in my head until now (the theme still doesn't work), and provided feedback on problem areas that haven't been touched on before:

• Turns slow down as the game progresses. The Dallas designers found that resolving Accelerate cards before the turn begins, in addition to the ability to draw during a turn, was a large part of this. Each player turn has 3 phases, Acceleration, Action, End, and resolving the Acceleration phase can occasionally take as long as entire turns in other games while still requiring a player to plan and execute an Action phase. Adding the ability to draw during (or card effects that draw before or during) the Action phase can make things even worse by injecting new variables during a player's turn versus injecting new variables and choices during other player's turns.
• The spread of cards and card effects, in the words of 1 designer, is tight. So tight that the players never felt that they were racing, per se. There wasn't alot of forward movement and, as decks quickly started to dwindle, the players felt more like they were in a test of endurance instead of a car race. Using your speed cards too early, rather than strategically, will result in a lost game.

The turn slowdown was something I always assumed to be a new player problem. However, after watching people play the game for so long, I've had to admit that the Dallas testers are right. There really is a huge point of slowdown in the current game that tends to pop up around the Acceleration phase.

I hadn't thought of FTR as a survival experience before. True, I have been tuning the game to be tight in terms of available speed resources, but I thought of this as keeping and building tension for the endgame. The Dallas testers noted this themselves, when one of the players almost won the game with barely any cards left in deck or hand.

Not all of the feedback provided was helpful. The Dallas designers made several suggestions, including that I alter my game to take a greater influence from established videogame franchises, that I'm simply not open to. And, that's ok. I was looking for testing help to find problem areas, and I received enough testing assistance through watching the Dallas testers play and hearing them talk about the game to realize, as one of them stated, there's a problem with FTR's foundation.

Normally, when I receive feedback, my mind begins racing with new ideas and new directions to try. However, this time, I found myself caring less and less as the stream went on. It started with the realization that the Maneuver cards still didn't work, and the feeling didn't completely go away until the next day.

I have re-designed FTR so many times that it's clear I need to take another break. The only question remaining was whether the break should be permanent.

After spending a few days this week just thinking about what I want to do, I've decided I will shelve FTR. FTR is dead.

However, FTR didn't die in vain. This latest testing, and subsequent thinking, have led me to a series of conclusions:

• Attempting to keep a car card racing design simple was not the right approach, and resulted in a fair amount of self-smothering and an inability to see any way to add real card synergy. I'm really, really tired of hearing complaints about the lack of synergy in FTR, so if I'm going to make a card racing game I have to be prepared to go big.
• Psychic racers was a correct choice to be part of the theme. FTR was an attempt to boil my game down to a basic racing element, and yet I still couldn't abandon the (now clashing with street racing theme) Psychic Scrap Racers mind power-inspired cards. Such cards feel unique to me in a racing game, and I see them as fun.
• When I want to play a racing game, I play Hydro Thunder on Xbox. I have a great deal of trouble imagining a racing board game design that hasn't already been done or isn't actually just a poor interpretation of a videogame. I believe I should work with this, instead of against it, by focusing on far more of a survival experience. I found my game to be fun because of the tightness, and it could be that pure racing would never fit what I'm looking for.

Eventually, I'm going to begin work on a psychic racing survival card game. But, I'm going to take a break and let a few other projects take priority first.

Text to Ghost is still a thing. I'm currently working to set up movement for all of the foes, something that is proving more challenging than expected. The tutorials I followed did me the disservice of only using animations for enemy movement instead of code, and I'm left to painstakingly figure out the code from random forums and guides.

I'm hoping to get Text to Ghost wrapped up this weekend, but don't quote me. Once Text to Ghost is done, I'm planning to move forward with A Beginning for Hitman. Hopefully, my experience with Ghost and Red Bop Blue will result in a faster turnaround for Hitman. Maybe.

Once a Beginning for Hitman is done, I'll either return to square 1 with the racing card game, create a multiplayer experiment in Godot, or begin work on a video game for profit. I haven't decided on this point yet, and I don't see any reason to pressure myself into a choice.

FTR was the culmination of over a year of my life invested in 1 project. I learned alot from the project, including a great deal about how complex card games really are, how they can go wrong, and what it means to admit you need to shut an investment down. I have no regrets.

Until next week.

7/17/19:

Before last weekend, I had decided I needed a break from board and card game design. As you can probably guess, I proceeded to design the makings of a new card game. I'm not going to go into alot of detail about this new project yet, because I'm still not confident in my ability to accurately judge a board game idea before it's received some real testing. Still, I feel like the design is already stronger for my experiences with FTR/Redline/Psychic Racers, and I'm very hopeful.

Speaking of things that occurred recently, I got the FTR prototype back in the mail today:

I have no plans for the cards for now, other than to set them aside somewhere, but I felt like sharing them anyway.

On the Godot front, I'm annoyed to say I'm still not done with the Ghost Text game. I was compelled to rethink my design of the enemies, as the original design was rushed anyway.

Originally, there were only 3 foes: Bubble (moves in straight lines and bounces around), Hand (launches itself at the player's last position in a straight line), and Mirror (mirrors the player's movements). Now, if I say there was never a plan for any walls or floor, some of the design issues should make themselves clear. Hand was never a problem; it just launches itself like a missile in 1 direction and doesn't stop. Mirror, however, in mimicking the player in an otherwise empty space, would never actually touch the player. And, with Bubble, what's the point if bouncing if you've got nothing to bounce off of?

So, wondering exactly where my head was at when I designed these foes originally, I redesigned them again and added a 4th: the Rock. The Rock doesn't do anything on it's own, but serves as a static obstacle to impede and protect the player.

 

The Bubble now moves in a straight line. I originally learned how to set up this kind of movement system using a Godot animation, and I was extremely dissatisfied with this approach. Animations can be used to move objects, but require you to lock down the distance traveled and the duration of the travel for every animation. This is too much work, so I figured out how to move in straight lines in a script for greater freedom in movement planning:

extends "res://Scripts/Destory.gd"

export var move_horizontal = false

export var move_vertical = false

export var wait_time = 1

The above values are exported to allow for free changing in the editor view. This also helps with instancing, allowing for different values for every instance. I had to make Boolean values for when I want a Bubble to move horizontally vs vertically, because (unlike with some other engines) simply rotating an imported node doesn't change its movement on the X/Y axis. I assume this means I'm using global position by default, and I don't actually care enough to try and change this behavior. I just have a switch to activate movement in the direction I want.

The wait_time variable is tied to a timer, and allows for extending the time a given Bubble will move in both directions. For more control over how long the Bubble moves in a given direction, all I'd need is more timers.

var travel = 1

func _ready():

$DirectionChange.set_wait_time(wait_time)

The _ready(): function in this script simply sets the starting time for the timer that runs continuously in the background.

func _process(delta):

if move_horizontal:

var motion = travel * (SPEED/2) * delta

position.x += motion

if move_vertical:

var motion = travel * (SPEED/2) * delta

position.y += motion

The _process(delta) function is where all the movement is being handled. The Bubble is an Area2D node, instead of a Kinematic or Rigidbody, and thus moves outside of Godot's built-in physics system. Operations that move Area2Ds have to occur under _process(delta) instead of _physics_process(delta), as far as I'm aware.

The _process(delta) function in this case is altering the Bubble's position. It checks whether the switch for moving horizontally or vertically is true, then alters Bubble's position by travel, set to 1, multiplied by half of the SPEED constant all foes are set to, multiplied again by delta, delta being some constant that ensures everything executes at the same time. I don't understand exactly what delta is, but I do know it's supposed to ensure that your game doesn't go too fast or too slow due to hardware differences.

func _on_DirectionChange_timeout():

if travel != -travel:

travel = -travel

else:

travel = abs(travel)

The _on_DirectionChange_timeout(): function is where the travel value (set in the above script to alternate between1 and -1) is modified to allow travel up (negative direction in Godot) or down (positive direction in Godot) on a given axis.

Mirror has received a complete re-design. The only things it does now are:

• Wait for the player to come into "view" (be within a certain distance).
• Unceasingly pursue the player once in range.

Here's the code for it:

extends "res://Scripts/Destory.gd"

export var distant_check = 0

var player = Global.player_pos

var motion

var distance

var timeout = false

func _process(delta):

var self_pos = self.get_global_position()

distance = self_pos.distance_to(Global.Player.get_global_position())

if distance <= distant_check:

if timeout == true:

if player.distance_to(self.position) > 0:

var direction = (player - position).normalized()

var motion = direction * SPEED * delta

position += motion

func _on_Wait_timeout():

timeout = true

The Mirror script is actually simpler than Bubble's. The Mirror tracks the player's current position through a value that gets fed to it via a separate script. In this case, the value is actually extracted by 1 script, fed to a Global script, and then fed again to all foes that need player positioning information. It's kinda ugly, but I haven't found a way to do it better due to how the player and the Mirror are instanced into a level versus being a part of a level scene.

 

The rest of the script is all about throwing the Mirror at the player every scene until one or both are dead.

 

I don't actually remember what that last timer does, which is a failure on my part. I became very frustrated and impatient this last weekend, and I let it affect my documentation. The timer may actually do nothing, because the value is set to 1 and the timer is set to execute exactly 1 time (timers are typically the most useful when they repeat in Godot). I'm not going to mess with it. 

 

My plan is to finish Ghost Text this weekend. The project was spawned from a jam I attempted with the Love2D engine, and my overall passion for it is waning. I had originally planned to attempt a score system. However, I don't believe a scoring system would teach me anything I don't know already, so I've cut the idea. 

 

The final version of Ghost Text will have a better name, use basic sprites, possess some light animations, not use any sounds or music, feature 3 levels (an easy level, a medium difficulty level, and a hard level), feature a start menu, and that's about it. As things stand, I've got sprites, animations, level design, and level transitions left to finalize. The main character, or ghost, in addition to all of the foes, the UI, and the start menu, have been completed.

 

The itch to develop a commercial video game has been growing stronger recently. However, I will not give in yet. There are still ideas I'd prefer to prototype.  

 

My next prototype, A Beginning for Pointman, will feature sounds, possibly music, and a greater action focus. I'm going to give myself the months of August and September to work on it, with October as a backup. If Pointman extends into November, I'll cut out something resembling a game and put it out into the world whether it's completely ready or not. All the more reason to do as much as I can in August and September, right?

 

Whether all goes according to plan or not, I'm going to finish out this year with jams, board game work, tutorials, and general attempts to get all my ducks in a row. My gut tells me the best time to start on a commercial project would be after I file my taxes, but I haven't talked anything over officially with any accountants or lawyers yet.

 

Look at me and my long term plans. Let me know if you like the new format I'm using to present my code, or if you preferred the old format. I haven't found a way to present code cleanly through the tools available as yet, and I'm planning to continue looking into it as a low priority.