Ok, that’s what I wanted to know. So there will be two separate windows to display level above and below, next to main terrain window, like in DF?
The full time developer should work on the hard stuff that requires long blocks of time. This stuff is hard to do part time when you have a job and a life. You need to plow through this kind of thing and that requires a full time person. The easier stuff (and often more visible stuff since its new content) can be better handled by the part time guys.
I dont see how its possible to have full and perfect specs for something like this. I think the group of part time developers have proven they can produce.
It’s a possibility - at the very least it will have the DF fortress mode model of “you can get an idea of the stuff that’s below you but have to manually look up to see the stuff that’s above you”. After all, no one ever looks up. We’ve got the compass, which DF doesn’t have, to point out things of immediate interest, and we might end up expanding that instead of doing the two-screen system. So you’ll spot things that are moving that are potential threats out quite a distance thanks to the compass, but you’ll have to manually look around to see things on other levels.
Unlike DF, our terrain will remain predominantly flat, so there’s less immediate need to always see what’s above and below you immediately.
There’s also a chance we’ll end up implementing it slightly differently for the tile version, where layering and greying things out or something might be more effective.
I just had a thought for a fun game mechanic!
Custom world generation.
For example, when starting a new game world folder, it could throw you options for everything you want to include/exclude, basically giving us the ability to have our own variants similar to the classic zombies mode.
Don’t like mutant bees, but like laboratories? Turn off one but leave the other. Or maybe you like labs but you hate the scary Lovecraftian monsters, so you could just disable them so that when you explore a lab you don’t have to worry about becoming a carbon-based snack for an nth dimensional fungus from the Plains of Leng. Or maybe you want to go zed-less and remove all forms of zombies and replace them with cities overrun with triffids.
In a nutshell what I’m suggesting is a custom world generation system that works like a huge bank of toggle switches we can go through to get just exactly the sort of Cataclysm we want. I have no idea if this would be doable or not, I just thought it might be worth suggesting.
@Rivet: That’s just about how I imagined the World Factory to function, though specific implementation is up in the air until I finish Tile Support.
I’d be willing to discuss professional (paid) tileset work if you guys are interested. There’s already have alot of unreleased stuff for Fat Dog just sitting around waiting for tile support!
Congrats on hitting your kickstarter goal!
This is very true, there’s another issue though. I’m not complaining or anything, but just so you’re aware, you already have a full-time dev, I don’t track my time closely, but I put in roughly 40hrs a week on DDA nights and weekends, but about 90% of my time goes to review/merge/test of other people’s work, leaving me little to no time to work on large features.
The Z-level thing for example is deceptively simple, currently the game tracks a 131x131 square area roughly centered on the player. Inside this area we do line-of-sight, dynamic lighting, scent diffusion, field propogation (fire, smoke, etc), active item updates (draining flashlight batteries, burning fuses on dynamite), vehicle movement, monster/NPC AI and interactions. This is basically all of the game logic.
To make z-levels work the way we want, this dynamically-updated area has to be turned into a 131x131x21 area.
Step one is making the changes to expand the area, this is a TON of detail work, because pretty much all the code assumes that there is NO interaction between Z-levels.
That’s the easy part, at this point the game will run roughly 20 TIMES SLOWER*, then we need to do [MAGIC PROGRAMMING STUFF] to make it go fast again.
In parallel with [MAGIC PROGRAMMING STUFF], we have to figure out how to actually display and interact with a 3D environment in a roguelike, which is mostly unheard of, we’ll have to INVENT new ways of interfacing with the game in a way that doesn’t make the game as difficult to play as QWOP (or worse, DF*).
The features we want are fairly straightforward and well-understood (other than the UI part, the hard part there is precisely in planning it), but will take a huge amount of detail and optimization work to implement.
- 20 times slower is optomistic actually, because we have various algorithms we run that are barely sub-exponential, which means that increasing the number of tiles processed can increase the amount of work by a factor higher than one, e.g. it takes 520 line-drawing operatons to do LOS checking now (we draw a line to each tile on the border of the 121x121 square, so 120x4 lines(the corners are shared, so 120 instead of 121)), but in 3D, we have to draw a line to each square on each face of a 121x121x21 regular hexahedron, meaning… drumroll (121*121)2 + (11921)*4, or 39,278 lines 0_0 So with a naive approach, that operation will take 75 TIMES as long to execute, and is already highly optomised to make dynamic lighting work, a few months ago I added optimzations to it that made it do something like 10x faster, but that won’t be enough for 3D.
**I keed, I keed, I love DF, it’s great, but we have different priorities, so we can’t steal Toady’s UI, damnit.
So you don’t know what or how, you don’t seem optimistic anything is going to be made at all, and even if you do make “something” it will be terribly slow? Why didn’t you say that on the Kickstarter? How do you justify taking money and promising features for which you yourself have no hope could be properly made?
You misread my post, I was outlining what needs to be done, and the challenges that need to be overcome, but I’m confident we can do it, because we’re made of AWESOME.
You seem to have glossed over [MAGIC PROGRAMMING STUFF], that’s the important bit.
If you actually do get the 20-75 times slower game to run with interactive Z levels tell us. I think that the entire forum would be happy to fall off buildings, even if it does take 3 minutes to fall 10 ft.
Also we could have alpha bug testing.
The features we want are fairly straightforward and well-understood (other than the UI part, the hard part there is precisely in planning it), but will take a *huge* amount of detail and optimization work to implement.
I’d be more worried if the problems weren’t also well-understood. That’s good, because it just means effort needs applying to fix it, rather than running around trying to identify issues, which is a hell of a lot less fun than code-progress. X)
[quote=“Otaku, post:110, topic:1854”]If you actually do get the 20-75 times slower game to run with interactive Z levels tell us. I think that the entire forum would be happy to fall off buildings, even if it does take 3 minutes to fall 10 ft.
Also we could have alpha bug testing.[/quote]
Very much so. We mostly rely on the people who track experimental for feedback on new stuff, but we do need to post builds of really big features in progress for focused testing/feedback.
Hey, once again, congrats on the kickstarter!
I know you must be EXTREMELY BUSY with all of the programming you guys are doing with your new dev and everything, but I just wanted to ask what features that will come out first?
Please do not feel rushed; you guys have already done an amazing job updating and bringing new features to this game already. Besides, I’m already enjoying the game as it is.
Thanks
@SKiPPY: I am currently working on Tile Support, and making good progress on the framework. Currently getting a json format finalized so that you can easily add and remove tiles without it blowing up and needing a recompile after every new item addition. Right now it is taking in a png of some size, splitting it into tiles, and storing tile coordinates relative to an id number (0-the number of tiles in the atlas). Once all of the used IDs are loaded in it will then compress the atlas given into a smaller SDL_Surface that only contains the used tiles before unloading the original tile atlas from memory.
My order of work is probably going to come down to: Tiles > World Factory > Z-Levels > Starting Scenarios. In other wording: Shiny stuff > Not so shiny stuff > more shiny stuff > kinda shiny stuff 
Tiles aren’t going to become a requirement are they?
I love my roguelikes but I can’t stand tile-based ones. Maybe I’m weird, but I just prefer the ASCII characters.
@Rivet: No, tiles will not become a requirement. The option will just be made more readily available
That’s great to hear!
Tiles are unnecessary and don’t really add anything of real value to roguelikes. I’m always in favor of substance over style anyway.
You can have both.
If you need tiles, the game’s programmed poorly. Cata doesn’t need them IMO because the major dangers (critters) are clearly keyed under the compass display. Conversely, I usually can’t make much sense out of a Nethack ASCII map.
Basically, I’d regard tiles as an accessibility mod, not as something that ought to be pt in for the sake of being purty.
Why not add tiles and take away the code for ASCII. This will limit the size of the files (yay faster downloads).
But also make a jpg or png or insert_image_type_here filled with ASCII, like this this except without all the fancy arrows and wall thingies.
