GoLionMk2
(GoLionMk2)
February 28, 2020, 9:49pm
8
If you’re productive with BP spaghetti, then it makes sense to keep prototyping in Blueprints. Otherwise you risk getting stuck in paralysis (or not being able to fully communicate core gameplay ideas to C++ coders). Its popular to prototype in Blueprints first anyway (a fact confirmed in numerous threads on here from experienced devs). The bigger issue is when should you start adding online multiplayer? Tricky to say, but your chosen game genre will offer clues.
For example, Its definitely possible to migrate a turn-based puzzle game or single-player shooter to multiplayer later on. Would you want to try that with RPG / RTS? Maybe not… Plus, while you’re designing a prototype, its hard to anticipate every possible angle or requirement. So there’s a risk that some time-consuming multiplayer code may actually get thrown out later, killing off precious time.
For that reason if you don’t have a team of specialists, I’d advise leveraging Split-Screen gameplay first, to test out all your ideas. There’s no replication or sessions or lag to deal with, and it will force you to think about core characters / vehicles independent of single-player gotchas such as player-controller 0 hardcoding everywhere.
As regards learning C++ or bringing someone on board. It’ll be interesting to see what others think… But making games with C++ is hell… Lets just say there are other more fun ways to inflict torture on yourself. So I would hire a dedicated C++ programmer instead. Someone who just eats this sht up 24/7. There are many types of C++ programmer too. Many won’t naturally gravitate towards online gameplay, as game work is such a highly-specialized field.
Something else to consider… Epic have accepted that UE4 C++ is NOT and never will be as SIMPLE as Scripting. It probably took the Enterprise crowd to persuade them. Because years of game devs pointing that fact out on here got nowhere. Overall, fully integrated environments like UDK / Unity are just MUCH EASIER. So with Scripting in the pipeline, what’s the point of struggling with C++ now if your gameplay doesn’t require custom engine work etc…
Thanks for the really insightful response. That helps me clarify things. I am generally not the strongest when it comes to coding any (takes me a long time to get a blinking LED with an Arduino) so I will likely take your advice and experiment with split screen, then seek out extra help if and when I have something I think anyone would care about
GarnerP57:
There is many approaches to C++ in Unreal.
You know the basics and use that knowledge to expose hidden events to Blueprint and do 98% of the work in Blueprint
You are proficient with C++ and Unreal and use C++ to deal with problems not easily dealt with in Blueprint. Somewhere between 50-80% of the work is done in Blueprint
You are an experienced C++ Programmer and have been using Unreal for a year or more and prefer to code rather than connect nodes in Blueprint. Perhaps 5-10% is done in Blueprint.
As soon as you start using C++ you have to embrace the world of debugging so if that is not something you feel like doing then you should definitely hire a programmer or try to deal with everything in Blueprint.
Garner, thanks too, that insight. I guess I was seeing it as either/or, but it’s nice to see the variety of options there…