Print

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

[Tuplis]

I'll try and get it up once I get home.

edit: google doc is up. The link is the the op and everyone should have rights to modify it.

[Dariush]

...please, please, PLEASE get rid of the 'effort' and 'priority' columns. I can guarantee that nothing except tons of procrastination will come out of them.

[Tuplis]

...please, please, PLEASE get rid of the 'effort' and 'priority' columns. I can guarantee that nothing except tons of procrastination will come out of them.

That's half the reason for having them. If one thinks something is worth 10 points and another thinks it's worth 1, maybe it's worth discussing? Those numbers are there to make opinions more transparent and facilitate discussion. (this one was for the priority column)

The effort column is only useful for me, others are supposed to ignore it.

[finka]

You want new suggestions still here, or put directly into the spreadsheet?  Here're a few:
- Non-omniscient vision. 
- Sleeping.  That would gamewise seem to necessitate the ability to have a safehouse, so:
- Barricade creation.  Perhaps one of the kinds of crafting.  Reinforcing doors / windows to keep zombies out (would need windows / doors in the map), or perhaps (at suitable material cost) building a new barricade somewhere. 
- Then, conversely, ability of zombies to (incrementally) break down barricades.
- Some sort of swarming or flocking behaviour for zombies, as opposed to just having each one shamble around individually.  In one simulation I wrote this emerged fairly nicely by just having zombies not know the difference between humans and other zombies from a distance, and just shambling after whichever. 

[Tuplis]

You want new suggestions still here, or put directly into the spreadsheet?

You can put ideas in the spreadsheet. You can be quite liberal, though use some common sense. (eg. don't put stuff like magic spells there by yourself, we should discuss that kinda stuff first)

Try to break them down to the smallest possible increment that has end-user value. The list you posted is good but try keep it short.

- Some sort of swarming or flocking behaviour for zombies, as opposed to just having each one shamble around individually.  In one simulation I wrote this emerged fairly nicely by just having zombies not know the difference between humans and other zombies from a distance, and just shambling after whichever.

Yes, this is doable. There's actually a pretty good chapter on this topic in Algorithms and Networking for Computer Games by Jouni Smed and Harri Hakonen (2006). I can definitely recommend this book for anyone who'll be working on a game. I've read (and took an exam on) chapters 1-7.

[Tuplis]

Implemented seeing (range 3 on this build) and zombies will attack any non-zombie they see. The difficulty is quite tough but go to the next stage (f10) and it should be easier.

Try and see how much moving in the large map uses up your cpu. The current seeing mechanism might be quite heavy and could require rework.

Known bugs:
-Inventory won't work properly with multiple items. I forgot to fix it and just realized now
-The text will get messed up if two or more zombies are beating you at the same time.

[finka]

Try and see how much moving in the large map uses up your cpu. The current seeing mechanism might be quite heavy and could require rework.

If there is any lag from seeing it's not enough for me to notice it. 

I'm on a laptop with no numpad, so it'd be nice to have an alternate keybinding for pause I can use. 

Examining an inventory item maybe shouldn't use a whole turn's worth of time; in most roguelikes it's a free action, isn't it?  I guess that would be part of the "timer for actions with different speeds" task.

[Tuplis]

If there is any lag from seeing it's not enough for me to notice it. 

I'm on a laptop with no numpad, so it'd be nice to have an alternate keybinding for pause I can use. 

Examining an inventory item maybe shouldn't use a whole turn's worth of time; in most roguelikes it's a free action, isn't it?  I guess that would be part of the "timer for actions with different speeds" task.

I'll add the pause for another key later today.

I thought about the examine thing for a sec. Since I haven't implemented the "different actions take different amounts of time" feature, I just had to decide whether it takes a turn or not. Anyway, suppose you take an item from your backpack / pocket and thoroughly examine it, don't you think it would take at least as long as it takes to throw a punch / take a step or two?

On the other hand, changing it takes 5 seconds so maybe I'll just do it for the next one.

[Dariush]

You forgot to limit player's line of sight.

Edit: Bug #1:

Edit 2: Also, why did you add numpad movement if it's impossible to move diagonally (aka the whole purpose of the numpad movement)? o_0

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

[Tuplis]

You forgot to limit player's line of sight.
Edit: Bug #1:
Edit 2: Also, why did you add numpad movement if it's impossible to move diagonally (aka the whole purpose of the numpad movement)? o_0

I didn't forget to limit the player's line of sight. I implemented "seeing" basically like this: find the nearest non-zombie and move to attack. That has nothing to do with how the terminal component displays the stage. So it's basically just a breadth-first (dijkstra's algorithm).

The text bug I mentioned a few posts up. I'll write a console message component later when we deem it appropriate. Is this the bug I described?
I'll add diagonal movement too later. Finka has a laptop that can't support it so I'd have to either bind some non-numpad keys (which ones?) to do the same thing or implement mouse support (ain't happening, at least not yet)

btw, what's a popular keybind for a 'pause' other than numpad 5?

[Dariush]

btw, what's a popular keybind for a 'pause' other than numpad 5?

Numpad 5 has always been 'wait a tick'. Always. Everywhere.

[Thief^]

Keyboards have a key that's actually marked "Pause", you could use that!

[Tuplis]

Numpad 5 has always been 'wait a tick'. Always. Everywhere.

Obviously. But Finka and a lot of other laptop users do not have that key. And it could be that some laptops don't have the pause/break key either.



Also, go read the backlog items marked with ?, I posted some questions there you might want to think about.

[Thief^]

Oh to chime in on the earlier discussion: Agile has a concept called "technical debt". It means: "do something right the first time, don't waste time doing something in a way that will need to be re-written later". "Converting to 3D" after you write so much of the rest of the game would be incurring massive technical debt because you'd end up refactoring so much of the rest of the game, so it'd become something you'd do before other tasks. 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 (because you can't verify whether it works with 3D or not until after you've written the 3D code), so either do it now or drop 3D as a feature.

This is me speaking as a professional games programmer that's been using agile for years.

[Tuplis]

Oh to chime in on the earlier discussion: Agile has a concept called "technical debt". It means: "do something right the first time, don't waste time doing something in a way that will need to be re-written later". "Converting to 3D" after you write so much of the rest of the game would be incurring massive technical debt because you'd end up refactoring so much of the rest of the game, so it'd become something you'd do before other tasks. 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, so either do it now or drop 3D as a feature.

This is me speaking as a professional games programmer that's been using agile for years.

I am familiar with the concept and do agree with you in principle. However, I have taken this into account and currently have not made hard commitments coding wise to presentation in 2d. The functionality is in most part pretty generic so as to facilitate easy change of mind and where it's not, it's compact enough to easily be modified.

In my opinion the more important issue occurred after someone mentioned this whole 3d thing a while back and a huge shitstorm erupted over how it can/can't be this and that. How many roguelikes have implemented 3d seeing in the first place? And how many of those games are the first roguelike the developer wrote? Off the top of my head, I can't remember any roguelike outside of dwarf fortress where the enemy even followed much less spotted me when elevation was concerned. Beating that game would be quite a tall order.

I should probably blame myself for offering the community too much rope to hang me with.

What do you think, Thief^ ?