After starting with the goal of just having some sort of shared network interaction between players on different devices, I took the ideas garnered from our in-class playtesting and decided to branch off from the original game concept and make a new game.
Tradetatos is a mobile game for 2-20 players, where the objective is to collect the most valuable fud possible by scavenging the map and sending negatively-valued fud to your opponents. Each player has their own screen on their device, but a shared screen tells players the overall map layout, how much time is left, and what fud is valuable or not. Players have two minutes to collect as much fud as possible as morks, tatos, and upples randomly spawn across the map, but they have to keep an eye on the economy indicators to let them know which of the three are super valuable, and which are actually negatively valued and will spoil your whole haul. Whoever has the most fud points at the end of the game wins.
I used these super helpful videos from Dan Shiffman as a starting point!
To play, follow these steps:
On a shared screen that all players can easily see, open this page.
Have each player open up this screen on a personal device such as phone or laptop.
When all players have chosen a color and name and have pressed start to join the map, press the start button on the shared screen page.
See below gif for an example:
It was actually a huge coincidence that the above example worked out so well. The coincidence that an upple spawned on our map immediately after the first trade went through is extraordinarily improbable…. So nice of the universe to do that for me.
It’s only been a week since I finished the game, but since I had spent about 10 days prior to that working on it non-stop, things are a bit of a blur. I’ll do my best to go through my process, but so many breakthroughs happened literally at 430 in the morning after I had been working on it for over 12 hours that I can’t possibly follow my own mind haha. All in all, was very happy with the demo in class; I really didn’t expect it to hold up that well with 12 players. It seemed like people enjoyed just being able to see each others avatars in real time, the game was sort of secondary, but I think that just speaks to how important the real-time interaction aspect is.
Here are some screenshots from the process, and I’ll go over the general flow below them.
So the first step was obviously to fix the problem I had during the playtest which was that the different screens weren’t actually able to communicate across the heroku-deployed server. This was much more of a hassle than I thought it would be. I scheduled office hours with Shawn Van Every that Monday as a back up, but ended up staying up all night sunday and figuring it out. Articles and Tutorials that I found online just weren’t helpful to me because they assumed a basic knowledge of web design (like the difference between an html file and a js file…), but once I spent a few hours getting up to speed on all that the rest was just trial and error. Changing the code from the Coding Train tutorial was the main step, I don’t know if his Agar.io code actually works… Once I had each client just connect to socket() instead of a specific socket like socket(3000) or whatever, that fixed the communication errors.
Then getting node to be able to send and receive messages from different js files was the next big thing. I had originally wanted to have a shared screen like jackbox, but figured that would be way harder (it was) so I started coding this to have a button where people could open different menus from their screen to see the map, timer, and economy indicators. I realized that was going to be way too cluttered and confusing, and that I needed to keep the user’s screen as simple as possible and offload all the shared information to the main screen. After messing around with file paths and eventually realizing I had to change the html files for each type of js file, I got the shared screen to be able to start a timer that would send a “times up!” message to the players after time ran out.
The atom picture was just to show my work environment, I ended up changing a lot of this code by the end.
Then I set to work on the shared screen, establishing the map tiles and their 3x3 grid. I just picked random colors that I thought would contrast the background and the fud icons. After playing with different layouts of the shared screen, I knew I needed to have the fud economy text match the user’s fud buttons (I tried getting the user’s fud buttons to change colors but couldn’t figure it out in time), and so putting the economy text and the timer on top was essential. I was worried having the map be stretched horizontal on the main screen would be confusing since the map tiles are vertical on the player screens, but in the end I don’t think people were even really paying attention to the map screen, so whatever.
I spent too much time messing with the scaling of the shared screen elements, since I wanted the text to be big enough but not overlap on smaller screens. Plus, I had to have the gold outline for the valuable fud and the black box for the spoiled fud, and when those overlapped it really bothered me too…
There was a huge chunk of time spent on trying to get the shared screen to communicate with the player screens well, but after messing around with the syntax I think I found a basic way to do it, but I’m sure there are better/more efficient ways besides just having a bunch of different events the server is reading and sending.
Then I had to get the map movement sorted out. The design went through a lot of variations, but I eventually settled on having prominent buttons on the player screen that would let them move around the grid, with their name being displayed on the main map to let them know where they were. I had an array to make sure that the direction buttons would only appear if the movement was valid, I knew it would confuse the hell out of people if they pressed a button and nothing happened. I assigned each player a random starting tile, and made sure their tile would have the same background as the matching tile on the main map. Getting the players to show up on the same map was tricky, but I ended up just including their map tile in the update object, so each player would only display another players avatar if their map tiles matched. This was later how I displayed the spawned fud too. This was the most conceptually crazy part I think, that in theory all the avatars were occupying the same rectangle, since there was no actual grid, there was just an array of objects that would contain players and only display the matching ones. Playing around with this movement was super satisfying.
Next was the fud generation, which I wanted to scale with player count, but ran out of time and ended up just having it spawn randomly every 3-20 seconds more or less. I had wanted to get fun assets to represent each fud type, but for simplicity’s sake, I just used triangles with colors that matched the fud text above the shared screen. Definitely not very intuitive, but I think repeat players would get it quickly. I had to make sure the pick up process was smooth and very specific since avatars would be fighting over these very quickly.
I wish I had gotten documentation of the playtest in class, since I haven’t had an opportunity to play it with anyone else since then. I’ll probably make my family try it over the holidays, but all in all, very happy with how this experiment in networked gaming turned out considering how little I knew about web stuff literally two weeks ago. Really eager to expand on this framework for the original game idea, Skinflint, and super happy I can use this as a template for the performance piece I’m doing for the winter show, Rhythm 0.0.2. Between all this and the “Collective Play” class I’m taking in the spring, I think I’ll have made some really rad stuff by this time next year. Stay tuned!
To Do // Next Features to Implement
Be able to reset from the shared screen since player scores seem to persist if I don’t reset the server in between games.
Figure out how to organize my code. Do socket functions need to be in setup or draw or neither or does it not matter? Should I alphabetize my functions or have them listed in the order they’re used? Should I use shared variable names across server and client files or try and keep them unique to avoid confusion?
I’m not sure if mobile is working or not, I was having off and on issues where I couldn’t drag my avatar from mobile, and the map movement buttons were double clicking.
I also need to figure out the best way to scale the windows. I meant to try messing around with the mobile scaling advice from this awesome website (https://creative-coding.decontextualize.com/mobile/) but I didn’t have time.
Fix the fud spawning to scale to window instead of just (300,400)
I was using two different github repos for my code, one for heroku and one for local development, but that was super inefficient and a waste of time.
I want to have pretty code comments like Becca
I think people need a tutorial they can play after the character creation screen that explains the objectives, map movement, trading, and economy indicators. They could skip it if they’ve played before
I wonder if people would appreciate having a personal score screen on their device at the end displaying how much points they got from their fud types.
I need to figure out how to make the buttons different colors
Um, need to make it look good haha. Need to learn css.
Make another game.