I have 2 great ideas for a video game one is for a fighting game and the other is for a fps/tps(haven’t decided which view to use). My question is what would be easier to make a fighting game or a shooter.
I have 2 great design documents for the games and know exactly what features I want in each game. I have stated before I am a sophomore now junior in Computer Science I have been programming in java and c++ since 2011.
It depends on what kind of fighting game or shooter game it’ll be and what skills you have. If you have two great design documents, you should know which of them are easier to implement. Just follow you thoughts.
For a fighting game animation quality is of high importance, while for a shooter normal quality is fine enough.
So it also depends if you are able/have someone who is good in animations.
(1) don’t overtheorize.
Keep reading as it’s good. You need the theory first. But don’t forget to do things in parallel. It’s important.
You will probably fail a lot but you will learn a lot too.
(2) don’t be too ambitious. Start with little and humble projects (aka “don’t start by making a MMO”).
Ambition is good but too much of it and you’ll fail, or be discouraged as you won’t get results soon enough. Seeing you are making progresses and getting results will give you the motivation needed to go further.
According to my humble 20 years experience in computer sciences (not only games) (1) and (2) are always true.
Let’s say you want to make a fighting game … Just do it as soon as you feel you understand enough of the theory. Don’t be afraid to rewrite large parts of your game or even rewrite it.
Failing fast is learning fast too.
Between the two I think a shooter may be easier to start with.
Fighting games can be among the ones that are the hardest to make. Not just animation wise, but balancing wise. It is extremely easy to have a fighter that sucks and / or one that is invincible and there may be glitches that can easily be exploited and ruin gameplay (specially in multiplayer). It requires multiple playthroughs and a keen eye for small details in order to identify and address the issues of the fighting games (that are naither bugs nor glitches… things like balance and performance). It depends on your design document for this fighting game the scope and complexity it will take you. My advice here is to test the hell out of the game and study a lot of fighting videos (martial arts, boxing, etc) since Mocap is well… expensive.
Shooters, in my opinion, are among the easiest to make. It is very easy to set up a prototype and programming the base mechanics is easy without complex models as @Pesegato mentioned and you can tune up and learn as you go. Starting small in a shooter is easy as well and you scale up or add more layers as development progresses without difficulties. The advice here is to have a series of small prototypes (movement, ragdoll, weapons, etc) and then combine them together
Thanks everyone for the thoughts. I also thought A fighting game would be more difficult.
Okay both games would have multiplayer the shooter would have competitive and co-operative aspects. And the Fighting game would have Arena fights something like 1 v 1, 2 v 2, 3 v 3. With that being said I would want to have all the basic game play worked out before I even thought about adding multiplayer( I dont know if this is the right approach though). Also the shooter would have a lot more Multiplayer than the fighter because it is mainly Co-op with Competitive aspects. Where as the fighting game would be more of a single player game and with the ability to go online and compete against others in an arena. In the shooter no more than 10 players and in the fighter no more than 6 players.
And at the moment I am alone so all graphical aspects or done by myself.
I strongly suggest doing the server first, and making the server controll everything.
Eg clients only send timestamp + keypress, and server applies it to its own view of the data. Then sends the world state to all clients. For 10 clients a rather rough networking system works, aka sending the whole worldstate to each every 20ms.
Understand, if you’ve never made a networked game before, it makes the game 100x harder to develop.
There is no crime in starting with something simpler first.
Edit: but yes if you insist on going the hardest way first then yes you want to start with the server and game logic first. SpiderMonkey will get you part of the way there. Then you will have to pick an architecture and implement your messaging.
If you are going to write a network game then you must start with the network part first.
Whatever you do, don’t fall into the trap of writing a single player game and thinking you can “just add networking” later. It’s a nearly complete rewrite.
That being said, I strongly urge you to write a single player game first.
make a single player FPS. No networking at all. Gain lots of experience. Impress your friends.
make a networked FPS. Start with the networking. Do the networking first. Always do the networking first. Else you will likely never finish and have pulled all of your hair out long before then anyway.
Adding networking to a single player game after it’s already built is a lot like adding an ingredient to a cake once it’s already baked and frosted. “But I’ll do it before I frost it…” doesn’t make it any easier. If you don’t start with the ingredient, it’s going to be nearly impossible to bake it in later.
We all need to learn to crawl before we learn to walk, making an online multiplayer game without learning to make a FPS game on JME first is almost suicide. You need to learn to make games with JME first before starting to make an online game.
Make a simple FPS game without multiplayer. Focus on the single player only and just focus on getting the game mechanics right. It doesn’t have to be a finished game to see. But you need to know to make a basic FPS first, use simple models and textures and work around it until you have something that satisfies you. Use this to get experience mainly. Do not think of multiplayer here, just focus on a playable prototype (have as many prototypes as you need).
After this, you are going to start over, make the FPS game but this time you start with the networking code and apply what you have learned with the prototypes you made before.
I’m btw. the guy who started with a MMO game XD, now in the third iteration of the basic engine around 8 years later, it is actually coming together.
So if you don’t want to spend 8 years, start simple.
Networking is the most i would do for my first game, and then copy already established simple logic.
Quake 3 networking would probably be the most easy.
Just send every x ms alll client positions, all upgrades, spawns ect, to everyone.
Clients then move locally, but upload their position and (important!) the server checks if the movement is actually possible, eh speedhack, jumping midair ect.
This is all depending on logical model. When it comes to networking you have to build infrastructure first with all that connection sockets processing and all that stuff which gives you nothing visual basically. So you have to be strongly motivated to start on that. IMHO