Messages

31

Programming / Re: Picking The Right Language/Game Engine For My Idea

« on: April 25, 2013, 06:08:10 PM »

I would love to attempt something along the lines of Dwarf Fortress(although that'll come much later on) so it's encouraging to hear that you're doing something similar with python. Have anything playable yet? As for sharing code, thanks a bunch but at this time it's probably way over my head. I'm still learning python and this thread was really just for long term planning. If I don't plan long term I'll end up dropping everything before I even get started.

No, nothing playable yet.  I'm still working on displaying the screen, moving the viewport, moving the "look" cursor.  I've finally got the interface working as I like it, but it's very slow to move the viewport or resize the screen, so I think I need to learn more about graphics.  I've been using a grid of "sprites" to simulate an ASCII grid, which seems to have a lot of computational overhead, and I think I may need to move to a simpler representation of the map.  That means learning about OpenGL and how the graphics really work under the hood.

32

Programming / Re: Picking The Right Language/Game Engine For My Idea

« on: April 24, 2013, 07:01:54 PM »

I, too, have been programming my roguelike in Python.  It's meant to be a real-time simulation (akin to Dwarf Fortress) rather than turn-based, so I will need to optimize for performance more than a typical roguelike.  My impression is that this is indeed possible.  My favorite commercial game, EVE-Online, is written in Stackless Python so I have to believe that it's possible to have a  high-performance Python game.  And I'm enjoying learning the language.

As for reference materials: I'm using Mark Lutz's "Learning Python".  He's pretty long-winded, could have covered the same material in half the number of pages, but otherwise I have no complaints about the book.  It taught me the language.

Most people using Python for games are using the Pygame library for input/output/graphics, if they aren't using a roguelike-specific library such as libtcod.  I'm using an alternative called pyglet, which seems a little more streamlined than pyglet and has fewer dependencies.  It wraps OpenGL so my code "simulates" an ASCII display rather than using a "real" curses-based terminal.  As far as I know, I'm the only person who has written roguelike code using the pyglet library.  Some of that code is up on github here, including my 7DRL (the "warp-core-breach" branch): https://github.com/joeclark77net/jc77rogue

I would share code from my more advanced project, but I'm not ready to open-source it yet...

33

Programming / Re: pedantic object oriented question

« on: April 11, 2013, 08:31:04 PM »

Pathetic n00bs, all! Real programmers write the 0s and 1s directly.

As always,
Minotauros

No, no, real programmers program with copper, silicon, and a soldering iron.

34

Programming / Re: pedantic object oriented question

« on: April 05, 2013, 10:35:32 PM »

I appreciate all the feedback, guys!
I think the take-away here is that programming a roguelike is different than normal programming if, like me, you're trying to learn something while you do it.  This game I'm writing in Python.  The next one I might try doing in Java.  And I might try using different libraries to do the same things.  I know that striving for "perfect" OOP shouldn't be an obstacle to a working game, but I'm glad to have had the chance to think about it with you all anyway.  (Now I can put that on my resume...)

35

Programming / Re: pedantic object oriented question

« on: March 30, 2013, 04:03:21 PM »

I guess I would just ask you this: do you know that iterating over a 1000 objects vs. 2 is a real efficiency gain?

Why not mock up a list of 1000 objects and a list of two and then time the iteration?

That said, I don't think many games would iterate over every map cell to deal with a thing. On the other hand, most games would not subdivide their things into many data structures either.

No, I don't know if it's a huge difference.  I'm only deducing it.  Hard to test, at this point, because my "things" don't really do anything yet.  But, if I'm going to have a huge map with thousands of things, where most are just sitting around but a few of them are performing actions, I don't want to try and iterate (30 times per second?) over the thousands of things and test each one's thing-type before running a function.

I *have* observed a similar finding in my code that draws the map to screen.  The initial screen-draw requires iterating over every tile and rendering it as a sprite.  Subsequent draws grab a list of "changed tile" indexes and re-render only those tiles (rather than iterating over every tile and re-rendering or checking whether it needs to be re-rendered).  This is fantastically faster.

36

Programming / Re: pedantic object oriented question

« on: March 30, 2013, 03:17:30 PM »

I'm using Python dictionaries (other languages call them "hashes") to locate things on my map.  There are three so far:

terrains = [an array containing a reference to one terraintype per map tile]
things = a dictionary, indexed by tile number, pointing to a list (stack) of items at that tile
critters = as 'things' but for critters

A dictionary is good for a "sparse array".  For example, if my map has 1000 tiles, the list of terrains will be 1000 items long.  But if there's only one "critter" (i.e the player) and he's at tile 345, the 'critters' dictionary will look like this:
{345:<Critter object>}
So you don't have to iterate over 1000 map cells to figure out what your critters are doing.


I'm also going to make use of "tags" for things, critters, etc.  So a torch or lantern might have the tag [illuminating].  There will also be a dictionary indexed by tag, each entry containing pointers to the objects with that tag.  So if I want to run a function on my light sources, I don't have to iterate between the thousands of inanimate objects in the game, just iterate through the [illuminating] set.

The trick is, if I get a pointer to a torch in this way, how do I then get its location (or its carrier's location) so I can implement its effect?  Iterating around all map cells and all critters would eliminate the efficiency gains.  Maybe my hacky way of having the objects point back to their containers is actually going to be the least problematic.

By the way, I'm trying to do a real-time simulation game (kinda like dwarf fortress but not) which is part of why I'm pushing for efficiency.

37

Programming / pedantic object oriented question

« on: March 30, 2013, 02:25:23 AM »

I'm trying to be a good object-oriented programmer, but I'm self taught and maybe some of you with more book-learnin' have a better grasp of the principles.  One thing that has me stumped is this question: is it OK, I mean according to good practice, to have an object contain a reference to the thing that holds it?  It seems like that would violate some key design principle, but I'm not sure how to do it better.

Here's the specific case:
I have a map object that keeps track of all the Critters (monsters/npcs) and Things (inanimate objects) by their locations.
Critter objects each have an inventory (a python list containing references to Thing objects they're carrying).

This is what I think I'm doing wrong:
Critter objects also have references back to the map that contains them (and to the location that is their index).
Each Thing object has a reference either to the map and location, or to the critter (if carried).

But sometimes you want to look at the map and see what is present in a given location; other times you want to start from the npc or object and find out where it is located.  What would be the proper object oriented way to do this?  I know that this is a pedantic and unnecessary question, but learning a thing or two about programming is indeed why I'm making a roguelike, so, I'm asking anyway!

 

38

Programming / Re: Bosses in a Low Health System

« on: March 29, 2013, 02:30:48 PM »

Maybe the challenge is getting close to the boss?  I'm thinking here of old arcade games (like 1943) where the boss would have lots of missile attacks and you spent most of your energy dodging his bullets, which were flying in all directions as he moved around.  You could only get a few shots of your own in between dodging.

So imagine your boss is a wizard firing lightningbolts and fireballs all over the map.  The trick is then to get close to him, whether by dodging, making a zig-zag approach, using obstacles, making chess-knight moves, etc.. Up close, you can land the killing blow.

39

Programming / info files

« on: March 27, 2013, 09:54:19 PM »

Do any of you have advice for using external info files to enable quick definition of monsters, items, etc?  (And also for users to set preferences and/or mod the game.)  Are there particular data formats that are easier to parse?  I figure XML is a bad idea because it's so hard to read, but, maybe JSON?  I'm using Python for what its worth.

40

Other Announcements / anybody remember Dungeon of Doom for mac?

« on: March 22, 2013, 09:16:44 PM »

I thought my first Roguelike was an Angband variant when I was in college (MacAngband) but I got to thinking about it and remembered a shareware game for the Mac called "Dungeon of Doom" (ca. 1987).  It was graphical but definitely a roguelike with all of the standard features: random dungeons, shuffled potion names + scroll names, need to identify bonuses or curses on weapons/armor, etc.

Well I finally got it up and running on an old mac emulator (an emulator of old macs, I mean) and played it again for the first time in... 25 years?

The graphics are lame, the dungeons are not very well-designed (basically wide, twisty hallways instead of rooms), and the feature set is limited.  Still, it's fun to revisit the memory.

Download it here: http://macintoshgarden.org/games/the-dungeon-revealed
Another fan site here: http://www.sidhia.com/shrine.html

41

Programming / Re: advASCIIdraw is out and about

« on: March 22, 2013, 02:47:30 PM »

Well, yes, or design splash screens.

42

Programming / Re: advASCIIdraw is out and about

« on: March 21, 2013, 02:11:18 PM »

This looks fantastic.  I don't know what I'd use it for, yet, but I'll try to think of something!

43

Traditional Roguelikes (Turn Based) / Re: Warp Core Breach (7DRL 2013)

« on: March 17, 2013, 07:11:59 PM »

Looks like no EXE is coming at this time.  It turns out py2exe doesn't support Python 3.x at this point, and I don't feel like converting my work to an older version of Python and pyglet.  So I doubt I'll be winning the competition but I'm calling it "done" and "successful" at this point even if nobody play tests it!  There's a screenshot on 7drl.org.

44

Traditional Roguelikes (Turn Based) / Warp Core Breach (7DRL 2013)

« on: March 16, 2013, 09:20:11 PM »

Announcing my entry for 7DRL 2013: Warp Core Breach

This is a little puzzle game written in Python with the pyglet library (no other dependencies).  Not very ambitious, but this is my first completed game since I was 10 years old and writing simple text adventures on the old Apple IIe.

The premise:  The warp core has been sabotaged and in a few seconds a stream of supercharged hyperquark particles are going to burst forth and annihilate anything they come into contact with.  Your only hope is to reconnect the hyperquark spigot to a negatively-charged antiplasma node (or whatever... it's the blue thing).  You do this by moving angled mirrors around to reflect the particle beam.  Press <TAB> to preview the course of the beam, and <R> to rotate the hyperquark spigot.  Try not to get vaporized.

I will try to figure out how to turn this into an EXE by the end of my 7 days, tomorrow, but for those who have Python and pyglet, here it is: https://github.com/joeclark77net/jc77rogue/tree/warp-core-breach

45

Programming / Re: Is this Rogue-like?

« on: March 13, 2013, 06:24:12 PM »

Boss hunting the player seems to be a solution that works.
So, you're going to use pixels rather than tiles?  I take it the Atari 2600 has big, clunky pixels: does it have 256x256 of them?

I just did a search and found that the screen res depended on the type of TV, but a typical value is 192 (vertical) x 160 (horizontal).  You might want to use that for your overworld map.  If you used 4x4 pixel tiles, you could have a little graphic detail and still squeeze 48x40 of them on screen, which oughta be enough.

Now you've really piqued my curiosity as to how you're going to really do this.  Do you have the capability of actually writing data to an atari game cartridge and playing it on the console?  Or is this all being done in an emulator?  What language(s) can you program in?  I'm very curious about the process and the constraints you'll be working with.