What do i need to learn to make a game like haven and hearth

[NOOBY93]

I am very skeptical of the pre-packaged engines, and I think you'll grow more long term from picking up a solid, industry-standard programming language, instead of the specifics of some particular prefab engine.

I know close to nothing about this stuff so correct me if needed and don't take this the wrong way but Haven in terms of graphics and mechanics looks like a super simple game to me, yet it still turns my laptop into a frying pan and makes it have a seizure when there's more than 15 people on the screen at a time. Do you think it would've been even worse if you made the game on a pre-packaged engine?

[jorb]

The scenes get fairly complex, and many of the scenes you find problems with probably render more individual things than many other games you might be playing, even games which are more AAA, or whatever. One feature of Haven is that players are in almost total control of the scene, in terms of how much crap they can put into it, and that is hard to optimize away entirely.

That being said, loftar is working on a major overhaul of the rendering pipeline, so there are certainly a lot of things we can and will do better.

Idk. The question depends on too many specifics to be meaningfully answered. Performance is not in any way a simple function of engine choice.

[NOOBY93]

The scenes get fairly complex, and many of the scenes you find problems with probably render more individual things than many other games you might be playing, even games which are more AAA, or whatever. One feature of Haven is that players are in almost total control of the scene, in terms of how much crap they can put into it, and that is hard to optimize away entirely.

That being said, loftar is working on a major overhaul of the rendering pipeline, so there are certainly a lot of things we can and will do better.

Idk. The question depends on too many specifics to be meaningfully answered. Performance is not in any way a simple function of engine choice.

well I'm not criticizing the rendering in Haven right now, there's no need for that, because it's already being worked on, it's more of a half-question I guess, basically asking, what does NOT using a pre-packaged engine even bring to the table?

[jorb]

My -- admittedly not extensive -- experience is that whenever you depend on external libraries, you end up writing a lot of wrapper functionality to fit someone else's square pegs into your round holes, or vice versa, which means a lot of -- sometimes quite costly -- duplication. It also means accepting someone else's structures, data types, execution flows, &c&c. All of that can be good and well -- arguably that is precisely the reason you want to rely on externals, i.e. not writing everything yourself -- but if you want to get into game building then I think the task you need to get down and dirty with more than anything else is precisely programming, and if you do all of this as a learning experience, then I think learning a good language from the ground up is a better way in than attempting to hack together a game real-quick in some high-abstraction level type external environment. You need to crawl before you walk or run, and if you've never done any of this stuff before, then I think making a computer say "Hello world!" using a straight-forward but low level language can be a pretty empowering experience.

When using externals you will not seldom spend a significant portion of your time learning and attempting to find documentation for the external, especially when debugging, which can be extremely frustrating if your particular problem, or some aspect of it, is unknown to the internet. I would rather be good at generalized coding than at in depth knowledge of some particular derived platform.

One caveat here could be that 3D rendering is a huge topic, and you might, perhaps, be better off using some established engine for it. Then again, basic OpenGL is not impossible to learn or use either.

I recommended SDL earlier, since I have used it and been happy with it, and what that does is to provide functionality for "media" handling -- audio, video, window control, mouse, &c, with some simple but still accelerated rendering commands -- writing all that nonsense yourself, especially if you're attempting to build a cross-platform game, is an excercise in frustrations that I am glad to have an external for, but the problems outlined above are also very real when using it.

Write it yourself and you will have more control over, and a better understanding of, what you're doing, quite simply.

[MagicManICT]

The problem you mention, jorb, of learning the engine and trying to debug problems is offset by the time you're going to spend trying to properly optimize an original system to get reasonable performance out of it. The game industry says the former is the general way to go unless you have a lot of money and manpower to throw at engine development due to the time and effort it takes to develop the rendering engine.

At this point, I'd applaud you guys for switching to something like Unity, but then it might be a long spell of little development while the client was completely rewritten from the ground up. Don't really blame anyone for sticking with what's already here unless there's a bottleneck reached and the only practical way through is to make that change.

[Granger]

Honestly, I see little point in switching to an engine like unity (or something similar) because there already is a client that is working - IMHO quite good for a single persons work.

It is a completely different question if someone (especially one that doesn't have years of coding experience) should write an engine from scratch or better use one so all the low level stuff is taken care of and one can concentrate on what you want to do: building a game.

I would say that using a pre-existing engine in that case is the only sane approach these days (at least for an Indy style developer). Doing an own engine from scratch in that scenario might be interesting should one really be into learning (which will take some years, full time), but even then it would be the smarter decision to start with an existing one (preferably fully open source with free license, like the one I linked) to at least get an initial clue on how to structure such a project (to skip months or years of try and error).

[shubla]

Based on Python

Sounds worse than go.

I am very skeptical of the pre-packaged engines, and I think you'll grow more long term from picking up a solid, industry-standard programming language, instead of the specifics of some particular prefab engine.

Benefit is simply that you can make more, with less. If all you want to make is a game, picking up some engine is not a bad idea, instead of starting to struggle with rendering pipelines and other complicated, not that much game(design) related stuff. Many very successful games have been made using unity. And without doubt, more will be made. Risk with game engine might be that they just stop further developing it, and when your game is compeltely dependant on the game engine that is no longer being developed, you are quite limited with the stuff that you can do.

For example, you could grow your own wheat and bake bread, bust most people just grab a mass-produced package from the store, because its easier. Although maybe not cheaper or healthier than doing the whole process yourself.

I know close to nothing about this stuff so correct me if needed and don't take this the wrong way but Haven in terms of graphics and mechanics looks like a super simple game to me, yet it still turns my laptop into a frying pan and makes it have a seizure when there's more than 15 people on the screen at a time. Do you think it would've been even worse if you made the game on a pre-packaged engine?

In short HnH client is just coded badly, especially rendering part, without rendering enabled the client runs quite nicely, if I remember correctly.
If properly implemented on some decent popular game engine such as Unity, it would be a lot more efficient without a doubt. Of course, unity barely existed when development of HnH was started.
Also I guess that some reasons why the client is so inefficient rendering-wise is because it has been developed over a large period of time, so stuff is maybe implemented in a way that would be regarded as bad these days. And maybe loftar wasnt so skilled when he started making HnH, and would do many things differently if he started coding the client from scratch today. But that would take a lot of time, and if whole client has been built on top of some bad decisions in the beginning phase of coding the client, fixing those things is not that easy as it could cause a lot of problems with stuff that has been later implemented, dependant on some previous functionality of the client.


With some decent game engine such as Unity, HnH would be better optimized without a doubt. But that necessarily does not mean that some other game engine should be used.

[Granger]

Based on Python

Sounds worse than go.

Not having curly braces hell is a plus for some, while others seem to like them.
Godot engine built in IDE seems to have good support for dealing with the lack of parenthesis.

Oh, and mono will be a first class citizen in the 3.0, in case you like to wait for Godot... It also gives you the full source of the engine, so the issue with it being abandoned isn't that bad compared to a commercial one where you only get a binary (or have to trade your house and firstborn to get something that actually compiles into something useable).

One thing that would make H&H hard to port to a mainstream engine is that several places load code on demand from the server (a flexibility that is hard to impossible to implement using commercial engines), as the client is just a remote presentation layer for the server.

[Zampfeo]

I personally would write a custom engine or at least my own renderer for something like Haven and Hearth if I wanted terraforming/mining. Because so much stuff is user created, less things can be baked in. Stuff like the location of objects and especially the terrain put a lot of strain on a client and will require custom optimization an engine like Unity isn't prepared for out of the box. Check out this video of a guy programming a minecraft-like engine in a week: https://www.youtube.com/watch?v=Xq3isov6mZ8 It's really interesting looking at his strategies for optimization.

One thing that would make H&H hard to port to a mainstream engine is that several places load code on demand from the server (a flexibility that is hard to impossible to implement using commercial engines), as the client is just a remote presentation layer for the server.

I don't think that would make it any harder than a completely custom client. You'd of course need to program your own server and client communication code either way. Engines like Unity and Unreal definitely support that. Off the top of my head Mortal Online is a MMO using Unreal. Speaking of which, it also makes it REALLY easy to hack since any hacks for other Unreal games can and have been ported to MO.

[Gensokyo]

I'm quite certain that Loftie isn't too familiar with C# as it's support for linux was pretty much null until mono came along, and I'm also certain that adapting to Unity would worsen things if anything trough both the first point and the lack of actually being able to modify the source code of the engine (meaning you'd have to, again, jump hoops and build things upon already existing things).

MMOs are generally kept on custom made engines as using an already pre-made one will most of the times just have you doing more work that a custom engine would've taken.