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

[MagicManICT]

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.

This might have been true 10, maybe even just 5 years ago, but more and more are based around Ureal, Havoc, Unity, and other engines.

[Granger]

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.

This might have been true 10, maybe even just 5 years ago, but more and more are based around Ureal, Havoc, Unity, and other engines.

Which could explain why they more and more look and play identical.

One thing is sure: I wouldn't build something in an environment that I can neither maintain nor reproduce, so a closed source (or proprietary license) tool is out of the question.

[CTheRain]

Whatever you do if you make a game like H&H don't remove all the combat and limit teching up to just LP gain.

[MagicManICT]

Which could explain why they more and more look and play identical.

They've been clones of WoW since 2004, and WoW was more or less a clone of EQ when it first released. (I like to call it "EQ lite".) There are exceptions, of course, but you could quite literally change the quests and everything else to something Azeroth based and you'd be playing a crappy version of WoW. At least Blizzard took some of the better concepts from a variety of sources and tried fixing some of the flaws of games like EQ, Anarchy Online, UO, and Dark Age of Camelot.

Looking back, I kind of wonder if WoW was in development already and some of the designs were in place when WC3 came out. Given the manpower and time it takes to develop a AAA MMO (well, any MMO, tbh), it had to have been. I just wonder how much of those designs were put into WC3 to what was being done with the WoW development, and what was put into WoW to be consistent with the Warcraft UI style.

Guess I've probably strayed off topic, but kind of not if the message someone were to get would be "don't just make another clone. make it better than what inspired you."

[loftar]

Benefit is simply that you can make more, with less.

Supposedly so, at least. Every piece of external code is a cost and a liability, though, and especially so for something so complex and loosely defined as a game engine. Whenever you're using an external library, constant and fixed costs include having to learn the library itself (which can be a huge task in and of itself, especially for complex things like game engines); having to adapt all your constructs and structures to the precedents established by that library and basically having to think in its terms; always having to adapt your needs to the library, rather than the other way around; and, of course, having to ship and deliver the libraries with your program in some reasonable manner. There are also very real risks, including, but not limited to, the library not doing something you need it to do, in which case you may well be stuck; or encountering a bug in the library that you are the only one to encounter and which the developers aren't interesting in solving; or a future update breaking something crucially central to your code.

That's not to say that all libraries are worthless, of course, but in order to be worth using, the benefits they bring can't be trivial. I too use libraries, of course, but I tend to be more comfortable around libraries that do a very constrained and well-defined task. Examples of external software I use include libraries and programs like GnuTLS, BSDDB, LLVM, the Python Image Library, Jogg/Jorbis, and, of course, GCC, JOGL and Java. (In that list, it is somewhat interesting to note that JOGL is among the libraries that have given me the most amount of trouble; there are surprisingly many bugs in JOGL that are simply being triggered in slightly unusual environments. Somewhat surprising, since one might imagine JOGL doing a very limited and well-defined function in just wrapping OpenGL calls.) Other things I've tended to avoid are pre-packaged web frameworks.

All that being said, I don't really intend to be overly negative in using game engines – if the idea of really learning to program appalls you and you really just want to get that game you have in your head into the real world, I'm sure they can provide shortcuts. Just know that those shortcuts come with costs, risks and limitations. And also that, to the extent that it indicates you're just being impatient, you're probably not going to have a good time anyway.

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.

To be sure, my greatest learning journey during the making of Haven/Salem has been that of OpenGL. When I started making the 3D client with Salem, I still basically hadn't even an idea what a GPU really did. It is only relatively recently that I've started to consider myself having a somewhat firm grasp on how modern GPUs "want" to be used through OpenGL (and even with that said, there's a lot that's still unclear to me). For me, one of the things that made OpenGL difficult to learn is the amount of outdated or otherwise incorrect information out there, which makes for a terrible amount of confusion as to how one is supposed to use OpenGL. One of the main things that come to mind is the commonly repeated wisdom that switching textures is expensive – that was certainly true 20 years ago, but it doesn't seem to have been true for a very long time by now. Arguably, reading about Vulkan is a better way to understand modern OpenGL that reading about OpenGL is.

It can be mentioned that, when we first started with Salem, I did strongly consider using a rendering engine instead of writing my own – the one I considered was JME. I spent quite a while going back and forth, but I ultimately rejected it precisely because I deemed it very opinionated about its rendering model and data structures. While I could certainly see the journey of writing my own rendering engine a long one, I also saw all the frustrations I was going to go through maltreating and beating up JME in order to make it do what I wanted it to do (Java is enough of that as it is).

With some decent game engine such as Unity, HnH would be better optimized without a doubt.

Perhaps, but another very real possibility is that it would simply not have existed at all that way. And, on the contrary, if you're doing something which causes performance problems in Unity, good luck trying to trace down why that happens and how to fix it.

basically asking, what does NOT using a pre-packaged engine even bring to the table?

To summarize the above: It avoids the frustration of a pre-packaged engine not doing what you want it to do and being bound to its world-view.

[xChapx]

Benefit is simply that you can make more, with less.

Supposedly so, at least. Every piece of external code is a cost and a liability, though, and especially so for something so complex and loosely defined as a game engine. Whenever you're using an external library, constant and fixed costs include having to learn the library itself (which can be a huge task in and of itself, especially for complex things like game engines); having to adapt all your constructs and structures to the precedents established by that library and basically having to think in its terms; always having to adapt your needs to the library, rather than the other way around; and, of course, having to ship and deliver the libraries with your program in some reasonable manner. There are also very real risks, including, but not limited to, the library not doing something you need it to do, in which case you may well be stuck; or encountering a bug in the library that you are the only one to encounter and which the developers aren't interesting in solving; or a future update breaking something crucially central to your code.

That's not to say that all libraries are worthless, of course, but in order to be worth using, the benefits they bring can't be trivial. I too use libraries, of course, but I tend to be more comfortable around libraries that do a very constrained and well-defined task. Examples of external software I use include libraries and programs like GnuTLS, BSDDB, LLVM, the Python Image Library, Jogg/Jorbis, and, of course, GCC, JOGL and Java. (In that list, it is somewhat interesting to note that JOGL is among the libraries that have given me the most amount of trouble; there are surprisingly many bugs in JOGL that are simply being triggered in slightly unusual environments. Somewhat surprising, since one might imagine JOGL doing a very limited and well-defined function in just wrapping OpenGL calls.) Other things I've tended to avoid are pre-packaged web frameworks.

All that being said, I don't really intend to be overly negative in using game engines – if the idea of really learning to program appalls you and you really just want to get that game you have in your head into the real world, I'm sure they can provide shortcuts. Just know that those shortcuts come with costs, risks and limitations. And also that, to the extent that it indicates you're just being impatient, you're probably not going to have a good time anyway.

One thing i still dont understand about game developing is where do you start, is the structure chaotic? is there some paradigm i have to understand first? my last programming project was a compiler and it had an structure: lexicon, syntax, semantics etc..

is there something like that for video games?

[loftar]

is there something like that for video games?

Sure, but it depends on what you want to do, more precisely, just as how the compiler structure you described is probably specific to a language with a context-free, limited look-ahead token-based grammar with a regular token parser. Just like you'd need quite a different compiler structure in order to parse a language like Befunge instead, a 2D and a 3D game will have quite different requirements on structure, for instance.

[Potjeh]

To be fair Unity is fairly permissive when it comes to replacing parts of the engine with your own. For example, the guy sitting next to me at work is currently working on instanced rendering which bypasses the default rendering pipeline (AFAIK), and I think he hasn't run into any hard blocks. I personally have opted to write my own physics instead of using Unity's, because thanks to constraints of the projects I'm working on I can get away with using simpler (and thus lighter) physics calculations.

Also, Unity has actually pretty decent profiler.

Anyway, I think the main argument for using a ready engine is rapid prototyping. This is especially important when you're just getting into game development because seeing results is crucial for morale, plenty of aspiring developers gave up when they burned the first month without even getting anything rendering on the screen.

[sMartins]

Anyway, I think the main argument for using a ready engine is rapid prototyping. This is especially important when you're just getting into game development because seeing results is crucial for morale, plenty of aspiring developers gave up when they burned the first month without even getting anything rendering on the screen.

Yeah, exactly ... I wanted to say the same.
J&L of course are right, when you want to do stuff seriuosly you need to make them by your own, but here we are talking about kids that want to know how to make a game, at least from my understanding, so first thing I would suggest is to study and learn math and physic at school, then start small with javascript on your browser with the notepad, have fun coding something with a space ship that follow your mouse and maybe shot a laser when you press some button on the keyboard.
If you succeed to do that, and are still interested ... then yes starting to study a good language from zero probably is your best bet.

P.S. I'm not a coder at all, only studied a bit of c++ in university and some more things ... more or less I know how it works. It's an hard job guys and it drive you crazy, sitting all day long in front of a screen. So it require a lot of dedication and some skill too.
Maybe H&H could look just a simple game at a first look, but it's not, most of all for only 2 people, they did and are doing wonders with A LOT of work behind the scene.

[shubla]

first thing I would suggest is to study and learn math and physic at school

I highly doubt that physics and coding has that much to do together. You dont really need that much math either, depends on what you do of course, but with most of coding you can manage with pretty basic maths that are easy to learn on your own. Although physics and mathematics both require and probably develop your problem solving skills, analytical thinking and such which are all needed when you code something, because that is exactly what you do when you code. Solve small problems to solve bigger problems that together form something greater.