Lets Make! A 7DRL in space.

[nooblade]

7DRL stands for Seven Day RogueLike (http://roguebasin.roguelikedevelopment.org/index.php/7DRL).

Sometimes it's part of a challenge that takes place at a specific time of year and people play all the contestants and vote on which ones are the best. This one is merely for personal fun, because I have about that amount of time before school starts again and I want to do it sometime. I don't expect to have something that's very much fun at all, but maybe I'll have a frame turned out that I could fiddle with more later. Technically, I should post this at the "rec.games.roguelike.development" group, but I don't lurk there very often anymore.

I'm not sure what kind of advice I'll want to take. Or if anyone here could help if I get stuck. But I definitely want the theme of this game to be a Sci-Fi setting, where middle-early interplanetary travel gets interesting. The goal of this game from the player's side would be to explore derelict spacecraft (or maybe "space hulks"--where broken ship parts and asteroids collect together, but I dunno what I'd do with the asteroids) with some kind of alien creatures. I think the early and most basic scheme of "winning" would be to find an armory or magazine and set off a self-destruct thingie there.

I've been looking at realistic physics in space travel and combat websites recently, so I think it will be fun to try for that kind of sci-fi feel. See eg.: Atomic Rockets (on Engines) (http://www.projectrho.com/rocket/engines.php), Wikipedia on interplanetary travel (http://en.wikipedia.org/wiki/Interplanetary_spaceflight), Some blog on spaceships (http://denbeste.nu/cd_log_entries/2004/04/SpaceNavies2.shtml). I kinda agree with these sources of information, but it makes design of a universe kinda difficult.

I don't have a Linux box at the moment and I don't plan to do any networking stuff, so I'm satisfied with doing this project in Windows. I'll probably release the source code eventually anyway. I'll be using Code::Blocks with the mingw compiler that you can download without much setup. I was introduced to object oriented programming a while back, so C++ is likely. For the Roguelike (non-) graphics, I'll use PDCurses, the windows equivalent of NCurses, where the two libraries are pretty much similar. Curses is nifty because it lets me redraw portions of the screen, use color, and take keyboard input in ways that <iostream.h> or <stdio.h> won't. I forgot how to set all of this up, so I did that according to a nifty tutorial at Cymon's Games (http://cymonsgames.com/getting-started/). I will skip the parts on Allegro or SDL because I've used curses before and I think it will suit this project just fine.

I've fiddled around with a few things, but haven't actually started the game project yet. It's pretty easy to churn out a basic roguelike framework. See the roguelulz (http://www.kuro5hin.org/story/2007/11/29/5715/1869) example. I did something like this before remembering about "roguelulz" at all. Here's an example of moving around in a blank screen (http://img37.imageshack.us/img37/9370/79113209.png). I haven't used the increment and decrement operators in so long that I almost forgot about them, but those things are so, so nice compared to doing "x = x + 1;" all the time. But those examples aren't games yet; I'd have a full 7 days of work to make a game.

I think the most difficult parts of this task will be figuring out the generation of the actual spaceship and adding in the AI of any space creatures that might make it interesting. A combat engine and inventories are also not to be underestimated either. I can look up a couple of RogueBasin articles for things like Field of View to hopefully grab one of those implementations.


SO!!!

I can finally start, I think.

My first goal is to actually generate a somewhat random spaceship. I bet I could spend the whole 7 days on this and still be satisfied with my work...

Actually, I think I will ask for some input here and take the rest of the day off, maybe. It is "Let's Make!" after all. :smallbiggrin: But it is important to sit and think these things through sometimes. Maybe. From the total novice perspective anyway.

Because of this quirky setting, the usual standards for random generation of an environment won't apply. If it were a fantasy DnD-like setting, you might generate the dungeon by having some things mine out rooms in solid rock, or you'll separate a square into a bunch of rectangles that would be the "rooms". I could do something like that with a ship, start out with some kind of cylinder and then split that up into rooms, which I could later designate as an "engine room" or a "bridge" or "bunks" and of course the important "magazine" to blow up for a win. And then I might have an "escape pod" or a hatch for you to jump out of before the ship actually explodes. Kinda like how some game will ask you to get the Amulet of Yendor and bring it back.

I would like it better if I could start with empty space and then add the rooms onto a frame starting with the engine. I would have to keep the engine at one extremity so we can be sure that working mass doesn't hit some other part of your ship, the engine would work good as a framework to build the rest of the ship. But further than that and we have to get into theoretical space combat and ship design.

HOW DOES SPACEFIGHTING WORK?!? I might be able to use some input here, but I dunno, the articles above make it sound like sci-fi does combat in space wrong like 99% of the time (unless you're in a freaky setting like "there's intergalactic travel but no computers"--freaking Frank Herbert and his spice melange). For our application, this will be important in determining how much of the ship is going to be a flying fuel tank, and what parts can blow up, and how many people you could expect to put on a ship of X size. It doesn't have to be perfect, these are ships that busted for one reason or another after all and some variety would be nice, but getting it right would be great. If I tried to make a ship that used missiles, then I'd guess it would need less radiators to deal with heat. Right?

There's also the threat of cheap "mines" and floating debris, those could hurt if the relative velocities of the small things compared to a ship are high... I think that all ships would have some kind of weapon-like system able to deal with junk like that unless we never go faster than a space shuttle.

Another thing. The ships are going to be broken somehow... I could have random room damage present after the previously working ship is generated. I could even fit in asteroid-attachments here.

Oh, also, let me take a second to shut down something:


It is a truth universally acknowledged that any thread that begins by pointing out why stealth in space is impossible will rapidly turn into a thread focusing on schemes whereby stealth in space might be achieved.

There should almost certainly not be stealth spaceships. I think ships will have a rather simple and effective suit of heat sensors. Visual detection of spaceships would be useless. Another pet peeve of mine is the smaller "fighter" ships that get deployed by "carrier" ships. I'm sure a missile would serve much better than some fighter, and you probably won't want to drag people along to pilot the missiles even if you have no value for human life.

I don't want to make giant ships that would take up more than a 80 by 24 ASCII symbol area, and maybe leave some room for player interface too, but yeah, one floor of a ship should all fit on that kind of screen I guess. I guess I could use "resize_term(nlines, ncols)" to make it something else, though. Some people are saying that spheres are going to be the best, but I think for the purposes of the game that the cylinders will fit on a screen better. But a sphere might be pretty fun, too. Spherical ships would make for an interesting interface where everything is off to a side of the screen, cylindrical ships would put interface at the bottom. Or maybe we could do both.

I think I will stick with cylindrical just because Curses doesn't give me a square font. I would need SDL to make a really square font. Circular things where the y direction of a letter is bigger never look circular anyway, the aesthetics are displeasing. But if spheres are a big thing then I might want to go back and do an SDL font drawing kind of thing like what Dwarf Fortress uses, I guess. It's going to be more work than the 7 day goal though.


I'm getting a bit hungry. I think I will hope to have a working, tweak-able system for generating cylindrical ships with some rooms by the time I go to bed. Maybe. Maybe this entire project in 7 days is just CRAZY!

[Inyssius Tor]

Best of luck! I was going to try for a sci-fi 7DRL with emphasis on intelligently-designed space vessels (and what happens to them when you screw with individual bits of those vessels) myself during some academic break a year or so back. Of course, Life Happened and I never got to do it, but I'll be watching with interest to see how your shot pans out. :smallsmile:

I think you might want to consider including some environments that are more citylike, more "grounded", or both; space stations, moonbases, habitats built onto or into or near asteroids, generational colony ships, that sort of thing. Such spaces can often allow for more variety in terms of layout, in terms of current state, and in terms of manner of demise. Plus, they're easier to find!

[factotum]

I'm a bit unclear on how this is supposed to work. Are you controlling a spaceship, or wandering around inside one? First half suggested the former, but then you started talking about rooms and cylindrical versus spherical ones!

[nooblade]

Nah, it's about exploring the ship, but the way I presume ship fighting would work influences the way that I generate random ships.

I'm getting the weirdest bug right now just making a big square in the 80x25 window. But some debugging shows that the program terminates only when displaying it. I might not even get the boring square. :smalleek:

Edit:

Got it! (http://img807.imageshack.us/img807/8316/82832936.png)

Err. I guess. I can fix the new problem, though. It turns out that it wasn't at all related to the display code, which you can see, but actually the room-creating code did something quirky. And still does. But at least it doesn't terminate.

The colons in space don't look very attractive, though. I guess I could use some kind of ASCII art or randomly generated space background for the parts that aren't the ship, eventually. For now the characters make sense.

Now I will make rooms! And probably sort them by colors.

Edit2:

Engines are red, reaction mass tanks in purple. (http://img200.imageshack.us/img200/9163/71660903.png) Those can be put on either the left or the right of the screen, and they come in two sizes. Oh, and the white room is just leftover from the first testing of my room drawing code.

I guess that took a while to do. I thought that figuring out how to place them and then giving the rooms color wouldn't be much work; I guess it's always easier to think about it rather than doing it.

I was thinking about making a special ASCII graphic for the engine, but it's not worth much to me right now. I don't think it would be a room that the player goes in though; I bet that engines would have to be worked on from outside.

Having more thought on the design of these ships:

The fuel-to-mass ratio will need to be high based on the psuedo-tech I'm using, so I think I could actually give them only a single displayed floor and say that the rest is a giant fuel tank. That would let me get away with making a smaller room for fuel, and say it's an interface and pumping room. And I could see how it might be nice to have modular tanks since pumping fuel for long amounts of time would be dull. Although it would be more "fun" to have a real fuel tank on the level that you could puncture or possibly blow up. Maybe isolating that tank has its own rewards. But fuel pumps and long fuel lines wouldn't do any good on spaceships according to those design principles.

I'm starting to get bored with dungeon generation, ideas aren't coming to me for this topic, so I'll probably want to just make it usable and then work on other stuff sooner. Are people going to actually go into the, err, fuel pumping room? Or maybe it will have fuel lines that are highly explosive. Yeah, I think having a fuel pumping room that connects to external fuel tanks would be a good idea for me. It can be a smaller room than the engine now, too.

Another option would be to make the "engine room" much bigger, and have it span across 3 or so floors, next to a giant, multi-floor fuel tank or two or three. Another good idea would be to separate "fuel" (think gasoline) from an oxidizer (the thing that allows other things to burn (or rust, or whatever), or to burn faster; think hydrogen and oxygen mixed in the same tube from chemistry, it nearly explodes) That way I could scale up most things, compared to the example here. Larger rooms are interesting for combat, too.

Okay, I'll do that. Time to figure out multiple floors and maybe stairs, then.

Edit3:

Where did the last 3 hours go? I guess I was doing this thing. (http://img820.imageshack.us/img820/1673/90525537.png) That doesn't look like a 3 hour improvement at all. I might spend another day on this and still not have something that looks very nice. I think I will finish with the multiple level spaceship mentioned previously.

But the shape of engines and tanks is pleasing to me so far. I think I should also have a corridor running on the side of a tank, a little more exposed, and maybe only one engine access corridor per ship. Having more floors gives me enough space to do something fun with the outside of the craft too, like add radiators.


More ideas: The main question here is, how much would spaceships fear boarding enemies? With very fast ships, I'm guessing not very much at all, so there likely won't be many defensible-type positions. IMHO.

I will probably soon upgrade to a 3 dimensional array for the extra floors to be added. Stairs up and down can go in some special cubbies that might fit almost anywhere.

The "X's" that you see indicate possible connectivity spots for square spaces, that may come in handy later. There will need to be more connections between engines and fuel tanks that the player won't really walk through but might be able to see. Or maybe engines are big enough that they are a possible point of entry into spacecraft.

It will be helpful to have the generator store information on rooms in general, in another array. Like the number of exits any of the rooms have, to make sure that all rooms are connected. I could put the connectible spaces in a room there instead of making an extra tile type.

I could save information on fuel tanks that are displayed like this to give them the same shape if they supposedly extend through multiple z-levels.

I will need to keep track of exactly what is in a fuel tank, too. They might be empty, or full of flammables, or oxidizer, or atomic fuel.

For the passageways: I'm guessing that in a spaceship, there will usually be one long access corridor that branches off into several rooms. That could simplify the rest of this process greatly, but then you have a huge, long corridor. That might be boring for battles unless something breaks across it. At least I could say that the engine access is a shoot-off from somewhere, or maybe just add some periodic doors.


Slow and steady finishes eventually.

Edit4: Progress. Not much. (http://img11.imageshack.us/img11/5741/41299027.png)

See how little it has changed? (http://img706.imageshack.us/img706/5851/57767475.png)

I figured out some more things about connectivity using some functions I wrote. They're getting a little on the bloated side, but I think the corridor function is good even if the room function is quirky. I like the "O" doors--they look like hatches. I'm not sure what to make them look like when the open, though, maybe "C", "G", "@", or "&". I dunno.

I kinda want to change the wall icon, too. "#" is boring, "X" doesn't look good either.

I think I will just keep track of space instead of keeping track of rooms, and use one corridor per deck to connect to all rooms. OR I could say that the "decks" are just surfaces around a cylinder, connected at the edges, with some kind of artificial gravity due to rotation at the center... But I dunno. I like the first idea better.

I think I will be in pretty good shape if I'm done with shipstuff tomorrow.

So far, I'm surprised at how quickly this can get messy, and at how much you need to plan ahead to do a more serious dungeon-thing generation. I have much more respect now for games with nice dungeons like Unangband (roguelike I think I knew before, and scoped to get generation inspiration). I'm betting that forethought in generation won't matter much for this case as long as I'm careful with assigning values to the squares, although it will still be good to keep track of the functions of various rooms and their extents (with a struct) for when I need to put items in them or let the player win or escape.

Looking to the future, there is still lots of fun to come with movement, AI, combat, items, and whatever else. I might do leveling like a typical RPG. If we go that far.

It's not very late at the moment, but I don't feel urgency about staying up yet. I think I will hear ticking noises as I sleep tonight though. 7.5 hours on the job.

Yay for sleeping more than working! :smallredface:

[factotum]

The colons in space don't look very attractive, though. I guess I could use some kind of ASCII art or randomly generated space background for the parts that aren't the ship, eventually.

Just place, say, 50 random full stops in "space"...it'll look better and shouldn't take too much effort!

[nooblade]

Well, 20 or so hours gone, 148ish remain.

Here's another shot of basically what I have. (http://img824.imageshack.us/img824/8799/32341166.png)

This looks a lot similar, but I spent a couple hours on adding 3D and cleaning up a few functions in generation. The engine and tanks take up space between floors, the other rooms would only stay on their floor, I figure. Notice the commented out spaces? Well, I made this confusing and it's taking long, so I will adopt a particular arrangement of the various tanks until further notice. There's a corridor connecting the engines to the rest of the ship on the 2nd z level.

The lesson here is that random generation requires thinking. I jumped in too quick and edited a bunch of functions many times because I didn't know what they were supposed to be doing yet.

Oh, and I still didn't leave much space for an interface. Eh, I'll change the window depending on what's needed, 80x25 is kinda small anyway.

That gives me another good idea. Instead of saving data for rooms in each tile, I should have those tiles point to data in an array of rooms, where the data can be found almost as quickly, which I'll use in generation anyway. Less redundant for all the tile storage, although the tile datas can still keep track of important things like explosion damage (if I get that far).

From here, I figure I can fit in less than 30 other rooms? They will be much smaller than the tanks, and stacked one on another.

Actually, I think I will just do away with the long corridor. If space is really at a premium, then the rooms should be connected more directly. That makes it more interesting to explore, too. The only problem there is that some rooms will take up only half the ship space, but that's fine I think. Makes two optional room paths. I dunno if I can handle nonrectangular rooms, though.

Edit1: Well that looks funky. (http://img97.imageshack.us/img97/8862/17053346.png)

Hum... It would look better if I made a random hull and then divided it into rooms randomly (that would make non rectangle rooms easier too, I bet, and then rooms with area requirements like cargo would be neat, too), but doing those things would take more work.

But in retrospect, drawing the hull first with some semi random symmetry (move along some distance, make the hull extend or retract, repeat for entire length) would've been best. The floors could easily be symmetrical. I could then do rooms by volumes (and use the overall volume of the ship to estimate mass, and then estimate the volume requirement of fuel tanks). Doing it the other way first might end up costing me like 24 hours. :smallmad:

Okay, I'll try that.

Edit2:

Idea!

I'll just use something like this. (http://img835.imageshack.us/img835/4551/94765017.png) It has nice hull symmetry. Then give it a chance to divide the room from there for each floor, so that the decks aren't symmetrical. It's a nifty spot to check for volume too. For example, if a room is generated as big enough, then I might make it for cargo. The only downside is that I still have rectangular rooms. Eh, no big deal.

Very egalitarian. Sounds good so far.

Edit3:

Not much changed. (http://img200.imageshack.us/img200/1565/87774072.png) I think I was cleaning up stuff? Maybe. Walls don't belong to rooms... I think I spent most of this time just playing with my own code. YAWN. That and lunch.

It's a little weird to think of where to put doors and where to split apart rooms. I guess I could just call the function that makes rooms again. For the doors, I have to be sure that the other room connects and that it isn't next to a wall if that room had been divided. I might actually put doors in first and then divide rooms, and make sure not to divide next to a door. That way, almost every room needs a door on either side. If the ship is facing left, then each room needs always a door on the left wall, I knew I had to keep track of orientation.

Edit4:

Okay, so I cheated. (http://img691.imageshack.us/img691/6312/49832862.png) With the doors anyway. There are plenty of cases where the doors could be one tile further out in a Y direction, but it's difficult to check the height of the rooms and add in logic for both sides having 5 shared walls. Much less work required here, and it's hardly noticeable. This way, you don't even have to look at the other room.

What IS noticeable is that this only works on Z = 3... What went wrong there? I thought I define z in the room struct in the function that makes rooms.

Edit5:

BUH! I see it now. I made 3 rooms in a row without incrementing the room counter.

Not bad. (http://img17.imageshack.us/img17/3517/28992298.png)

I notice here that I can improve this by adding an extra available space on the middle level. A little bit of extra randomness there will be fun.

I think I'll connect the whole ship with some stairs and then start playing with movement. Can do room division later.

Edit6:

I have ships! (http://img836.imageshack.us/img836/6131/71926154.png) I have random ships. (http://img856.imageshack.us/img856/1613/93748553.png) Stairs are the "X"'s in these pictures, and they change into ">" or "<" on Z 1 and 2. There are stairs in engine rooms, too.

27 hours though, and a bare minimum of generation is done. The mass ratios are off, too, unless I want to assume major breakthroughs in maybe nuclear fuel or something? But from the standpoint of figuring out the game, most of the stuff on the screen at any time isn't from an area that you can play around with much. Well, eh, I'll just move on for now.

Movement! Time to have a guy move around through here. I didn't make an entry airlock, could do that really quick. Maybe make a starting menu, maybe do that last.

At the moment, I run through the for loop that checks all the rooms several times to find which one has the lowest volume to use as the "HUB" which contains up/down ladders or stairs or whatever. But I will eventually want to use one of the divided rooms that can possibly have less volume. Ditto for the Airlock, although that room only needs to be on one of the floors.

These rooms could be so small though (hub requires only 1 tile, technically, but airlock could use more space) that I might pick a room that could almost always go smaller and shave a little off it.

Edit7:

Bug number I-lost-count. (http://img26.imageshack.us/img26/3346/41435900.png) Map is not redrawn after player movement. Durr. I make roguelike? A lolcat could've avoided that!

I should put movement on a solid function too, one that I can use to move things other than the player.

Edit8:

Glorious. (http://img94.imageshack.us/img94/659/64211810.png)

The player can move through some nifty functions. Once other things are made, those things can move through the same functions. When I get around to turn-based stuff where some things can move faster than others, movement will have an energy cost using that function, extra nifty.

I also spent a bit of time with the functions that draw tiles. And I like the vertical doors. If there are any horizontal doors, I think I will give them the appropriate door tile.

Also, welcome to 587 lines of code. That's not exactly a sign of progress or skill, plenty of people could do more, more quickly, with less, but it's a fun number that will increase.

Edit9:

Almost forgot. (http://img12.imageshack.us/img12/9707/67450136.png)

Obviously, you need to be on stairs to go upstairs.

Edit10:

I'm thinking about items right now. I think I might use a subwindow from Curses to fill the inventory task, if I can also save the stdscr... But I haven't done this before.

Lookie. (http://img695.imageshack.us/img695/227/62515884.png)

Hmm. I had thought that making the subwindow would clear the area behind it. I guess I have to overwrite it and redraw the window anyway. Drat. The box looked nice, but it doesn't do anything for me. Actually, using it might be a liability since I can't get mvwprintw to work properly. :smallsigh:

I will just use redraw stdscr whenever someone goes into an inventory I guess. That puts a damper on items.


I am losing focus just a little bit. I don't want to mess with rooms much more until I figure out what to put in them (items, interaction). I guess with movement basically started, I could try my fingers at some monsters and basic AI.

Edit11:

So, I quit for a while and also tried to fix the thing with more random doors for a while. Doors aren't getting fixed. (http://img36.imageshack.us/img36/6012/59353709.png) They're failing quite badly. (http://img191.imageshack.us/img191/7144/90173819.png) I can tell by the little blue colors (stupid debugging on my part) that something's wrong with the way I'm storing data. Yeah, the blue dots in the same column should only be one blue dot. Maybe an index is wrong in one of my for loops? I dunno. I'm almost, but not quite, ready to give up on it again.

Edit12:

More funky debugging has more to reveal. (http://img20.imageshack.us/img20/3394/41520777.png) The green squares represent the values from normal access, the blue squares are gained by indirectly going through the index stored in a room tile. So, since the blue tiles are always wrong, I can tell that there's something wrong with the way I get data about rooms from the tiles in those rooms.

Now what to do about that? Fix it, or gut it?

They line up so nicely in the columns that I think something's right. The columns represent indicies so there wouldn't be two of each in the middle if I were doing it completely wrong, I think. But the data calls look so similar.

Another test: line up only the indicies, put blue below green, and it confirms my suspicions. "len = rooms[adj].y1;" and "h = rooms[e].y1;" are different even when adj and e are the same. How odd.

I'm hoping that solving this problem will be essential to something fun down the road, otherwise it's too much work.

Edit13:

Look at the bugs more clearly. (http://img6.imageshack.us/img6/7456/42281605.png)

With this one, you can really see that the values in green are always accurate. Notice the triangle pattern? That's due to the symmetry of the cylinder; the rooms on z = 2 have one extra line of tiles on each side. I guess it isn't technically correct to say that they're the same statements because "e" is part of a for loop and "adj" is determined by looking it up through data stored in a 3D matrix.

But using "adj" is hardly ever correct. Once, I spotted one error that was in favor of the "blue" side, but I figure it was because the "adj" value dipped below the correct green value for that case.

Really interesting. Except that I hate it because it isn't working and I can't fix it. The index is right there in the tiles I'm looking at, but I can't use it in the array.

I wonder if pointers would help. Pointers are like magic, right?

Edit14:

Fixed that problem. (http://img11.imageshack.us/img11/863/49346041.png) How? I still don't know why you can't do the thing where you access a room by index from some other array from a for loop in another room. I hope I don't run into that in a situation like when a player walks into a room. But this whole thing with a bug helped me realize I was doing it wrong. With one extra variable in a previous part of the generation function, due to the symmetry I was using, I could save the previous value for y length and put it into the right array directly.

Adding code that saves the position of a door to the room that it's not created in is more ugly, though. I think that, instead of checking a variable when partitioning rooms, I'll check the tiles for walls.

If there's a door, then there's a door! Wow.

You can see how ugly some of the previous generation codes are from that screen. :smallyuk: But they work, I'll run out of time if I mess with them more.

I still want to move on to other stuff (spending three days on generation would be awful!), but it is kinda going well now.

Edit15:

Started on room splitting. (http://img814.imageshack.us/img814/5516/73670556.png)

There are some obvious problems. A room with no floor space is not a room. There are no horizontal doors, in some case cutting off passage. It can be split across an area with a door. Plus, I haven't actually defined the newly split-off room as separate from the main room yet. And there's still the part where the rooms are allocated before we're done with those things (and eventually maybe items will go in rooms). This shot doesn't show it, but cargo rooms are already in because of the requirements for larger sized rooms there.

I might do some more work before bedtime but it's more likely that I'll just randomly generate a bunch of ships and look at them because they're so pretty.

Edit15:

Yeah, I've done so much stuff for rooms that I might as well finish them. Then I could pick up the project later and have interesting rooms, which is better than a finished 7DRL with nothing interesting IMHO.

Here's an interesting bug. (http://img822.imageshack.us/img822/7641/44561775.png) The cargo room shouldn't be capable of being split at all. And it isn't split properly.

But I've been having data problems lately. Sometimes you'll pass something through the rooms array, like the z level that a room is on, and it won't come out properly. I bet this particular bug won't show up again if I pass z through function parameters, but that's tedious and it doesn't solve the problem with data.

I dunno why exactly it's acting like this.

I never really learned how to use malloc and free, I hope it's not related to that.

Edit16:

Huh, that didn't fix it, it happened again. Same kind of set up, too, a room on another floor with the same dimensions as the division in the cargo room.

OOOOooooooh, of course. I made a new room without setting it's value for z. So obvious now.

Edit17:

I spent an hour wondering why some walls are generated green, figuring that something was wrong with the extents of the rooms I was making. Turns out that the walls were green because I didn't specify a color for them. The code I have for splitting apart rooms allow the newly created room to possibly be split again, so the green showing "new room" got washed onto the wall without effecting the door. That was silly.

But it looks nice. (http://img692.imageshack.us/img692/912/72097315.png) I like how you have to wind around a bit to get somewhere most of the time.

Now I think I will redo the hub and airlock room ideas. They can still be the two smallest rooms, of course, but we'll have to loop through all the rooms AGAIN after they're divided to find the lowest volumes.

Also, sometimes the split-off rooms are big enough to have a small chance to be made cargo rooms. I guess that's fine?

Edit18:

ROOMS! (http://img844.imageshack.us/img844/6487/43271006.png)

Needed more rooms. Now there should be lots of rooms. Plus the airlock has a separate room, not necessarily on the middle deck anymore. Only downside is that the hub (with stairs/ladder) is still the largest of the originally generated rooms, which can still be pretty big, but that's okay because it saves me the trouble of trying to line up rooms up and down.

There's one bug where the entry hatch is generated in the middle of space. I might not bother fixing it, it's a biggie.

Edit19:

More on rooms. (http://img194.imageshack.us/img194/2613/60840926.png)

I haven't seen the spaced entry hatch in a long time, so I'll assume it's fixed. Maybe. I tried setting one of the giant fuel tanks as the initial room in the loop that checks for tiny rooms, because I was thinking that the initial room is compared in size, but not set up for the actual hatch. I'm hoping that the spaced entry hatch is just that initial room problem. I hope that's enough "fix".

But these rooms are now sorted into types instead of giving detail on construction. The blue rooms are "combat" rooms, which contain junk like weapons, ammo, probably a manual self-destruct switch, that kind of thing. There would have to be variety among that type of room. And the green rooms are related to biology, they would be medical stations, life support, or hydroponic farms I guess. Or just food storage or bunks, yeah. And we've seen cargo rooms already.

What's space cargo supposed to be like? I wouldn't put something like textiles in a spaceship...

After generating the map, I will fill it up with some enemies based out of these rooms. Bio and combat rooms can spawn different kinds. If I go further with this, then it would really depend on the subtype of the room. I'll add the mission-ending self-destruct button to one of the combat rooms, too. I should probably try to make it not on the same level as the hatch, but then we have the "what if the hatch is right next to the stairs" thing. I might not get that far.

Edit20:

The ship is inhabited. (http://img153.imageshack.us/img153/748/41019834.png) Nothing exciting yet, just testing out functions that make guys. Oh. I changed the player character just for fun, I think I'll put it back now.

I should probably have made a function by now that gives the center of an area or a random point in that area... Yeah, that let's me get rid of the "temp" variable and makes it easier to read.

Edit21:

Finally time to move away from rooms.

FOV is tough. (http://img191.imageshack.us/img191/730/42102651.png) Well, it is just some algorithm that I copy+pasted from roguebasin, I didn't try really making it work yet. Already there are problems with seeing through walls. Walk into a wall -> disappear (a problem with my movement function most likely).

If there are fun points to give up at, this is one of them.

Edit22:

It's hot. Ugh.

I will quit working on it (for now) and stay cool. FOV is a neat puzzle though, I will have to read up on it and figure out a nice way to do it sometime.

So much for the "7DRL". I didn't think I'd get a solid game out of it in such a short time anyway, I don't feel bad about quitting here (or changing work schedule to intermittent at this point).

I want to spend time looking at other people's blog posted 7DRLs sometime.