New CyberPunk RogueLike

[Scautura]

I've been trying to make a roguelike (cyberpunk style) for a while (ooooh, what, 10 years plus?)

Now for the first time (second time really, but who's counting?), I've actually got some code down and a blog (pardon some of the babble, and "micro posts", but it actually gives me the motivation to continue!) at CyberRogue.

Ideas, suggestions, criticism all welcome - I haven't even got everything in mind down in a form that you can read yet, and quite often I write in what I call "brain-babble" - everything in mind gets written down in the form it was in my mind, at least, the first time I get to it, so it may not make sense. No code yet, but I'm slowly getting there.

Scautura
PS: Blame crashRun for actually giving me motivation to develop this!

[ywgdana]

PS: Blame crashRun for actually giving me motivation to develop this!

Yay   Happy to help!

Looking forward to seeing another approach to a cyberpunk setting.

[Scautura]

I hope you don't mind me waltzing through your code and learning Python on the fly?

Some of the things I find interesting is going through bits of yours after I've written (what I think is) something equivalent, and finding I've come at it from a different angle. Possibly because I don't know the language "from the inside" and I'm coming at it from a PHP type perspective?

Anyways, thank you for the inspiration (and I'm guessing you're not American from some of the spellings in the code!)

Scautura

[ywgdana]

I hope you don't mind me waltzing through your code and learning Python on the fly?

Oh absolutely -- part of the point of releasing stuff under GPL.  The source for crashRun runs the entire gamut of me just learning Python to more recent stuff where I think I know what I'm doing   So I hope it's obvious where I've done something dumb or klunky.

Anyways, thank you for the inspiration (and I'm guessing you're not American from some of the spellings in the code!)

I'm glad you're finding it useful.  Yeah, I'm Canadian so there'll be a mishmash of American and British spellings.

[Anvilfolk]

British! Honour! Colour!

[Scautura]

Valour! (Yep, I'm from "over here", but my other half is from "over there")

I'm probably going to end up with some stuff done backasswards because I'm stubborn and want to do it my way... I'll probably end up looking at it and going "I'm sure there's a better way to do this" and eventually it'll click.

Until then, backasswards it is.

Scautura

[Anvilfolk]

Actually, I've been told several times that the best way to do stuff is to just do it, and then optimize it later.

There's no point in continually trying to write the fastest code on the first time (especially on such "small" programs)... it's hard knowing exactly what part of the program is going to slow the execution down. You can figure that out later, and try to optimize only those parts that really need it. Besides, it get frustrating really fast, if you're always, always, always changing the code to get it to run faster, because you never actually get anything done.

Just keep going, see stuff moving! If it all starts becoming too slow... rewrite, but probably small sections only

Grey! Aluminium! Centre!

[ywgdana]

Actually, I've been told several times that the best way to do stuff is to just do it, and then optimize it later.

There's no point in continually trying to write the fastest code on the first time (especially on such "small" programs)... it's hard knowing exactly what part of the program is going to slow the execution down. You can figure that out later, and try to optimize only those parts that really need it. Besides, it get frustrating really fast, if you're always, always, always changing the code to get it to run faster, because you never actually get anything done.

Just keep going, see stuff moving! If it all starts becoming too slow... rewrite, but probably small sections only

Grey! Aluminium! Centre!

I tend to do it in pieces.  I'm not overly worried about performance, or at least I won't be until I get close to a 1.0 release.  But if you find obvious problems, there's nothing wrong with fixing it then and there.

When I wrote one of my map generators, it was kinda slow; like, 400 milliseconds and I worked on the speed while the code was still fresh in my mind.  And just before releasing 0.2.0, I found a couple of degenerate cases in my pathfinding implementation that would sometimes pause the game for a second or two.

But I think that you're correct and it's a mistake to try to get too worked up about performance.

For Scautura: Python comes with a simple profiler built right in.  It's easy to use and is a good help in identifying hotspots in your code.

[Scautura]

Right now my code is running "slow" - but it probably doesn't help that I'm running it off a memory stick (I'm trying to keep it with me at work so if I have an idea I can try it out), but not to the point of being an issue.
I don't see mapgen as a problem, as it's a once-per-level operation, a couple of seconds breather between levels is not the end of the world. Unless the next level is the end of the world...
I have written code in the past where I've re-invented the wheel because I didn't read the manual well enough - 20 lines to do something I could have done in one function call. Doh! I do occasionally go back over my code and think "can I do this better another way" but that's something I'm saving for later - except for those moments when a lightbulb comes on over my head and I rewrite something there and then.

I'm enjoying this immensely - and I've already got further than ever before!

Scautura

Redrum! Redrum! Oops...

[Gamer_2k4]

Right now my code is running "slow" - but it probably doesn't help that I'm running it off a memory stick

Hmm...my game isn't as fast as it could be, either (I run it off an external hard drive).  Is USB really slow enough to make a significant difference?

[Scautura]

Yes, actually, it does make a difference. 10x for my code (speaking very subjectively - I didn't time it, but it takes about 5 seconds to generate a level before displaying it on USB, and 0.5 on HD - approximate timing)

Dwarf Fortress actually doesn't like running off USB during generation, it seems to lock up (it's doing a lot of thinking) while creating a world.

Crawl is something like a 10x difference as well.

This is a rough estimate, but USB will not be able to match a HD for throughput - not yet, at least.

Scautura

[Anvilfolk]

That's pretty weird actually.

The computer should just load everything up into memory once, and not do any more disk accesses. That's the way it's supposed to work, but apparently USB must influence that. I run semi-modern games from an external USB 2.0 drive all the time, and they work. I highly doubt they're 10x slower too.

Straaaaaange.

[Scautura]

Remember that Python (CyberRogue, crashRun) is interpreted, not compiled, Crawl and Dwarf Fortress are only slow during the initial generation... Once loaded and working from memory they don't seem to be any slower (that I've noticed), and since they're in memory, that's exactly what you should be seeing (errr - in memory=no slowness, disk access=slowness).

The game I first noticed "slowness" on was OpenTTD - it autosaves every X months of game time. It would freeze for a few seconds when run off USB, whereas it wouldn't when run off HD. It's drive access that causes the issues.

Oooh, forgot to add... At work, where we have a lot of stuff that runs over a network as well, the networked installers take forever to run... But if you copy and paste the folder somewhere onto the local machine and run it from there, it takes less time overall than if you just run it from the server. Windows networking sucks (not that we have a choice - can't exactly teach students how to use UNIX machines and send them out into a world of Windows, can we?)

Scautura (FNARG!)

[Anvilfolk]

I can't say I know how the Python interpreter works, but I had an "Interpretation and Compilation of Programming Languages" class last semester, and if it's anything like what we did (and it's probably not), I still don't see the problem.

The interpreter would get loaded onto memory, then it would read and parse the files, and store them in an appropriate way internally, also in memory, and then run based on that internal in-memory representation. I find it hard to believe that there's constant disk accesses! Maybe every module / file gets re-loaded every time some function is called?

*likes this kind of stuff*

[Scautura]

I think it's more to do with the initial load, but being interpreted just means rather than a single file access (.exe) there are multiple (concurrent-ish?) loads to be done. Does it aggravate it? It seems to, to me. I'm probably grasping at straws a little, but I do notice a difference at certain specific points.

I don't know all the ins and outs, but it's definitely slower on startup and disk access for everything I've tried. Gameplay doesn't seem to have any difference that I've noticed, so I have to agree with you in principle.

I'll try profiling from HD and USB at some point, see what the difference is. I'm expecting to see a big (relatively speaking) difference in disk access sections, but minimal difference everywhere else.

I enjoy these sorts of discussions, makes me think. Kinda tough to get that at work (kinda sad when work is a school)