If I am being completely honest, I am not really a sports kind of guy. Sure I’ll watch them every now and again, but if I am gonna play sport, why not actually play it versus playing a digital simulation of it. However, my family has always been really into sports, specifically football (not american, the real one). Because of this, FIFA has always been a game we get every year no matter what. I enjoy playing it, but I really enjoy playing it with my family even more. With four controllers and two teams, we always have fun planning tactics with each other, and setting up plays ultimately resulting in either an amazing finish or a terrible miss. With a game based of a sport and competition, having a good multiplayer experience is important. However, this landscape is changing thanks to innovations in how we structure multiplayer gaming in sports games, and its a welcome change I could see in other genres as well.

Bartle’s Taxonomy and Early Sports Games

Any game designer has heard of Bartle’s taxonomy; a set of four player types that define interactions of players. Bartle’s taxonomy states that a player can be classified by whether they act or interact on the players or the worlds. Originally, this was used to describe players in RPGs after observation, and is now used to target specific types of players through narratives or mechanics. In early multiplayer sports games, we see players interacting with players, or more specifically acting on players, since the actions the players take directly affect another player. Thus, the players of multiplayer sports games typically are classified as “Killers”, a group of players who are interested in dominating over other players. They will consistently try and one up each other through play. This creates longer engagement, and by implementing play modes where players are competing in tiered systems or in professional leagues like EASHL in NHL can also increase investment in the players. However, this is just one player type.

When you think of multiplayer, you automatically think of Socializers, the type of player who enjoy interacting with other players, and you’re not wrong, but in early multiplayer, this was limited to voice chat and single control multiplayer, when one player controls a team and another player controls another, for a PvP experience.

Nowadays, we are seeing a change in how we play online through lobby like experiences. For this we can look to NBA 2K MyPark, an online mode where players play with other players using their own custom players. These could be up to 5v5 games with 10 unique players, allowing for more interaction with players. These systems also have rankings, invoking the killer role. 2K has capitalized on these players by using micro-transactions to get players to buy more goods for customization, like jerseys and hats.

One of the major aspects of these open world multiplayer games is your status or “clout” in the game. These include badges which represent your level or tier. This ropes in achievers, who are looking to leave their impact on the world. As such, being known for being the “Park Bully” is just one of the ways a player can leave their impact. In NBA 2k20, players can build their reputation, earning levels such as “pro” and “legend”. The structure of these new multiplayer experiences help rope in more of these player archetypes into the game, and with yearly installments, can help increase the base.

Where to go from Here

Multiplayer in Sports Games have enticed 3 out of the 4 player types to come into the system, but we are missing the 4th type: Explorers. This type prefers interacting with the world itself, trying to find hidden secrets and learn all there is to know. When developing sports games, the major focus is on the gameplay experience within the actual matches; how the player’s play the game. However, if sports games wanted to incorporate elements that explorers would enjoy, it would be as easy as adding a simple story mode for your player. Similar to manager mode in FIFA, you could have a career manager with your player, allowing you to open businesses and make deals for endorsement. Allowing you to manage your own park can allow for hidden secrets, which means that explorers would be constantly looking for these things.

Of course we have to address the elephant in the room: the validity of Bartle’s Taxonomy. In reality, this system is really poorly designed for games other than MUD’s (Multi User Text Dungeons). However, the core idea here is that Multiplayer sports games are becoming more and more adaptive to new play styles, ranging from the causal players to the more competitive players. The taxonomy gives us a solid foundation when looking into player styles for games, such as adopting new play styles, or adopting for a spectrum of styles. Just like the Taxonomy, take this with a grain of salt because these are just here to show that the multiplayer scene is changing in the sports games market, and I can see it soon changing in other areas.

Conclusion

The adoption of open world multiplayer systems helps cultivate an experience for players to not only play competitively, but encourages exploration, communication and perseverance in games where frustration is a prominent feeling. Is this a perfect system? No, but in the game design world, perfect is the enemy of good.

Drop In — How Sports Games are Challenging the Multiplayer Scene was originally published in Matters of Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Well, I didn’t keep my promise in my last article clearly, but if you always look to the past mistakes, you fail to fix them in the future. In my last article, I talked about how I wanted to change this publication, or rather actually start writing for it (if you haven’t checked it out you can take a look at it right here). However, I forgot to mention one thing though. As designers, we have to look at the world and see design in everything, but we should also appreciate good design, both form and function. So in order to do that, every now and again I will be writing articles about some product or design that are designed really well. For our first ever showcase, we start at a hackathon, StarterHacks. My friends (myself included) created an app to help others with a simple problem: Waiting in line. Now without further ado, let’s see what it’s all about.

Meet the team

Aside from me (if you don’t know me you can check me out here, our team consisted of 3 members, each of which had a certain specialty to make this app work.

Shivam Pandey — Student, Mathematics, University of Waterloo

Shivam is well versed in Python, which was essential to the development of this app. More importantly, he knew how to visualize the problem and logically connect all the actions we needed to take and that the user would make. He was in charge of connecting all the systems together.

Ali Zohair — Student, Mathematics, University of Waterloo

Ali is a fast learner, which meant that he could adapt to any situation that we faced. In the case of our app, we needed to store phone numbers in a database. This is where Ali shined, learning and implementing a simple Database for us to store information.

Hossein Mohebbi — Student, Computer Science, University of Waterloo

Hossein knew that this app needed to use some third party API, and learned the essentials of the Twilio API so we could handle user interfacing through MMS. He also worked on the business side by helping to develop the pitch and key graphics.

So What Exactly is Crowd Control?

Have you ever gone to a conference where you were excited to explore and learn, but ended up waiting in a long lineup before you could? Have you ever been so hungry that you would push everyone in front of you out of the way just to get a slice of pizza? You have faced one of the major problems conferences have: lineups. Lineups cause many issues for people waiting in them and people managing them. Organizers face issues such as inefficiency and safety concerns. Users end up fatigued and annoyed. Even worse is that the time you wait in lines is valuable time you could use for other activities. Now, there are a variety of solutions already on the market, but there are many problems that aren’t solved:

• Single Screen Systems — Users need to wait for a screen to show their name/number
• Cost/Weight of the system — Some systems are really nice for big conferences, but are still hard to implement due to how many components there are
• System Requirements — Some require apps which are only usable on certain operating systems, and more support increases costs

In all these issues, one key component was overlooked: We carry around a device that is connected to the internet all the time. So why not use it to wait in line. That is why we created Crowd Control. A single user interface for everyone, their texting app, could be used to wait in lines.

How does it work

The app uses 4 components. We created a dashboard in React for the front end. This was simple enough for any organizer to use, and is scalable. More importantly, the dashboard only pushes info to the API. This means more security because the data only interacts between the server and the API’s, which means less access. This brings us to the main part of the app: The Flask API. The Flask API acts sort of like a train switching station. It receives calls from the dashboard which either gets data from the SQLite database or passes information to the Twilio API. We used Axios and Flask to communicate between the front-end to create call patterns, which was easier than using Fetch because we only needed POST commands. We created a SQLite Database because it can use local storage and is lightweight, a key factor in our design. Finally, we created a separate Twilio API Handler, which communicated between the phone’s messaging app. This also helped with scalability, as we would only have to change certain variables. Relatively simple in theory, much harder in practice.

So What Happened?

During development, our whole team as on deck working on an individual component. The react front-end was made as simple as possible for the pitch. The main aspects were the back-end components. Using Twilio allowed for us to not only send messages to all types of phones, but could allow us to scale to Facebook Messenger, Whatsapp, and email. Our database selection used a single table with three columns: phone number, status (boolean) and queue. The status tells us whether a person has already been called. For the query to call a user, we would pass it the queue number, and then the number of people we want. We would then select the people where status is false and the queue number is the one we want, and we would return a list of these numbers to the Flask API and call the Twilio API to message those users. We then delete these rows from the table. The benefit of this system is that the front-end doesn’t see the numbers, and thus is more secure.

What We Learned

A lot of the development was about learning how to develop on a team. Approaching the problem from a modular standpoint allowed us to be able to target specific components without overlap. We also learned the importance of planning. By creating tracer bullets, we allowed ourselves to break out the functions into the inputs and outputs we desired. Finally, we learned time capping projects. Sometimes you can’t add a feature you want in a short amount of time. If the deadline approaches, make it presentable enough that you can get your point across, and then improve afterwards.

I hope to be doing a couple more of these when I find cool projects others have worked on or some of mine. If you like these give me a clap and I’ll keep making them.

Design Showcase — Crowd Control was originally published in Matters of Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Wow, it’s been a while since we’ve written something. Since I started University, it has been one crazy event after another. Because of this, I haven’t had much time to post any new content (in fact, we’re still on part 1 of Gamify It: Survivor). For this reason, I must apologize. However, I’m glad to say that we are going to be back for 2019, with some amazing new ideas and great content for you to enjoy. So let’s put 2018 behind us and look forward to 2019!

What’s up next

We had a huge list of goals for 2019 in terms of MoD, but we narrowed them down to a shorter list. For one, we really want a good stream of content coming out, so we want to post at least 2 articles a month. We don’t exactly know if this will be purely biweekly, but we know that is the minimum. We also have some great new series that we will be starting. I’m happy to announce that we have a team of designers who will be conducting a design sprint for the next month or so, and we will be covering all the updates. We also want to revamp Gamify It. When we last left off, we had laid the groundwork for minimizing the game of survivor to some key mechanics, and we are hoping to continue building on this, looking at implementation and strategy. Furthermore, we want to actually look at other ways of Gamification and applying to the world around us. The reason we started Matters of Design is to take a look at the real world from a design perspective, and in 2019 we want to hit that hard, looking at everything from education, business, economics, sports, healthcare and more. Finally, we want more interaction with our users. We want to see what you create and we want to have a conversation on design, so we want you to comment on the stories with your input, and hopefully, we can begin to create content that you want as well.

One last thing…

Because of my busy schedule, and my limited team, we are looking for a couple extra writers. This would be a great opportunity for you to expand your portfolio and horizons by writing about the world in new ways. I am looking for people who are committed and can bring some unique perspectives to MoD. If you are interested or have any questions, please reach out to me on LinkedIn or email me at khalid.talakshi@outlook.com. I look forward to hearing from you.

Innovation is all around us, and it’s our job to look at the world and see how we can make it better. I can’t wait to write more in 2019 and hear from you about your designs and thoughts on design. Until then, Happy New Year and I’ll see you in 2019!

Looking to 2019 was originally published in Matters of Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Welcome to Matters of Design’s Gamify It, a new series on taking everyday situations and ideas and applying game design principles to either turn it into a game, or improve on it through gamification.

So today, we’re are gonna look at the hit show Survivor and turn it into a playable game. Now I know what you’re thinking: “Survivor is already a game, so what’s the point?” Well its not that simple. You see, creating a game requires both mechanics (the concepts which allows the game to advance) as well as other design features, such as player group size, board size, and much more. Survivor provides a great foundation for the mechanics, but the design is still wonky. How can you replicate an island challenge show? For that, we need to go through the design process and help flesh out some of the details. Without further ado, lets get into it.

Medium of Play

The first step is to determine how the players are going to play this game. There are 3 systems we can use: Video/Digital, Board, and Tabletop/Pen and Paper. Video/Digital Systems use technology such as PC’s and Consoles to play games. These can be useful for a variety of different games, but limit how much physical interaction there is. For a game like Survivor, we want that engagement to not only be present, but the forefront of the game itself. Board games are great because it does require some physical interaction, but there are limitations such as resources needed and space needed. You don’t want to have a huge board to play on, but you need a huge space for this game. We can’t have challenge locations and island locations be the same. With Tabletop games, it allows the players to create their own narrative within a controlled environment. Thanks to a Game Master aka Jeff Probst, players will be able to make decisions, but ultimately it will be up to Probst to decide whether or not it works and how well it does/doesn’t. So our medium of play will be a tabletop game, with a Game Master.

MVP — Minimal Viable Product

Now that we have where we are going to play it, we need to figure out how we are going to play it. For this, we need to look at the core mechanics of how Survivor works. Based on the show and what has remained constant (or relatively constant) over the years, this is what I have determined to be the key mechanics:

• 16–20 “Castaways” (Players) Divided up into 2–4 “Tribes” (teams)
• 3 day cycles*
• Challenges for Immunity (safe from the vote) and/or Reward (improve camp life)
• Team Socializing/Alliance Building
• Tribal Council, where players vote to eliminate one member of their tribe from the game.
• Merge at x castaways left (can be as many as 12 and as few as 9)
• Eliminated players form a jury post merge
• Final castaways (2 or 3) plead their case to the jury
• Jury votes on winner

I have put an asterisk next to 3 day cycles because while this is not an advertised mechanic in survivor, it can provide strategy with timing, but can also be changed at the Game Master’s discretion. Now lets take these mechanics and make them manageable. I have a few problems with some of these mechanics.

• The requirement for a minimum of 16 players is going to be hard to gather for many people. We need to find a way to reduce it down, or be creative with a smaller number of teams
• The challenges cannot be purely based on character stats, but should be played in real life by the players. For this we can use simple puzzles and minute to win it challenges.
• Team socializing is a big part of the game, but often times the other tribe shouldn’t know whats going on at the other beach. One simple way is to divide the players up by half and ask them to remain in a certain part of the room while they socialize.
• We need a catch up/kingmaker/saving grace mechanic as well (this can be through the hidden immunity idols mechanic).
• Survivor has secrets, so you need a way to convey those secrets. Simple notes to the GM can be helpful, just pass them to the GM during socializing time.

Player Requirements

Looking at the player requirements, it becomes difficult to acquire 16–20 players to play a 3 hour game. Lets take a best cause scenario and say we need at minimum 11 players, 10 castaways and 1 Probst. Survivor can range anywhere from 13 rounds to 15 rounds of play, with a merge at around round 6 or 7. If you eliminate one player each round, by round 3 or 4, you would have to have a merge, and by round 8 or 9, you would have final tribal council. Those aren’t bad numbers, but you could do better by adding an extra “Island Twist”. These are special islands where voted off castaways go to get a chance back into the game. There are 2 different island twists, and 1 potential one.

• Exile island: In the show, players would be sent there and return the next round or in time for tribal council. The exiled player wouldn’t be able to strategize with their alliance, but could find a twist, such as a hidden immunity idol at this island. For our game, you could send people to exile after they have been voted off, and can potentially influence the game with an extra jury seat (i.e. all the players on exile can vote as one juror, or one exiled castaway can win a seat on the jury). This means one player gets 1 chance to stay in the game, or act as kingmaker.
• Redemption island: It may be herald as the worst twist in Survivor History, but can be really useful in the context of this game. Eliminated players go to Redemption Island, where they can play in head to head duels to win their way back into the game. This essentially makes the game 9–10 rounds instead of 8 or 9.

Now I said there’s one more island twist, and that is Island of Extinction. It works similar to Redemption Island, but with a few changes:

• Eliminated Players can choose to exit the game or go to island of extinction. They would then sit there until the merge.
• Once the merge comes around, island of extinction players battle to get back to the main game. One player moves on, the others remain on the island.
• This continues during the merge phase, until there are 3 or 2 players left (depending on FTC format). Players on Island of Extinction will battle again to get back into the game. The rest form the jury. At this time there will be 3–4 players left in the game, meaning you have one last challenge before FTC. The last player joins the jury.

The problem is that we don’t know how this will turn out in real life as we have never seen it before, so heed caution. If your pool is greater then 10 people, you can use other twists if you would like (I think the Outcast twist would be awesome).

So we have the foundations for our Survivor Game, now on to build it. You can do this on your own, or wait until the next part where we begin to build the game.

The tribe has spoken, good night folks.

Gamify It: Survivor was originally published in Matters of Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

People think that programming is some sort of complex art, a skill of high difficulty. However, just like any professional, we all started off in the same place as all of you. In fact, many of us don’t know everything about every language. It may seem difficult to start to learn, but I am here to help you get started and tell you a little about my story of learning to program.

My Journey

I started programming when I was 9. I wasn’t sure how to get started either. My first introduction to programming was through a Lego Mindstorm RCX robotics kit. These were the really old ones where, like before the days of NXT and EV3. These wasn’t typical programming where you typed out languages but rather dragged blocks which had different functions on the screen. As I grew older, I began to delve into more languages. My first was HTML (which on its own is a debate for another day). I began developing websites for school projects and my own personal development. From there I learned CSS, which helped me create better user interfaces for people who wanted to use my websites or other apps. I wanted to expand my horizons, so I began to learn C# to build Windows apps and games using Unity. I continued my journey with PHP, Javascript and Python. Today, I teach students how to build their own website using HTML and CSS.

What I’ve Learned

Over the course of my learning journey, I faced both triumphs and trials. I always knew learning any skill was hard, but never have I struggled with anything more than I have learning new languages. Its not like learning a new spoken language like French or Spanish, but more like learning an advanced version of English. Along the way, I also learned some tips and lessons that I think every new programmer should learn.

1. There are tons of ways to learn. Find the best one that suits you. If you like to read, try and find some books. There are tons on programming. More of a listener or want to watch? Video tutorials are abundant. I personally love to get my hands into it, so I build projects. Mix and match also. No matter what there is no wrong way to learn.
2. Pick a particular area you want to study. No one is going to be able to learn everything all at once. It’s better to make some short term goals and work your way up. If you want to build websites, look at HTML and CSS. If game design is more your style, go for C# or C++. App design is widespread and you can use many languages. There is tons of overlap in language and areas of programming.
3. Pace yourself. You don’t want to overwhelm yourself with a lot of information, but also don’t want to forget the language you are learning. Find the balance that fits your schedule and stay strict to that. And whatever you do make sure you keep the languages your learning straight. You don’t want to use PHP when you should be using JQuery.

This is by no means a comprehensive guide on how to learn programming, but hopefully this helps spark the flame on your own journey.