Temple of The Roguelike Forums
Development => Programming => Topic started by: MeowMeow_Prince on January 31, 2014, 04:14:01 AM
-
I would like to start making my own RL, But don't know where to start
if possible I would like someone to point me in the right direction
- I have previous experience in C++ and other languages and am also willing to learn a new language to do this.
-
I started developing my roguelike in Python, of which I had actually no previous experience. I was taught C# at my school but Python isn't that much different language.
There's this nice tutorial on roguebasin. I took the final code from this and started adding stuff to it.
http://www.roguebasin.com/index.php?title=Complete_Roguelike_Tutorial,_using_python%2Blibtcod
-
When I started, I had *no* experience with C++, only some GameMaker (and an ADA-course).
I used SDL, and followed these excellent tutorials for making a simple SDL game:
http://lazyfoo.net/SDL_tutorials/
I think it worked out well for me. I just tried to get a game running, and learned more C++ concepts as I went along.
I had no idea how other roguelikes were made, I invented my own solutions for everything, which was more fun at first. Of course I made lots of horrible mistakes1, and I've had to refactor things over and over. But it was a good learning experience.
1In the very beginning, the map was an array of integers. These integers represented different terrain types. So maybe 0 was floor, 10 was wall, 20 was grass, etc. These were only referred to by their integer value throughout the code. For example when the map generator created a room, it put a bunch of zeroes in a rectangular area. When the player was walking, the game checked that the cell you attempted to walk into was != 10. I had text files on my hard drive which listed the integers, and which terrain they represented!!! This was before I even knew about enumerated types....
Now after two C++ courses, and several thousand hours of programming, my code looks very different :D
-
Depends on your programming approach:
- Top to bottom: Get the source from one of the many open-source RLs out there, tinker and change stuff. Or start from libtcod.
- Bottom to top: Start with mini prototypes, e.g.
- generate a map
- do some pathfinding
- do some los/fov
- do some ai
- add some stats
- instantiate monsters out of the stats
and so on and so forth. Again, you could check libtcod for some of the above bits if you don't fancy doing everything yourself.
You could also follow this: http://www.roguebasin.com/index.php?title=How_to_Write_a_Roguelike_in_15_Steps (http://www.roguebasin.com/index.php?title=How_to_Write_a_Roguelike_in_15_Steps) or other nice articles in RogueBasin.
I don't think there's a universally right direction, just find what's right for you in terms of not abandoning the project, not losing motivation and getting things done.
-
Take the quickest route possible to basic user interaction. "@ walking around a map" is a common phrase, but of course it might be a sprite. Once you have a game you can play, you can start adding other things to the game. The 15 steps article is good; I followed it loosely when I made my first roguelike. Of course you can skip a lot of steps and do the last five steps in any order.
I prefer SFML or libtcod as a display library, but if you do use SDL I would second the recommendation of the tutorials on lazyfoo.net.
For languages, go with whatever you're most comfortable or fluent with. Writing a roguelike can be a complex task and it's easier not to combine it with learning a whole new language.
-
I'm only part way through my own game but I'd say its a good idea to start with the level generator before combat or ai or magic or other things.
That can be one of the hardest parts because if the level generation isn't convincing or interesting the game probably won't be either. In a randomized game world the level layout is your "plot". How you move through the level is what shapes your gaming experience. If the map is too random the player may feel lost or bored, not random enough and it gets repetitive very quicky.
Placing rooms is just a start. How will you populate and decorate those rooms so they're not just empty rectangles? Will you have keys for doors? How can you keep one area secure while making sure the required key is not inside? will you have puzzles? They are a big part of rpgs but randomized puzzles are not easy to program without a lot of planning.
Anyway, I agree with most of the 15 steps but I think random level generation is something worth investing in early on.
on the otherhand you may want to get a working game first an leave perfecting procedual generation until later.
-
If I were to start today I'd go for python and libtcod.
The reasoning is that
1. Easy to learn, trivial if you have any other programming experience.
2. Lots of code to look at already.
3. Common programming language you might use later in professional life.
I DO NOT recommend any of the game engines to start out. Like Gamemaker or Construct. Not for Roguelikes. I use Gamemaker but I learned to program first. It's not built well for turn based games, though it's doable.
Unity would be good to use and learn if you were looking to make 3D games. In fact if you want 3D that's pretty much the only way to fly from what I've been told. But again, learn to program before you jump into that.
There's also the T-Engine used to make TOME4. Some people like that one, it uses LUA files and has a lot of common Roguelike things already implemented.
-
I had aspirations for a long while, but I hadn't programmed in anger since Uni. Late last year I stumbled across Jotaf's python tutorial (the one Aukustus links to). Within four-ish days I had it up and going and enough of a handle on Python that I was adding my own content and mechanisms. I find Python easy to prototype in so I can rapidly implement ideas and see what they looked like. Now my project is almost un-recognisable from the tutorial.
-
I would like to start making my own RL, But don't know where to start
if possible I would like someone to point me in the right direction
- I have previous experience in C++ and other languages and am also willing to learn a new language to do this.
Someone already mentioned using libtcod and following the Python tutorial on RogueBasin. Since your experience is in C++ I would recommend trying out Code::Umbra's tutorial (http://codeumbra.eu/series/complete-roguelike-tutorial-using-c-and-libtcod) since it is based in C++. This way you won't have to learn the nuances of Python to get up and running quickly.
Also make sure you frequently reference the libtcod docs (http://doryen.eptalys.net/data/libtcod/doc/1.5.1/index2.html?c=true&cpp=true&cs=true&py=true&lua=true).
-
Don't read tutorials. They are not games and often written by poor programmers.
Look at the source code of actual games, good ones, and try to figure out how it works.
-
If your thinking about "where to start" involves musing over whether you need to learn a new programming language, you're light years away from doing anything serious with computers (although I'm sure you can find people who will tell you writing a roguelike game doesn't qualify on that count). You need to find an excuse to write a real program (something at least several thousand lines long that performs a commensurately nontrivial task), maybe something for school or whatever. When you're done with that, you'll be able to decide what more, if anything, you need to know to be able to program a roguelike game or something like one.
-
Don't read tutorials. They are not games and often written by poor programmers.
Look at the source code of actual games, good ones, and try to figure out how it works.
I think this is (mostly) good advice. Some people learn very well from tutorials, but if they don't help you improve, you should definitely avoid them.
Reading source of other games can also be very valuable. That and learning how to really understand official documentation will go a very long way.
If you want to jump right to learning the best way possible (although, may be a bit slower learning) then go to the docs and examples of GOOD source code.
-
If your thinking about "where to start" involves musing over whether you need to learn a new programming language, you're light years away from doing anything serious with computers (although I'm sure you can find people who will tell you writing a roguelike game doesn't qualify on that count). You need to find an excuse to write a real program (something at least several thousand lines long that performs a commensurately nontrivial task), maybe something for school or whatever. When you're done with that, you'll be able to decide what more, if anything, you need to know to be able to program a roguelike game or something like one.
As a computer science student I'd like to advise against this*. You will definitely learn a lot when writing "real programs" or learning via college courses, but you won't be learning how to make games. In fact, you will learn a lot of things that are either completely useless in making games or detrimental when making games. If you want to learn to make games, there is only one way to do that: make games.
*My advice is given in a black and white format but there are always exceptions. I just don't want you to think that you need a college course or that you need to write generic software in order to learn. You absolutely do not need to do those things.
-
If your thinking about "where to start" involves musing over whether you need to learn a new programming language, you're light years away from doing anything serious with computers (although I'm sure you can find people who will tell you writing a roguelike game doesn't qualify on that count).
He didn't say he's completely new to programming; he said he has previously used C++, and asked if other languages would be more suitable for roguelike development.
And as for that question, MeowMeow_Prince, I'd say if you're familiar with C++, then go ahead and use it. There's really no "preferred" language for roguelike development; everyone uses what they're most comfortable with. I personally can't stand C++, but then that's just me ;)
-
If you want to learn programming, sure, start from scratch in Python or C or whatever floats your boat.
If you want to see results speedily without having to do "@ moving around" stuff, you could use T-Engine. It's Lua-based, really powerful and allows you to dig in immediately.
-
If your thinking about "where to start" involves musing over whether you need to learn a new programming language, you're light years away from doing anything serious with computers (although I'm sure you can find people who will tell you writing a roguelike game doesn't qualify on that count).
He didn't say he's completely new to programming; he said he has previously used C++, and asked if other languages would be more suitable for roguelike development.
Well, perhaps I'm reading between the lines here, but the OP's question strongly suggests to me that his experience with "C++ and other programming languages" is at best rudimentary. If your question is "how can I write a turn based game with a console interface?" and you "don't know where to start," it stands to reason that you haven't gotten quite around the block as far as programming goes.
As to whether you should actually learn to program before you try to write a roguelike game, I've spent a fair amount of time reading code for angband and its variants -- I can say unequivocally that it would've been better if the people who wrote these games had first learned to program before embarking on those projects. I mean, something as simple as reading SICP would've gone a long way.
-
Learning to code by writing a spaghettiRL is a time honored and fun educational method!
-
You need to find an excuse to write a real program (something at least several thousand lines long that performs a commensurately nontrivial task), maybe something for school or whatever.
How about a roguelike!
I get the impression that a decent chunk of the major roguelikes were started by people who didn't know what they were doing and did it all wrong. And yet, here we are.
-
Learning to code by writing a spaghettiRL is a time honored and fun educational method!
I know how to code well and I still end up with a god class and spaghetti code on day 6 of the 7dRL. Which is fine since I'm planning on not working on that particular code again :)
As to the "where to start", if the goal is to make a game use ToME or RPG Maker or Project Spark, or Alice, or whatever. If the goal is to learn programming then get the Head First series book for your desired programming language and read it / do what it tells you to.
-
On a related note, what material would you recommend for somebody (me) who has zero programming experience but would want to try his hand at making a roguelike?
Besides that 15-step tutorial on roguebasin, of course.
Thanks for any help.
-
Stone Dog, I'm going to give you the hard message.
You aren't going to make a roguelike unless you learn to program. You don't have to be awesome at it, but unless you learn to program you aren't going to make a roguelike. You aren't going to make any video game at all unless you know how to program. Hell you cannot even design or do the art, music or effects for a game without knowing how to program a bit.
Thankfully after one programming class plus the tutorial you mentioned you should be good to go. If you are no longer in school then after working through one programming book (python!) you should be good to go.
Those of us that use game engine programs, as Eben mentioned above, like TOME (t-engine), we actually know how to program. The T-Engine, for example, uses LUA to make things happen. That's a programming language. Some will call it scripting, but that's a distinction without any real meaning in this context.
Game making programs actually require you to know how code is written and structured. We use them because we have no interest in recreating certain functions and would rather use a higher level (inefficient) system instead of getting bogged down in the minutia.
If you don't want to program but still want to make games then you need to make board games. You cannot make computer games without knowing how to program.
-
Stone Dog - pick up T-Engine or RPG Maker or whatever, and then start learning how to program in the language the engine uses. That's how I learned enough Lua to be able to keep Veins going.
There's a lot of free resources for most programming languages used.
-
@ Jo
Sorry, I was tired and didn't explain myself properly.
What you said was already crystal clear to me (especially after faffing around a bit with the 15-step tutorial: I can sort of understand what I'm copying, but sure as hell I couldn't do anything on my own).
My goal would be learning a language while trying to code some sort of RL, so I meant to ask if anybody here knew about a manual or something that explained a programming language while explaining how to code some sort of game.
Long shot, I know.
Guess I'll choose among one of the hundreds of tutorials floating around the net (if someone had recommendations on that, please, I'm all ears).
@ Zireael
I was thinking of learing Python, to be honest. Anyway, is the T-Engine very flexible, or am I going to end up with something close to TOME (which I dislike)?
Also, OP, sorry for the thread hijack.
-
Anyway, is the T-Engine very flexible, or am I going to end up with something close to TOME (which I dislike)?
It's immensely flexible, just take a look at Darren Grey's Mosaic http://gamesofgrey.com/ (http://gamesofgrey.com/) (scroll down)
-
Oh yeah t-engine can do a ton of things.
-
You need to find an excuse to write a real program (something at least several thousand lines long that performs a commensurately nontrivial task), maybe something for school or whatever.
How about a roguelike!
I get the impression that a decent chunk of the major roguelikes were started by people who didn't know what they were doing and did it all wrong. And yet, here we are.
A roguelike can be a real program or it can not be. It's pretty much true that some of the more prominent examples in the genre started out using C arrays as their workhorse data structures and never really got past that. These games have had the benefit of twenty to thirty years of ferment and gained popularity in an era when anything that allowed you to move something around on a screen was sure to impress someone.
Roguelike projects today rarely go anywhere, so maybe it doesn't matter anyway, but if you want to bring something new and interesting to the table, you should expect to use algorithms and data structures you wouldn't come up with in a late night of coding. I don't really see the point of writing throwaway projects, but I may be in the minority here.