Print

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

[Dariush]

The question is, can the proposed model of sitting around a fire achieve that goal? What do you think?

Of course it can. This way, the community of hardcore gamers will internally discuss every idea and the best way to implement it instead of simply dumping a huge backlog of potentially contradicting ideas on you through which you'll have to sift manually.

Then I figure how much effort it takes to add either. Guns would take 2 hours (priority = 9/2=4,5), sounds 1 hours (priority=6). So I decide to implement the sounds first, then weapons. In an ideal case, the backlog is so long that some of the features will be postponed until quite far, maybe 30+ days into the future.

IMHO, this isn't going to work. For example, adding a completely new system for, let's say, implants must have far higher priority that adding a new weapon, if only because of the sheer amount of stuff you'll have to redo to implement the new system if we determine it viable. However, if you use the 'priority/time' system, you'll implement all the minor (0,5 hours) stuff immediatly and postpone the important but huge (10+ hours) stuff unto oblivion.

[Tuplis]

To be honest, you do appear to be nitpicking right now. Specifically, the 'value' system seems just arbitrary and pointless. It should be obvious that, for instance, adding a completely new system for, let's say, implants must have far higher priority that adding a new weapon, if only because of the sheer amount of stuff you'll have to redo to implement the new system if we determine it viable. Any arbitrary measures will just confuse things.

And this is where you are wrong. This is a central concept within agile development, and the software industry is currently experiencing a paradigm shift towards the very idea of measuring value vs effort of every single requirement the customer throws. That is because requirements for any vision of a software product are constantly shifting and the most important thing is to concentrate on short-term, not long term customer value. It's about managing risks and as we all know, "You Can't Manage What You Don't Measure"

[Dariush]

Actually, I realized I misunderstood your intentions and edited my post. You managed to quote the previous version during the like 15 seconds it was actually there.

[Tuplis]

IMHO, this isn't going to work. For example, adding a completely new system for, let's say, implants must have far higher priority that adding a new weapon, if only because of the sheer amount of stuff you'll have to redo to implement the new system if we determine it viable. However, if you use the 'priority/time' system, you'll implement all the minor (0,5 hours) stuff immediatly and postpone the important but huge (10+ hours) stuff unto oblivion.

I (probably, lol) understand exactly what you mean by this because it is a central point of contention in the agile vs non-agile debate. I'll try to explain this to you within the scope of this game.

Alright, let's imagine we're adding a whole new implant system. Workload 10+ hours or so with a high value. Priority? Zip and pip.
What you do here is split the implant system down. Let's see, your normal strenght implants and so forth, then some cool utility implants like underwater breathing, infrared sight and what have you. The point is, all these subtasks have an independent value score, whereas the implant system in itself actually doesn't. We have to split larger systems down until we have a bunch of features (that have customer value in themselves) that we will implement. After that, we naturally combine these scores and work estimates and calculate the priority.
You can think of it this way: There's no point in committing to implementing a large system within the game if the enabled subfeatures don't add up to enough value to justify the effort. You have to justify every effort.

[Tuplis]

I posted a link to what I've done so far. If you'd like to take part in the design of this game, ie. decide everything that's to be implemented, just say.

[Dariush]

Java. My eternal nemesis. We meet again.

Edit: Okay, time to begin that backlog.
- Add numpad support for movement. Priority: ∞/10.

Edit 2: Well, the game is by now far too unlike a game. What are you currently doing/planning to do?

[Tuplis]

Work on a backlog... numpad support can be done in a few mins, no problem... The whole point is that there's virtually nothing in the game right now. If it was an actual game already, why would I need you? Maybe I'll just start adding stuff you say and we'll see if more people join in and this turns into something else than you telling me what to do

edit: done.

[Girlinhat]

Alright then if we're starting from scratch...
Top ten things:
1: Make sure at least one zombie spawns.  I restarted the program and had zero zombies.
2: Make the player icon white and the zombie icons green, for obvious reasons.
3: Display that you have performed an attack, instead of running a silent bit of math.
4: Random level generation.
5: Line of Sight.
6-10: Numpad support.

[Dariush]

Oh, so we are starting to work from literally next to nothing. Okay. List of stuff, in no specific order, in addition to stuff GIH said:
- Add randomly generated tunnels. That is, if you're going for 'tunnely' look like, for example, Nethack and not 'freeworld' like, for example, Cataclysm. To tell the truth, I prefer the tunnels;
- Scrolling map;
- Locations spanning more than one screen;
- Inventory screen;
- Help menu with all keybindings;
- Make zombies randomly move around. If they see player, move toward him;
- Add a timer to allow for actions with different speed (think Cogmind) (if you haven't played it, every action takes a certain time. The game advances only after player's actions, so he may move several times between other monsters' moves or move only once while monsters will be able to move several times);
- Seriously, opensource this stuff;
- Add basic clothing - T-shirt, jeans, sneakers for everyone (including zombies);
- Add item integrity - damaged clothing will protect you worse, damaged weapons deal less damage, etc.
That's all for now.

[Tuplis]

Already implemented some of that stuff and will work with others in a bit when I'm done writing.

-Both of you think random map generation is a big thing. However, seeing as how there's so little content, there's no value in implementing that now; I couldn't do anything with it.
-Adding a timer is something I thought about doing earlier but again, it's not something that has any real value right now so I'm not going to work on it yet.
-In my experience, item integrity isn't something overly standard in roguelikes at the moment and I won't even add that to the backlog for now. That's something we'll have to discuss later. There's no point in implementing a system like that unless I know I'll do something with it.
-I'll do the keybind screen when I can no longer easily remember all of them (currently arrows, numpad 2,4,6,8 and f10 to exit).

Things done as of this moment:
-Display that you have performed an attack, instead of running a silent bit of math.
-Make the player icon white and the zombie icons green, for obvious reasons.
-Make sure at least one zombie spawns.  I restarted the program and had zero zombies. (added another 3% chance per empty spot, that'll do for now)

Next things to do:
- Make zombies randomly move around. If they see player, move toward him (currently the default action when moving "on" someone is to attack, I think I'll just keep it.)
- Add basic clothing - T-shirt, jeans, sneakers for everyone (including zombies); Inventory screen

Edit: By the way, you can make your own maps. Open the text file called "test" under resources/maps. The parser currently only understands spaces, # and @. Empty spot, wall and the tile where the pc will spawn, respectively.

Just came up with an idea, btw. I could make it so that you can write a bunch of words in a text file. During startup, the program could read the textfile and load a map by the name of the first line on the list. When you've cleared all the zombies, the next map starts. What do you think?

[Girlinhat]

Another 3% chance for spawn isn't going to actually solve the "there are no zombies" bit.  Just do your level generation, then do a zombie placement for the tiles.  Mark up how many zombies are created.  If zed==0 redo.  It's incredibly easy and is much more reliable.  Not to mention that increasing spawn amount will, well, increase the spawn amount.  If you want to keep the spawns at a certain number while also generating a minimum number, you need a loop to be checked.

Random maps, timers, and integrity are all things that will help later.  They may not be useful now, but you have to look at the future goals too.  If you don't add timers, and want to add them later, will it be more difficult?  If you're going to add them anyways, will it be easier to do it now, or easier to do it when the game is more complex and you have to fit the new mechanic into existing design?

On that note, enable multiple Z levels.  That's something you need to do early, trying to add towers and rooftops later becomes very difficult once you've establish the data structures for your map.  It's an instance of "you might not use it now, but you'll save a LOT of time when you want to use it later."

[Tuplis]

Random maps, timers, and integrity are all things that will help later.  They may not be useful now, but you have to look at the future goals too.  If you don't add timers, and want to add them later, will it be more difficult?  If you're going to add them anyways, will it be easier to do it now, or easier to do it when the game is more complex and you have to fit the new mechanic into existing design?

On that note, enable multiple Z levels.  That's something you need to do early, trying to add towers and rooftops later becomes very difficult once you've establish the data structures for your map.  It's an instance of "you might not use it now, but you'll save a LOT of time when you want to use it later."

Nope, this is all against the paradigm I'm using. There must be as little as possible and not a bit more up-front design and time investment without immediate returns. What you're proposing is along the lines of what the "waterfall" method would propose. What I'm doing is the iterative approach - developing in small increments. I understand your concerns of not being able to add these things later - that is addressed by constantly paying attention to code quality.

http://en.wikipedia.org/wiki/Agile_software_development

[Dariush]

Words, words, long words, words. Level generation and timer aren't things that can be left to the future. Trust us, those two things are the most important ones.

-In my experience, item integrity isn't something overly standard in roguelikes at the moment

And that matters becaaaaause? You aren't doing yet another 'standard roguelike', you're doing something original. A lot of features can be based on item integrity. It is several lines of code, yet hours saved longterm, when you would be reworking your code to fit it in.

[Girlinhat]

Right, this is doomed.  If you're intentionally ignoring foresight then you're fairly bad at... I dunno, anything people do.  Judging by your model here, then things like new colors take 2 minutes to do and have immediate showings.  If you added a Z level structure now, it would take 2 hours and have zero showings.  On the other hand, adding different tile types might take 3 hours but make a marked improvement.  So you add different terrain.  Now that you've done that, it would take 5 hours to work Z levels into the existing code, and still wouldn't do much.  Instead you add random map generation.  Now Z levels take 8 hours with very little to show.  A month down the line, you'll still be making items different colors while adding Z levels would take a whole week to accomplish.  By that time, people will want to climb, but it's so much easier to tweak weapon balance than to change existing mechanics.

If you continue on this rate, you'll get a mediocre game comparable to a kongregate.com flash timewaster.  Just adding little bits instead of doing anything significant.

[Tuplis]

Heh, alrite. I didn't really want to pull the "I know what I'm doing" card but that's exactly what I'm doing. Right now, you are both stating opinions as facts. I've studied, practiced and researched this type of development (and this type of development is changing the whole industry as we speak - agile, lean, iterative-incremental, and the rest of the buzzwords). If you don't want to be a part of it, fine. I don't know what types of backgrounds the two of you have - the decisions I'm making are based both on modern understanding of how software engineering and project management works. What are you basing your opinions on?