1
Traditional Roguelikes (Turn Based) / Re: Quickband 2.0.5 released
« on: November 29, 2011, 02:18:37 PM »
Very interesting. Might just be the *band for those with short attention spans 
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
Other Announcements / Re: Grumphack. Anyone else see this?
« on: November 29, 2011, 02:16:29 PM »
Hah, not bad! Definitely subscribed to that channel.
3
Programming / Re: On the subject of Plot...
« on: November 29, 2011, 01:04:04 PM »So would you say that a pool of events, chosen randomly, coupled with an alternate-ending-type-thing, would be best?
This seems like the best idea. It gives you the best of both worlds: Having a plot while still remaining somewhat unpredictable/random.
Not too sure about the karma system since I've never played Fable.
4
Early Dev / Re: Red Rogue (platformer roguelike)
« on: November 26, 2011, 05:41:35 AM »
Neat game! I need to spend a bit more time with it, but so far I've been very impressed.
5
Programming / Re: Let's talk a bit about world map generation!
« on: November 24, 2011, 03:56:15 AM »You might not have shit to show for yourself after years of work. And in the end you might create something that only a few nerds care about. Just like developing a roguelike.
When I started developing my roguelike, I went in with the mindset that I was developing it for one person: Myself. I wanted a game I could play, and if by chance other people liked it then cool
Great advice overall!
6
Programming / Re: Peril: Experimental Survival Horror Roguelike
« on: November 17, 2011, 12:29:45 AM »
Personally, any fear would be eliminated by the fact that it's turn-based. In the situation Jim posted, I would simply stop, think, "What's going on?" and continue.
What WOULD be scary is if the game was turn-based up to the point the crimson Q appeared. The game would continue to tick, but the player wouldn't be able to move or react for a few turns. That would freak me out, but good luck making it work the second, third, or fourth time
What WOULD be scary is if the game was turn-based up to the point the crimson Q appeared. The game would continue to tick, but the player wouldn't be able to move or react for a few turns. That would freak me out, but good luck making it work the second, third, or fourth time
7
Programming / Re: Let's talk a bit about world map generation!
« on: November 17, 2011, 12:24:18 AM »
This is extremely cool! I'll echo the "complaint" in the comments that the biomes are a bit too "horizontal," but it still looks great.
Just a general question since I haven't heard of this project before: How do you like developing with Python? Anything in particular you've run into that would make you want to switch to another language?
Just a general question since I haven't heard of this project before: How do you like developing with Python? Anything in particular you've run into that would make you want to switch to another language?
8
Programming / Re: Python for a Rouge Like RPG
« on: November 16, 2011, 10:49:40 PM »
I am just going to address the topic directly. I've been developing a roguelike in Python for the past six months. I've went from only knowing a bit about game design/roguelike development to being mildly competent in both areas. I am by no means a genius or programming wizard, so maybe I can speak "on your level" to help you understand some of the finer points of what you're getting into.
Python is great for a lot of different things. Quick scripts to scan log files, neat little programs to speed up boring tasks, etc. Of course, the introduction of things like PyGame have brought the language into a different area of programming that is mostly dominated by people who want to learn a language just to make a game. That's fine, but only to a certain extent.
My experience with Python was pretty traditional and didn't involve games, but I quickly learned about PyGame and went from there. I made all the usual games, like Snake, Pong, and a whole pile of different things, but time passed and I wanted something with more depth. About a year went by and I started creating my first roguelike.
Python can be fast, but it can also be very slow. Unfortunately, learning a language just to make small scripts and games doesn't exactly teach you to optimize much. I was learning at a very fast rate that I had picked up some terrible programming habits from those small scripts where speed didn't matter. Example: If you're crunching a 50-line file even the slowest code will get the job done. It's when that file is a thousand lines long that you notice how slow your code is.
Thanks to this, my first level generator took five seconds to finish. Take note that most generators take less than half a second to finish and crank out sprawling worlds/levels. Mine was making a dozen rooms spread about and struggled on high-end hardware. Scary, and very discouraging. It's a year later and my generator can make potentially hundreds of levels in the same amount of time the old generator took to make a single one. That's just one aspect of the game, though. We've yet to talk about A* or Dijkstra maps yet.
So what's the lesson in all of this? You're not going to make a roguelike in Python unless you're willing to learn how to optimize it. People learn Python because you can jump into it without much prior programming experience, then get confused when their simple Pong clone struggles to render any higher than 20 frames per second. It's a high-level language that needs a bit of taming before it will do what you want at the speed you want.
I'm not trying to discourage you. Your design seems great, but it's going to take quite a large sum of cash to get someone to do all that for you when you could do it yourself for free.
Back to my story: I've been working on a roguelike for quite a long time. It's been a rough experience, but overall a HUGE learning experience. There's been times where I've erased hundreds of lines at once because it was too slow or hard to read after spending a week away from it, and that's usually when I learn the most. I promise you'll do the same multiple times.
And for the past few hours, I've been trying to squeeze every bit of speed I can get out of my Dijkstra map function. Turns out you really, really notice a 0.1 second pause every frame. Yet, from what I've seen, games like Brogue can generate multiple Dijkstra maps each frame without any change in performance. That's not too surprising, considering C is one of the fastest languages out there.
I will link you to my code if you're up for seeing how a Python roguelike works. I will warn you that while the code is in a public repo, it's still very much "hackish" and has remnants of unused code in places, but I'm willing to clean it up if you'd like to take a look.
In summary: A roguelike in Python would be easy to get started, but would be hard to finish. Your mileage may vary.
Python is great for a lot of different things. Quick scripts to scan log files, neat little programs to speed up boring tasks, etc. Of course, the introduction of things like PyGame have brought the language into a different area of programming that is mostly dominated by people who want to learn a language just to make a game. That's fine, but only to a certain extent.
My experience with Python was pretty traditional and didn't involve games, but I quickly learned about PyGame and went from there. I made all the usual games, like Snake, Pong, and a whole pile of different things, but time passed and I wanted something with more depth. About a year went by and I started creating my first roguelike.
Python can be fast, but it can also be very slow. Unfortunately, learning a language just to make small scripts and games doesn't exactly teach you to optimize much. I was learning at a very fast rate that I had picked up some terrible programming habits from those small scripts where speed didn't matter. Example: If you're crunching a 50-line file even the slowest code will get the job done. It's when that file is a thousand lines long that you notice how slow your code is.
Thanks to this, my first level generator took five seconds to finish. Take note that most generators take less than half a second to finish and crank out sprawling worlds/levels. Mine was making a dozen rooms spread about and struggled on high-end hardware. Scary, and very discouraging. It's a year later and my generator can make potentially hundreds of levels in the same amount of time the old generator took to make a single one. That's just one aspect of the game, though. We've yet to talk about A* or Dijkstra maps yet.
So what's the lesson in all of this? You're not going to make a roguelike in Python unless you're willing to learn how to optimize it. People learn Python because you can jump into it without much prior programming experience, then get confused when their simple Pong clone struggles to render any higher than 20 frames per second. It's a high-level language that needs a bit of taming before it will do what you want at the speed you want.
I'm not trying to discourage you. Your design seems great, but it's going to take quite a large sum of cash to get someone to do all that for you when you could do it yourself for free.
Back to my story: I've been working on a roguelike for quite a long time. It's been a rough experience, but overall a HUGE learning experience. There's been times where I've erased hundreds of lines at once because it was too slow or hard to read after spending a week away from it, and that's usually when I learn the most. I promise you'll do the same multiple times.
And for the past few hours, I've been trying to squeeze every bit of speed I can get out of my Dijkstra map function. Turns out you really, really notice a 0.1 second pause every frame. Yet, from what I've seen, games like Brogue can generate multiple Dijkstra maps each frame without any change in performance. That's not too surprising, considering C is one of the fastest languages out there.
I will link you to my code if you're up for seeing how a Python roguelike works. I will warn you that while the code is in a public repo, it's still very much "hackish" and has remnants of unused code in places, but I'm willing to clean it up if you'd like to take a look.
In summary: A roguelike in Python would be easy to get started, but would be hard to finish. Your mileage may vary.
9
Early Dev / Re: My Attempt at a 7DRL
« on: November 16, 2011, 08:49:49 PM »
Neat little game! Unless I'm missing something, there's no purpose to complicate things with an inventory, as you're probably running low on oil by the time you find one anyway. I also felt that oil ran dry a little too quickly. I'd prefer if it decreased every three or four ticks instead of two.
Not sure what you'd do with journals. Burning them for fuel is an interesting idea, but in that case they're just another source of light and don't really serve any other point. You might as well just get rid of them altogether if you can't think of another use for them. Maybe some kind of punishment for using them? Counting them as score seems rather pointless too, because there's really no incentive to score higher yet. Maybe have the player start each level with a complete map of the level, but they can choose to rip off portions of the map for more fuel. Just throwing out ideas.
I love the visual style, by the way. Feels very retro.
Also, one of my games started with me on top of a body of water, unable to move
Not sure what you'd do with journals. Burning them for fuel is an interesting idea, but in that case they're just another source of light and don't really serve any other point. You might as well just get rid of them altogether if you can't think of another use for them. Maybe some kind of punishment for using them? Counting them as score seems rather pointless too, because there's really no incentive to score higher yet. Maybe have the player start each level with a complete map of the level, but they can choose to rip off portions of the map for more fuel. Just throwing out ideas.
I love the visual style, by the way. Feels very retro.
Also, one of my games started with me on top of a body of water, unable to move
10
Other Announcements / Re: Must-play Roguelikes
« on: November 16, 2011, 08:32:09 PM »
Seconding IVAN. It is by-far one of the best roguelikes I've played. It seems so simple at first, but then your scroll of teleport rips in half, moving you across the map next to a hedgehog that just happened to step on a landmine, which destroys both your legs and sets your scroll of door creation on fire, successfully surrounding you with doors while you bleed out. Absolutely brutal, but so much fun.
11
Other Announcements / Re: Roguelike Radio podcast
« on: November 15, 2011, 02:17:30 PM »
Episode 11 was awesome. Very inspiring to hear success stories like that.
12
Programming / Re: Java roguelike libraries?
« on: November 14, 2011, 06:40:09 PM »
Check out Jade. Looks fairly simple to implement, but I have no experience with it.
Pages: [1]