Hi, so I’m trying to recreate Yu-Gi-Oh in Unity online, and don’t know exactly how to do it. I’ve thought about having two different boards next to each other, and show each player only one board, and while that would work, it would be a hassle.
I’m not trying to make something big here, just for me to click “host”, and play with my friend, nothing bigger.
So, what would be a solution to have it work? I’m still really new to everything online.
To get started, it can be helpful to look at existing examples for inspiration and understanding. For example, I found that the Spades game on http://www.aclockworkbrain.com/spades does a great job showing how an online card game can run smoothly, with easy-to-use controls and gameplay that keeps you hooked. It’s also important to think about backend development to handle player data and make sure everything runs seamlessly online. From my experience, using a framework or game engine can really speed up the process, making it easier to bring your card game vision to life.
Multiplayer by it’s very nature is “something big”. You need to learn how to use a networking framework including how to set up lobbies and matchmaking, and you need to learn how to build a game that is made for multiplayer. You should be able to find tutorials for Mirror and Photon. Starting with an existing framework off of the asset store might work but you need to know how to work with someone else’s code which isn’t always that easy.
If I were you I would probably start with single player first. If you succeed, you can try to add multiplayer on top of it, because multiplayer is complex and requires a lot of knowledge. For starters, look for tutorials, something like this: https://www.youtube.com/watch?v=XsC9DiOZlVI&t=220s
I don’t recommend this approach for the simple fact that creating a single player game is wildly different than creating the same game but with multiplayer. Unless you’re creating a simple game it’s not “add multiplayer on top of it” but rather “completely redesign and rewrite it for multiplayer”.
I kinda agree. While for an experienced developer it can be an approach to first complete a single player game, however experienced developers keep their goal in mind and know their “dos and don’ts” so everything is designed in a way it can easily be leveraged to multiplayer. Doing the singleplayer “wrong” would mean to start from scratch or run into countless of dead ends along the conversion process.
Even bigger games like MMOs generally start with their database, server and API design before they even approach the actual game. This is a good basic reference for MMOs.
I would agree for a VR game, FPS or other types of games with advanced interaction with the gameworld.
Since it can be hard to retrofitt MP into those complex state machines.
I’ve read the other replies but I believe you have several alternatives. First, have you mentioned the client? I have only ever worked with Unity on VR but I will assume that is not what you are doing. So forgive my dumb question but is this hosted on a website or installed somehow?
If it is some sort of web-hosted app and your needs are truly “a second player” then it is entirely possible that you wouldn’t need any sort of multi-player library / services / server. Programming in my head for a minute I have to assume you can process API requests and responses. There are countless libraries that would help with the basics. And I (assuming again) believe that you could chat directly between the two web clients.
Re: single-player first vs multi-player first I will suggest doing both simultaneously. You work on the parts that are needed to move forward on your project. So right off the bat some sort of display that everyone sees. Step 1 done. Players key their names in and press the “ready” button. Step 2 done. But you need both players to sync the names and acknowledge the button presses.
So now you work on the multi-player part of it. Find out the simplest way you can get that data sync to work. Move on to the next item on your list.
Do not work on “the easy parts” thinking you will get to the harder parts later. You can refactor the parts you have in place when (and if) they cease to meet your needs but try not to defer requirements that are fundamental to your completing it.