Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Thief^]

I think 3D (in the level layout sense) should be dropped if you're not going to do 3D drawing. It's just damn confusing otherwise (sorry DF, but it is).

EDIT: This doesn't mean you can't have "floors", but it does mean you can't have "hills".

[Dariush]

Who removed a ton of my entries in the backlog? :-/

[Tuplis]

I sorted it by priority and added two of my own, can't see any removed tho.

What disappeared?

[Tuplis]

Released another version.

- Can now equip and unequip items (there's only one weapon right now, try it out!)
- Zombies will now shamble about when they have nothing better to do.
- New menu system

Known "issue":
- You can't backtrack in the inventory. I need to study the UI component some more.

[finka]

On pause keys I can use:  is there something you want to do, Tuplis, with the main-keyboard digit keys that merits keeping them distinct from the numpad keys?  You could do press 5 to wait a tick, doesn't matter which 5. 

Edit 3: Maybe we shouldn't allow zombies to break walls? Seems unrealistic to me.

Yeah, totally unrealistic.  Man, the last zombie I met couldn't claw his way out of a wet paper bag

Anyway, I suggested that as part of the barricading stream of ideas, the idea being that if the zombies want to get in at you somewhere, but you're on the other side of like a big thin wooden door or something, they could eventually break through it.  Perhaps "walls" was the wrong word; they probably can't get through most walls.  Feel free to edit the wording, or break it down into subtasks (environment material strength + damage?), or whatnot.  Or not, and vote it value 0. 

You can't write code in such a way that it won't need to at least be partially redone for the change to 3D,

Can't you, in principle?  As Tuplis has pointed out, you could go so far as to store cell coordinates as tuples of no fixed length (and cells in a hash table rather than a big fixed array, and so on), and switch to any number of dimensions just by changing a constant somewhere.

Toady's painstaking experience converting DF to 3d, with a massive technical debt, is of course etched deep in our collective memory round here.  But that's one data point.

How many roguelikes have implemented 3d seeing in the first place?

How many roguelikes use the third dimension as a dimension, and not just a level-progression mechanism which happens to be dressed up as "down", in the first place?  Going down then up again generating you a completely new dungeon level isn't really behaving like ... space.

[qwertyuiopas]

One thing that would be important, I think, would be a way of representing key features of what is above you, if it was 3D. Simply being able to tell where there is a roof directly overhead, or a hole that requires further inspection, without having to constantly enter look mode (or whatever), and check a level above.

It could be handled as simply an extra bit of shading that distinguishes whichever is less common/more interesting, without interfering much with the presentation of whatever is being drawn at that space.

Another consideration would be something like this:
(side view)

#_@_               __$#
#  #                z #


Where the @ is the player, the $ is some interesting item, and the z is an enemy which is rather important to know about.

This could be handled by showing interesting stuff that would be obscured by something drawn on the current level as a transparent image. Or perhaps DF-style switching between the current floor's object, and a symbol that represents "something visible above/below that is rather important", the way dwarves get an extra state that they flash to when hungry, thirsty, or tired.


Of course, all of this only matters in a fully 3D world.

[Tuplis]

Alrite, back with some news:

-Timer that allows for different speed has been released (and I fixed the invincibility bug that it caused in the version before). Currently the player has a speed of 100 and zombies are at 80.
-Implemented wearable items. It's a natural extension of the weapon equipping system and from now on, adding new item slots and new items is a quite mechanical process. Good times!


What kinds of equippable items would you like to see? Currently weapons only have the damage attribute which basically increases hit damage by 0-damage and the armors have armor attribute which reduce damage by armor amount.

[finka]

What kinds of equippable items would you like to see? Currently weapons only have the damage attribute which basically increases hit damage by 0-damage and the armors have armor attribute which reduce damage by armor amount.

Well, some sort of gun is a sine qua non of zombie stuff, isn't it? 
And once you get player vision in, light sources are another standard. 

[Tuplis]

Well, some sort of gun is a sine qua non of zombie stuff, isn't it? 
And once you get player vision in, light sources are another standard.

Right. Adding a ranged weapon at this point would basically mean having to implement line of sight also. We need to figure out which line of sight system to use, though.

edit: just released flocking. It looks kind of dumb atm. I wouldn't like to spend any more effort on it because it will be at least partially incompatible with hearing/smelling. On the other hand, we now have a general-purpose breadth-first(dijkstra) algorithm on our hands so that might prove useful later.

edit2: I'm currently facing a kind of dilemma. I feel as though we're at a point where the majority of the items in the backlog aren't really relevant at this level of development. Instead, I feel we should direct the scope of the game somewhat in an attempt to focus the development to a certain path. For example, if I were to add random map generation at this point, I'd need to decide the types of maps it would produce. That on the other hand will basically lock down the scope of the game: for example, I might make the generator generate cities, rural areas with trees and sparse housing or caves/dungeons a la nethack. Currently I don't feel like I possess the skills to make a generic enough random map generator that could switch between those categories with changes in parameter inputs only.
On the other hand, adding the item integrity system Dariush proposed would mean this would become more focused with equipment. And stuff like barricading and sleeping would mean the game is first and foremost about survival (kinda like Rogue Survivor) whereas it could be about something else.
So, what kind of a zombie apocalypse game are we making?

[Tuplis]

Alrite, uploaded another version that allows for different kinds of zombies. Actually it turned out very good in my opinion. The way it works is that there's an xml-file under resources/creaturetemplates and the creature attributes, including sign, color, sight and physical attributes can be edited by anyone. Or a totally new creature can be created by anyone from zip and pip. Later on when map generation is implemented, this mechanism will also enable anyone to add custom-made monsters to any map. The xml object builder I created is very generic and will later allow the xml file based mass-production of pretty much any object we might need (including random generated maps based on parameters given in an xml file). Awesomeness!

Also, since no one has answered anything, I will repost the question I asked in my last post:


I'm currently facing a kind of dilemma. I feel as though we're at a point where the majority of the items in the backlog aren't really relevant at this level of development. Instead, I feel we should direct the scope of the game somewhat in an attempt to focus the development to a certain path. For example, if I were to add random map generation at this point, I'd need to decide the types of maps it would produce. That on the other hand will basically lock down the scope of the game: for example, I might make the generator generate cities, rural areas with trees and sparse housing or caves/dungeons a la nethack. Currently I don't feel like I possess the skills to make a generic enough random map generator that could switch between those categories with changes in parameter inputs only.
On the other hand, adding the item integrity system Dariush proposed would mean this would become more focused with equipment. And stuff like barricading and sleeping would mean the game is first and foremost about survival (kinda like Rogue Survivor) whereas it could be about something else.
So, what kind of a zombie apocalypse game are we making?

[getter77]

Congrats on the swift progress.

As to the type, well, I would say there is already a good bit afoot that deals with the urban and suburban sprawl in terms of Zombie Apocalypse---so striking out to parts lesser trod seems like it might serve it well as part of the initial hook to distinguish in addition to this rather open development style.

I'd favor a Grindhouse style revenge motif(Awake in cabin, family just newly dead, player character utterly snaps and goes on frenzied bid unto destruction..or something), emphasizing far less on the mathematical details versus over the top exaggerated cause & effect in terms of physics so as to get nicely visceral and lethal on all ends.

[Dariush]

I feel as though we're at a point where the majority of the items in the backlog aren't really relevant at this level of development.

Goddammit. We've been over this already.

Currently I don't feel like I possess the skills to make a generic enough random map generator that could switch between those categories with changes in parameter inputs only.

Just make a single type for now and then elaborate when the time comes. Make two 'planes' - overworld and underworld (dungeons), with the former being more open-ended and the latter cavey-nethackey style and add transition between them such as through mines or sewers. Add both large cities and sparse villages in the same world. How are you planning to generate cities anyway?

On the other hand, adding the item integrity system Dariush proposed would mean this would become more focused with equipment. And stuff like barricading and sleeping would mean the game is first and foremost about survival (kinda like Rogue Survivor) whereas it could be about something else.

Both of those points are wrong. Making the game deeper and more complex doesn't make it more focused. If, for example, you prefer to be constantly on the run, you won't have to give a fuck about the possibility of building barricades. If you want to hole up in a safe basement and allow robots and converted zombies to defend you, you won't need to worry about item integrity, and so forth. So really, the best idea is simply to implement everything and allow player to choose what he wants to use.

[Dariush]

By the way, does the game actually allow for different creaturesm apart from the player and zombies? How did you implement the zombies? By adding an 'is_zombie' flag to a specific creature class? (are there actually classes in Java?..)

[Tuplis]

Just make a single type for now and then elaborate when the time comes. Make two 'planes' - overworld and underworld (dungeons), with the former being more open-ended and the latter cavey-nethackey style and add transition between them such as through mines or sewers. Add both large cities and sparse villages in the same world. How are you planning to generate cities anyway?
...
Both of those points are wrong. Making the game deeper and more complex doesn't make it more focused. If, for example, you prefer to be constantly on the run, you won't have to give a fuck about the possibility of building barricades. If you want to hole up in a safe basement and allow robots and converted zombies to defend you, you won't need to worry about item integrity, and so forth. So really, the best idea is simply to implement everything and allow player to choose what he wants to use.

Ok, it seems to me like you still don't understand the development paradigm.

Do you know the term 'feature creep'? Perhaps the most known example of a product that experienced feature creep is Duke Nukem Forever. What happened with that was that they had been developing for ages and the Big Boss kept seeing all these cool features the other games were getting and decided that they need to have it too, like for example cool snow effects. The boss decided they wanted awesome snow effects so now they had to develop a snow level. That's a prime example of design following implementation when it should be the other way around. Now, I'm not going to commit to building something big like a random map generator when there's at least a 50-50 chance that work is useless in the long run (or we have to commit to what I pulled out of my ass). And from that you can probably realize that your idea of "implementing everything" is not a good idea since I can't invest 8 hours every day on this project. Can't afford feature creep.

[Tuplis]

By the way, does the game actually allow for different creaturesm apart from the player and zombies? How did you implement the zombies? By adding an 'is_zombie' flag to a specific creature class? (are there actually classes in Java?..)

Yes, there are classes in java. Those are the things you create objects from.

There is a class called Zombie in the game. It is a subclass of NonPlayerCharacter which is a subclass of Creature (PlayerCharacter is another subclass of Creature). So far those are all the creature classes there are. You can differentiate a zombie from another creature by checking whether it originated from the Zombie class.