Learn to make game engine from scratch or learn existing game engine?

Newbie & Debugging Questions
#1

Hello awesome JGO people,

I have been programming for the past 3 years. I have mainly only worked on Minecraft mods for Bukkit/Spigot. I have learned a lot about programming and I feel I have enough experience now to start trying to develop my own small game. As far as Minecraft goes, I spent a year making a MC RPG which turned out nice, but not nice enough to make a server out of it.

I want to stop wasting my time creating MC mods. If I am going to learn to make my own games with Java this is the time to start. I have purchased 4 books on Java Game programming. Each book has similar approaches to solving problems. However, as I work through the books and learn new techniques I ask myself if it is really worth it. I wonder if my time would be better spent learning an existing game engine rather than reinventing the wheel. My thoughts are if a game engine has been seen, debugged, and worked on by hundreds if not thousands of people, then why not use existing work. Why not learn their engine and spend more time making a game then learning about code I will never use because an existing game engine is what I will use in the long run.

What do you, a fellow programmer, game lover, and enthusiast, think is the best path to take?

Thank you for your guidance!
unenergizer

#2

It really depends on what you want to focus on learning.

Personally I think using an engine and/or pre-existing libraries is a good way to start. That way you can focus on learning how to build game mechanics, story lines, etc. rather than getting bogged down in the huge amount of work that’s required to build the low level support functionality.

Going the other route then you should try creating something you “think” should be very easy given your programming skills.

#3

On the other hand I meet a lot of programmers who’ve never really gotten down into the bowels of programming and how things really work and the moment they come across something off the beaten path it’s all confusion and forum posts and frustration. We all suffer from this to one degree or another - as soon as the topic of 3D maths or fancy OpenGL rendering comes up I just throw my hands in the air and ask @theagentd to sort it out - but the more you know the less frequently you need to bother a specialist and wait.

What you should do first is decide on your game. What it will be, what it needs to achieve, what it needs to look like. Then have a think about the technology required to do that, and decide whether there’s something else that easily does the job for very little extra effort (libgdx for example will probably just save you a load of hassle), or whether what you want to do is probably beyond the capabilities of some pre-existing library (which is hard if you don’t really understand how those pre-existing libraries really work).

Cas :slight_smile:

#4

There’s also the issue that java games can’t be distributed as applets anymore which is a real pity. Executables are the only real way to go to distribute your java game.
There appears to be a trend that many non-AAA games, such as casual games and so on are being programmed in javascript perhaps with webGL targetting the browser, iOS objective-C targetting the iPhone, and java targeting android phones.
You might want to keep this in mind when choosing an engine and language.
Thankfully libGDX can be coded in java and compiled or transpiled to all of those platforms.

#5

Right now there’s a few engine’s out there, most of them are in development though… LibGDX seems to be the end-all if your looking for an engine in any sense. It’s probably one of the most well documented too. (Documented as in tutorials not javadocs that is)

Creating a game engine that ports to android, browser, ios, and desktop all at once is an extremely hard effort and they did a very good job on that. I’d say you should work on a game engine for the desktop in your free time while learning to make a game in LibGDX. This can teach you a bit on how you should couple things together if you read the source of LibGDX also.

CommanderKeith: I don’t think applets dying are a pitty… :persecutioncomplex:

EDIT: Forgot to mention LibGDX is apache lisenced also, so it’s great for profitable games also.

#6

If you want to focus on making games, learn how to use an engine. It’s a tool so why not? If you want to focus on building engines, build the engine. This isn’t a one or the other situation.

Why not learn how to program while making games? ;D

The real question I think you’re asking is “should I learn to program”, which is a question you have to ask yourself, not anybody else.

Edit: Also, I think this is in the wrong board :wink:

#7

I went this route with my new game. Instead of using any engine I decided to program from scratch, and have learned so much more than if I had used an engine. Granted I’m pretty new to programming games, but I still learned a lot of the “whys” that come with doing certain things.

#8

Have a look at a presentation from Camilla Berglund (she is the author of GLFW) about render engine design: http://www.elmindreda.org/lectures/opengl-lecture2.pdf
Especially the sentence on page 23 that there is no such thing as “the” (generic) render engine, and that every engine is about increasing ease of use at the cost of flexibility. This is orthogonal to whether you use OpenGL or Java 2D or whatnot. And also whether it’s a render engine or whole game engine. You have to know what kind of game you want to make before evaluating the fitness of existing engines or before you know you need to write an own engine to help you (or others) in productivity when developing the game.
It’s just that people start writing engines before they even know what that engine should be fit for. That always leads in a dead end because nothing is driving the design of the engine. Nothing but the hunches of the engine developer about what “good code” and object-orientifyng everything might look like and trying to integrate every render technique he/she read about on the internet, which always necessitates redesign and ultimately having no clear goal.

#9

The only way to write an engine is to write several complete games.

#10

I’ve been working really hard at a full-blown “game engine” over the past year or so, on and off. It’s an incredibly large workload, but I’ve honestly found that it’s really given me a far better understanding of the bowels of what goes on inside a lot of large-scale games, and it’s also through poking around engines’ documentation and even playing games based on them and observing certain practices that are used (note: I’m not referring to game mechanics, but the way the mechanics themselves can be implemented) that I’ve been able to build a semblance of an engine for myself.

It is not a project for the faint of heart. I find myself even questioning why I should bother, why I bothered in the first place, why I didn’t use a full-blown game engine and have most likely completed the game that I actually set out wanting to make, but for me the answer was simple and it’s one that I come back to every time - it’s not how I, as a programmer, work. Sure, I could’ve cut the workload into an eighth of what I’ve got currently, but I found myself unwilling to learn the ins and outs of a game engine that abstracted a lot of the fundamentals away from me. In the end, I would have maybe learned how to make a game, but I wouldn’t have learned better programming techniques or satiated the curiosity that’s been driving the development of the thing.

By on and off, I mean every month or so I’ll plug a heck of a lot of work into it, move it that one step further towards an alpha or a beta and beyond, before I lose the confidence to keep going and forget it for a while. This is something you’ve got to consider, whether you’ve got the time, effort to put into it and the motivation to succeed. I don’t mean to try to scare you away from it, but I’m just stating this from my experience - my voice is not the only one so please take into account all of the other posts in this thread and any more to come, they offer just as valuable advice.

But if you want to know what sort of work goes into an engine (well, my engine), this is what I’ve discovered so far:

  • you have know the language. I know this seems simple enough but when you get into actually programming the beast you’ll find that it’s so many individual functions communicating with one another beneath the surface, you have to avoid sloppy practices and bloat in your code or else you may end up finding yourself on a bug hunt through tens of thousands of lines of cruft and have no idea what the code means any more.
  • time management is key. you can’t leave endless unimplemented functions scattered in several classes, they will build up and you’ll find yourself returning to a much larger workload than you wanted.
  • you’ll need means of storing, accessing, saving and altering so many different sorts of assets. Images can be simple enough to use, but when it gets to things like animations, or storing a game’s storyline, or a tileset, or items, or dialogues for NPCs, or particle effects, you’re going to need to have effective ways to use them - I opted for a Manager paradigm to keep all types of data together and to be able to access them from the right places and be able to keep it all consolidated. There aren’t any “standard” formats for these things, you’ll need to roll your own (I can share some implementations), and they take a lot of thought.
  • rendering. you need an adequate understanding of your chosen graphics library (I opted for Java2D for simplicity but may port it over in future) to be able to provide abstraction to the end-user but enough flexibility to provide power over what goes on. it’s a balance you need to find.
  • documentation. whether or not you’re the only one working on the engine, or the only one who’s going to use it, you’ll have difficulty remembering every single intricacy and function provided by the engine so you will have to provide extensive documentation. Granted, that may be one of the last things you do but even things like comments describing functions’… function will help you remember what your code actually does. Several IDEs (I don’t know if they all do, I use NetBeans) allow you to comment functions and variables in such a way that the comments appear as though they’re JavaDoc.

Those first two points and the last one apply to any decent-sized project really. Another point is that your code has to be self-documenting, because you may potentially be not the only one working on it and it could slow your development down.
At the end of all this - I am programming my game engine as a means to an end. I fully intend to complete the engine and use it in a game and I know that the familiarity I’ll have with it will allow for a lot of ease through the game development process. You need to decide why you want to write one and if any of the things I’ve said hasn’t deterred you then I wish you all the best, it’s been difficult, I’ve made a lot of the mistakes I mentioned for myself, but I’ve had fun doing it and I hope you do too if it’s the road you choose to take.

#11

Yes it’s true that applets were never well implemented by sun. But the lwjgl guys including kappa did a very good job of the lwjgl applet loader. Marcus Person, who used this applet loader, actually attributed some of the success of Minecraft to the ability of potential customers to try the demo applet game in their browsers without installing anything, since most had java installed already in those days.
It’s a big pity that applets are no longer supported. Our java code must be turned into JavaScript now.

#12

I want to say thanks to everyone who has contributed to this thread. I really do appreciate the input of everyone here.

I understand their is wealth of information that can be learned from making your own engine. However, as humans, our time is limited. I would much rather spend my time writing games then reinventing the wheel. I know and understand that at any time, I can always come back to and learn about building a engine. For now I have decided to learn libGDX to see what I can come up with. I took advantage of a book sell, and purchased two $5 USD books from packtpub.

While this route may be frowned upon by some, understand that my real interest is making a game. Something that I would love to play.

Once again, thank you for all your help and all of your advice. It is greatly appreciated.

Have a wonderful weekend everyone!

#13

that’s the only right way :slight_smile:
you can’t write a game engine without having written any games… every game engine in existence has grown out of an actual game

so good luck on your game!

#14

Things really depend on what you actually want to achieve - what your application really needs. In many cases you can simplify things so much that really not much knowledge and work is needed to get the base framework for your project. One really simple rule I’ve learned in my programming lifetime is to never over-generalize things - and the limit of the generalizations is the visible horizon, stepping one step beyond will get you lost.