Temple of The Roguelike Forums
Development => Programming => Topic started by: Superjoe224 on August 23, 2013, 03:40:29 AM
-
All right, first off Hi Y'all! I have been a huge fan of rougelikes (angband, Rouge, TOME, POWDER) and similar games (likeDwarf Fortress mainly) and I really REALLY want to make my own preferably in Java (1.6/1.7 hopefully).
I want to make this game from my very own engine, the only problem is I've never created an engine for a rougelike. Now don't misunderstand me, I know how to program (I wouldn't be going to University for it if i didn't know how, but I digress).
Mainly what I would like to know:
1) any GOOD open source code that I can take a look at (preferably one that is not entirely impossible to follow, and also has comments)
2) suggestions on any good Java supplements to creating a rougelike (addons, 'cheats'/shortcuts the like)
2b) my current IDE is Eclipse 4.2.2
3)Youtube/non-youtube videos on the subject (man, I love watching videos. I used to watch TheCerno program java)
Also I would like to hear from the other developers, their tips and tricks, their 'most common problems' the like. I know it seems like I'm kinda just coming here and demanding these things, but I'm having a hard time locating anything 'useful' from google atm.
Thanks in advance,
Superjoe224
-
I think Java is a great choice for RL development. You can easily port things between mobile, desktop and browser. It's good to make your library and design choices now with portability in mind. Here's a list of Java RLs, check them out:
http://roguebasin.roguelikedevelopment.org/index.php?title=Java
Now don't misunderstand me, I know how to program (I wouldn't be going to University for it if i didn't know how, but I digress).
Yeah I thought the same when I was at University :D
-
Many people choose Java because it's easy. If you want to see something working quickly, and many people do (because people are impatient), it's pretty obvious that you want to do it in Java. Sure it will give you a great start, but what then? At some point your project will eventually get so complicated that language won't matter anymore. Now assuming that you've been programming only in Java for several years, you will be much less prepared for those problems just because Java programmers are too lazy because Java does everything for them. Let uncle Joel (http://www.joelonsoftware.com/articles/fog0000000319.html) explain this in detail for me. In short: learn C++ first and then maybe write your game in Java (if you still feel the need). Don't make the fundamental mistake and don't choose Java just because it seems to be easy. There aren't any good roguelikes written in Java.
-
Your hidden point is that someone who hasn't learnt a low level language will have problems with efficient code in high level languages. There is a lot of truth in it. But to religiously tell people to go learn C++ before they code in Java is another thing. A novice programmer starting a big project in C++ can only lead to disaster (of course it's the best way to learn). If you want to have a chance to actually finish something, I'd say choose and easy language and learn to use a profiler if your code is too slow.
There aren't any good roguelikes written in Java.
Oh that convinced me ;D
-
A novice programmer starting a big project in C++ can only lead to disaster (of course it's the best way to learn)
Yes, you should start from small projects. A novice programmer starting a big project is a disaster waiting to happen, no matter which language he will use. Complexity adds as many problems in C++ as it does in Java, but Java programmers are too lazy and unaware of the evils of the programming world, so that they are unable to deal with those problems.
If you want to have a chance to actually finish something, I'd say choose and easy language and learn to use a profiler if your code is too slow.
Lack of efficiency is only one problem. Besides, a Java profiler may tell you that a string operation (for example) is slow, but you will never know why until you learn to program in a low-level language.
Oh that convinced me ;D
Well, let's look at the "Big Five" from the Roguebasin page. All written in C or C++. No Java games. Does that convince you? :P
-
but Java programmers are too lazy and unaware of the evils of the programming world
If the language doesn't matter, why do you say anything like that? C++ programmers can be "lazy" too, so can it be generalized to all C++ programmers?
About engines, I think there is no reason to create a "generic" engine, because it's almost impossible to know what features a roguelike game requires. However, you can create an engine for a roguelike game with specific features in mind. That way you get firm support for those features which are part of the engine, not just something hacked in quickly.
-
If the language doesn't matter, why do you say anything like that? C++ programmers can be "lazy" too, so can it be generalized to all C++ programmers?
If C++ programmers get too lazy, they are punished for that sorely and either retire from real programming or change their approach, work hard and actually achieve something. Of course that does not apply to you because you never make any mistakes, do I need to add?
-
You mean a lightning bolt strikes you when you do a bad design in C++? ;D
-
You mean a lightning bolt strikes you when you do a bad design in C++? ;D
Something like that, but less spectacular (and more painful) :). In Java the worst thing that can happen to you is a "Null pointer exception" (Do Java programmers know what is a null pointer, by the way?), but that happens rarely to them, the Java deity is seemingly very forgiving. In the C++ realm, though, a slightest mistake results in a crash. If the C++ god is in a great mood, you only get a one-page-long compiler error which does not differ much from a string of random characters. Needless to say that C++ is a very unfriendly universe. If you want to survive there, you must learn how to code properly.
-
Needless to say that C++ is a very unfriendly universe. If you want to survive there, you must learn how to code properly.
It doesn't work like that. C++ doesn't make you learn anything about good programming. Someone may argue that it's the opposite, because C++ gives the freedom to do things very wrong. Besides whatever the language is really has nothing to do how and why you create the engine.
-
In C++ in a bigger project you tend to abstract away all the low level stuff into well tested routines anyway. So after a certain point programming in C++ is very similar to programming in Java, with differences only in memory management and all the surrounding technology. And the bugs are pretty similar too, the difference being Java catches them early on, and a C++ program can keep running with corrupted memory.
-
There aren't any good roguelikes written in Java.
Yeah, cuz Legerdemain sucks, right? ;)
Anyway, to address the original question: When writing a RL, I think it's quite common to learn from some mistakes in the beginning, having to restart a few times. So I'd say, just start coding and see where it takes you. Some common pitfalls or subtle spots include doors that can be opened and closed, containers, and stairs/portals between levels. Also, be mindful of memory leaks (twice as dangerous in a language with garbage collection, I believe).
I always found this article (http://roguebasin.roguelikedevelopment.org/index.php?title=How_to_Write_a_Roguelike_in_15_Steps) very inspiring.
As always,
Minotauros
-
There aren't any good roguelikes written in Java.
Lol.
IF there was a performance penalty from Java, a turn based genre like roguelikes are one of the most lenient genres. Most of the time, the CPU is just sitting there waiting for user input.
Usually, the complexity in roguelikes comes from interactions between items/monsters/players, and that has everything to do with the engine structure, and almost nothing to do with the language since you can get more than enough rope to hang yourself in both Java and C++.
I code professionally in C/C++, and code in Java/Python/anything else at home to relax...
Finally, I've been using this Java based framework: libGDX http://libgdx.badlogicgames.com/
Easily ports to Android and other platforms.
-
It doesn't work like that. C++ doesn't make you learn anything about good programming. Someone may argue that it's the opposite, because C++ gives the freedom to do things very wrong.
If you do wrong, you will be punished, like I said before ;). That's the best learning method ever invented (unless you like to be punished, of course). I wouldn't call that freedom. Otherwise North Korea is a free country.
And the bugs are pretty similar too, the difference being Java catches them early on, and a C++ program can keep running with corrupted memory.
No, a C++ program can't run with corrupted memory. Sometimes it will (notably when it is a debug version), but most of the times it will simply crash sooner or later. It's Java what tends to keep running even when there are serious bugs in the code. So the difference is that C++ programmer will notice and fix a bug quickly, while Java programmer will never learn what some of his bugs really are, because too much is done under the hood. He will either ignore the problems or get discouraged and drop the project. Isn't that what happens to Java roguelike games?
IF there was a performance penalty from Java, a turn based genre like roguelikes are one of the most lenient genres. Most of the time, the CPU is just sitting there waiting for user input.
I wasn't talking just about performance (but the truth is that Java is really talented at slowing everything down, even a turn-based game). Honestly, I don't know why complex Java games do not succeed. I'm only presenting my hypotheses here.
I code professionally in C/C++, and code in Java/Python/anything else at home to relax...
That explains much. I code professionally in C++ (and sometimes in Java) and code in C++ at home to relax ;).
-
No, a C++ program can't run with corrupted memory. Sometimes it will (notably when it is a debug version), but most of the times it will simply crash sooner or later. It's Java what tends to keep running even when there are serious bugs in the code.
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.
On the other hand, please educate me how a Java program can run with a bug that C++ would catch early on.
That explains much. I code professionally in C++ (and sometimes in Java) and code in C++ at home to relax ;).
I code (or have coded) professionally both in C++ and Java, so I'm smarter than both of you :P
-
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 (http://scientificninja.com/blog/write-games-not-engines).
-
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.
-
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.
-
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.
-
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?
-
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.
-
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.
-
Calm down, I haven't heard the Javan pope or the C++ian pope declare holy war this week!
-
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.
-
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.
-
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.
-
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.
-
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 :P).
Thanks a lot guys, I'll keep you all posted if you're interested?
-
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.
-
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