Creating an entirely new engine from the ground up (Java Project)

[Quendus]

The best language to write a roguelike is the language you're most comfortable with. Ignore the people telling you to use different languages, use Java. The real problem is that you should start by writing a game, not an engine.

[Trystan]

Here's my simple step by step guide to successfully creating an entirely new engine from the ground up:

• Write the smallest roguelike you can. Just spend an evening making an "@" and some walls.
• Refactor mercilessly.
• Extract and reuse some code to make a slightly larger roguelike. Try a new feature, technique, algorithm while you're at it.
• Go to #2.

Your common code will become more and more generic and more and more useful. Eventually you'll have your own engine that handles the most common things: input, output, worldgen, pathfinding, etc. If you look at anyone who's made a successful engine like TOME or some of the libraries used by 7DRL authors, this is what they did.

[Quendus]

I don't entirely agree with that. Here's my step by step guide:

• Make a game, perhaps using Trystan's method
• Repeat N times:
• • Make a game in a similar genre to the first, reusing any useful functions and classes from previous games.
  • Put any newly reused functions and classes in a separate "engine" project.
• Neaten up the engine project so that it's obvious which components need to be added to make a game.

If you base your engine code on one game, you'll end up with a toolkit that enables you to make that game. Better to make more than one game and extract the common elements that you'll want in future games.

[Trystan]

If you base your engine code on one game, you'll end up with a toolkit that enables you to make that game. Better to make more than one game and extract the common elements that you'll want in future games.

I see your point but overgeneralizing can have it's own set of problems. If you somehow made something where it's equally easy to make a game of any genre then you'd end up with a programming language. If you want a roguelike engine then focus on making a bunch of roguelikes.

[TheCreator]

So can or can't it? I've had C++ programs successfully finish and return results that are bogus and even non deterministic because of memory corruption. An uninitialized pointer that accidentally points to a valid address is enough.

I've already told that memory corruption, albeit annoying, is not such a big problem. The biggest problem is complexity. Java is very susceptible to this problem because you need a thousands of classes that do nothing but the library you use (or the language itself) forces you to have them in your code.

That's one thing, the other is that Java programmers are too lazy (haven't I already mentioned that?) to do anything right. C++ folks always expect the worst. If they write a new function larger than three lines, they typically test it in thousand ways before they dare to actually use it. Java folks just move on to writing next function - if it compiles, it's done. On the other hand, they tend to write huge classes that do nothing really useful, but fulfill some stupid design pattern they don't even understand. I'm not saying that all Java programmers are like that, those who know C++ are certainly not, but advicing Java to newcomers is like letting a child to drive a real car - it's easy, you don't even have to touch the wheel, the computer does everything for you... Right?

[Quendus]

If you base your engine code on one game, you'll end up with a toolkit that enables you to make that game. Better to make more than one game and extract the common elements that you'll want in future games.

I see your point but overgeneralizing can have it's own set of problems. If you somehow made something where it's equally easy to make a game of any genre then you'd end up with a programming language. If you want a roguelike engine then focus on making a bunch of roguelikes.

Agreed. If you want a roguelike engine, it should be based on the common elements of some roguelike games. But not on the common elements of subsequent versions of a single roguelike game, because there's no basis for generalisation if there's only one datapoint on which to base the generalisation.
For instance, consider movement blocking. You might implement a game where you can't walk on a wall tile, and incorporate that into an engine. You might generalise that into having a function that lets a tile report whether it's blocked or not, or a map function that takes a location and reports whether the tile is blocked. But if you then try to make a game with thin walls, or ghosts that can move through walls, or water that can be passed by actors who can fly or swim, it turns out that the original generalisation was the wrong one.
It takes more than one game to find the right generalisation.

[wire_hall_medic]

Java is very susceptible to this problem because you need a thousands of classes that do nothing but the library you use (or the language itself) forces you to have them in your code.

No, Eclipse forces you to use a thousand classes.  I like jGrasp; it's minimal, and doesn't tell me how I should code.

That's one thing, the other is that Java programmers are too lazy (haven't I already mentioned that?) to do anything right.

Are you sure?  There's quite a few of us.  All, or even most, sounds like a pretty ridiculous claim.

I code professionally in C++ (and sometimes in Java) and code in C++ at home to relax .

Wow, being a worthless Java programmer must really be a challenge for you at work.

[Quendus]

Calm down, I haven't heard the Javan pope or the C++ian pope declare holy war this week!

[guest509]

I will second the concept of ALWAYS HAVING A PLAYABLE GAME.

Make basic movement.
Make walls.
Make a bad guy.

Expand from there.

If you are a good programmer you can have things be editable with text files and stuff so the engine is separate from the game. But having an always playable game keeps you motivated.

[Trystan]

For instance, consider movement blocking. You might implement a game where you can't walk on a wall tile, and incorporate that into an engine. You might generalise that into having a function that lets a tile report whether it's blocked or not, or a map function that takes a location and reports whether the tile is blocked. But if you then try to make a game with thin walls, or ghosts that can move through walls, or water that can be passed by actors who can fly or swim, it turns out that the original generalisation was the wrong one.

And that's why you keep iterating and trying new things.

It takes more than one game to find the right generalisation.

I think we both agree with each other - I just under stated how important it is to try new things. That's how you end up with useful abstractions and generalizations.

[Quendus]

For instance, consider movement blocking. You might implement a game where you can't walk on a wall tile, and incorporate that into an engine. You might generalise that into having a function that lets a tile report whether it's blocked or not, or a map function that takes a location and reports whether the tile is blocked. But if you then try to make a game with thin walls, or ghosts that can move through walls, or water that can be passed by actors who can fly or swim, it turns out that the original generalisation was the wrong one.

And that's why you keep iterating and trying new things.

What if those incompatible elements aren't part of the design of the game you want to make? If I made a game with solid walls, I wouldn't later on be interested in converting that game to use thin walls - that would be something for a different game. It's nice to experiment with different game mechanics, but sometimes you have a specific idea in mind for a game mechanic and no intention of using alternatives - that's why an engine should be based on more than one game.

But yeah, we do agree - both of our guides start with making a game, and end with an engine, not the other way round.

[Trystan]

What if those incompatible elements aren't part of the design of the game you want to make?

Isn't this the opposite of your earlier example? Where having solid walls was the wrong generalization for something that has thin walls and that's why you should consider games from other genres?

Not only do I think you need to make a game before a game engine, but I prefer to make several small games - sometimes just to try an idea or new feature. For example, I have today off and I'm looking into FOV. With my current framework it takes me about 10 minutes to have a simple @ running around bumping into randomly placed walls. Starting with that, I can try different ways of implementing FOV (raycasting, shadowcasting, etc) and try different ways to use it (traditional "what can the player see", light from light sources, blast radius for spells, etc). By the end of today I'll understand field of vision better and have a few more things to integrate back into my framework. I find that trying to add new systems or big features to a big game has a very different feel and very different results than trying it on a throwaway evening project. I'd learn much more from implementing twenty 1 day roguelikes than I would from one 5 year roguelike. But that's just me - some people are very intent on making their one big game and nothing else.

[Superjoe224]

All right guys, so what I got from this is really helpful, and yes TheCreator I know C++ also, I just enjoy using Java as miki151 said for portability.
Thanks so much, I wasn't expecting to find 2 pages let alone 2 posts! But I will siphon through some of the discussion about whether I should use C++ or Java and take switching as an option in the future if I hit an impassable wall with java (because, like I said, I know C++, and a little C for that fact ).
Thanks a lot guys, I'll keep you all posted if you're interested?

[TheCreator]

No, Eclipse forces you to use a thousand classes.  I like jGrasp; it's minimal, and doesn't tell me how I should code.

As of IDEs, I prefer heavy stuff (like Eclipse). Minimal environments are usually nothing more than an editor with syntax coloring. Much too little for real programming. We don't live in the 80's anymore. Eclipse is quite shitty with C++, but for Java it is probably the best.

[AgingMinotaur]

Thanks a lot guys, I'll keep you all posted if you're interested?

Please do. That's what we're here for Have fun.

As always,
Minotauros