Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Tuplis

Pages: [1] 2
1
Hey hey. In case anyone is still following, I'll give you a small update on the progress.

Zombies! is now actually a game because there's a purpose now. I've added a quest system with objectives, with users able to create quests and objectives and a reward with xml files. The only objective type atm, however, is a Kill objective. There are two in-game quests atm.

There's a pretty important discussion going on in the other forum regarding the way we want to take the game. Here's the original question I asked:
Quote from: Tuplis
That's why I'd like people to explicitly state which way they want to go:
1. Stealth-centric (for example, cone-like field of vision, greater emphasis on finding ways to avoid zombies through mitigating smell, sound, etc)
2. Arcade-style (piling 'em up with big weapons like rocket launchers, miniguns, etc)
3. Survival style (sleeping, eating, drinking, shelters, barricading, etc a la Rogue Survivor)

Currently we're leaning toward a combination of 1 & 3 with 1 probably being favored more because at least my feeling is that Cataclysm and Rogue Survivor explores question 3 pretty well and I'd like to think differentiation would be a good thing for us.

Based on people's answers I tried to describe a vision of the game, it's something like this:

Quote from: Tuplis
We start out in a city, Zombies everywhere. You are comparatively weak so you're best off trying to avoid combat. If you need to kill, silent melee skills are preferred to firearms. While in the city, the player could have some tough optional objectives like trying to find and rescue someone from an infested apartment building or something like that. Or perhaps someone is sick and needs meds from the hospital which, of course, is an absolute deathtrap.
Like Immortal proposed, we could then head out to the rural areas where we could perhaps center the game around the player (and his friends?) achieving long-term survival. Since sleeping is, in my opinion, already covered pretty well, I'd abstract it away. We could definitely go for this pheromore thing you seem to be interested in, though.

In other words, it's still not too late to join in and you'd really get to give input into probably the most important aspect of the game.

2
  Oh cool. I think I'd be better of a commenter after playing.

  I was only really commenting on what was said on the back log, about smell/hearing being the same.

Well, you can already play it. Go to the original post, download it and try it out :)

3
This place is just fine for suggestions.

Technically, hearing and smelling is almost exactly the same. Both would work best through an influence map. It's like you said - smell lingers (there's a source of smell which will start to weaken as time passes and every turn propagates until it's completely disappeared) and sound is an impulse (same thing except that the rate it weakens at is 100% - you only hear it for one turn.)

However, I'd rather have people do less technical design which you just did and more gameplay design, eg. "I would like it if creatures could hear" (which is already on the backlog) and so forth.

Edit: just added the rules for adding stuff in the backlog, go read the original post if interested. Also updated the version link to the latest version. We're actually approaching the release if version 1 - sayaks almost has a complete "scenario" done. After he finishes it, I will wrap it up to a more complete gaming experience and release 1.0

4
Well, he does actually have a point here.  You will get conflicting desires (and ideas that are just outright bad).  A designer must know what suggestions to reject.  Still, I think it's a worthy project, and just because it's done differently than the established norm doesn't mean it has no potential.  Plus the release early, release often model is excellent for keeping up a good development pace.

He definitely has a point that I can understand - a point made already by others. But then again, I'm not setting out to make a game that should be designed by one person alone. Sure, one person has designed whole games in the past so it's not impossible. But am I that person? Probably not. So I'm looking for help. Instead of putting in the work to design myself, I'm putting in the work to moderate what other people suggest. In my mind, the end result should be at least equivalent.

5
Haha, obvious troll is obvious. You still had me before that last one (even despite the fact Darren Grey explicitly pointed it out - I'm gullible). Please go be a sad, lonely troll who hates his job somewhere else :)

6
Other Announcements / Re: So I am Buying Diablo III
« on: June 27, 2012, 05:30:51 AM »
They've done a great job of polishing up the formula; personally I find it's a formula I've mostly outgrown, though I'm not unable to enjoy it.  I think even those who dislike and disparage the franchise should pay attention to the design refinements if they care about understanding evolution in game design.  The streamlining between D2 and D3 is strongly evident, and shows a good instinct for finding the game in the game and cutting out the rest.

It was fun enough at the start but eventually I got bored, especially when fighting is more about running around and less about piling dead monsters. I do agree that it's very streamlined and that the careful game design was a good thing. I think my issue is also that I've outgrown it because as much as the game is streamlined and shows improved gameplay design, it seems to me like something is missing. I've come to believe that 'something' is probably what I should have brought with me. But then again, the  two issues I pointed out really do eat away. I spent much of the time from about lv 10-40 browsing the auction house because at those levels, you can find insane gear at very low prices. Even so, I definitely cleared normal and nightmare faster than I would have without doing that chore.

7
Other Announcements / Re: So I am Buying Diablo III
« on: June 27, 2012, 03:48:16 AM »
I bought it when it launched. Frankly for me it was a huge disappointment, althought in hindsight I can't say I knew what to even expect from the game. The biggest disappointment was the fact that the servers were constantly down. Also, I didn't like that you basically have to visit the auction house constantly if you want to advance quickly. Your own drops are typically so bad that you can double your health, damage, everything, by buying cheap-ass items off the AH. I think the money AH is up and running already but I haven't played it for a while now so I wouldn't know. If I could get even half of my money back, I'd let go of the game immediately.

8
Well you said it's a game with a test map and you can kill some enemies. I guess it's not a roguelike. The way to reach the features of a roguelike is a big question. No one has reached that fast or easy, maybe except Biskup with ADOM. But if you do succeed in that it's a victory for everyone, because then we know what has to be done. I have to say it doesn't look good with all that help you need in game design, because it should be the starting point.

Why don't you actually play it before you guess what it isn't. Because it's obvious you didn't. I put the outdated-tags around it over a week ago. Also, I don't _need_ help. It was my choice to acquire help because that was a challenge I wanted to undertake. We've already taken a distinctly different path that I originally had thought before I decided to crowdsource the design. Why? Because in my opinion, if we have people that know what they like in roguelikes and can convey those ideas, that'll make for one hell of a good game.

9
So it's not a roguelike. I don't want to be skeptic, I'm just interested to see what happens, as always.

What do you mean it's not a roguelike? Also, please don't call me a java button coder. I'd rather stop the name-calling here.

10
This is wonderful and classic situation. A java button coder who believes in development theory X and thinks he can create a roguelike just like that.

And this person is a typical Finnish person - someone wants try something new and original (I don't know if this in fact is new and original, but it is for me) and he dislikes it and can't shut up about it by either ignoring it or following it from a distance. Instead he insults the one doing it. Hello, Finnish Guy. I'm Finnish too. Please leave.

Also, I already created a roguelike, just like that. It's not nethack or dwarven fortress but thanks to "development theory x", it's already playable.

11
Just to clear something up. You want 5-10 active people, but you will be the sole coder. So what is everyone else doing exactly? Brainstorming, I guess?

First of all I'm sorry about the slow response. I haven't checked this site a lot lately since the topic on bay12forums is much busier.

A software project actually consists of so much more than just coding it. As Jo said, one of their responsibilities is to actually play it. Testing will help us identify usability issues, technical issues (bugs) and helps us to focus on what we want the game to do (gameplay design). So basically yeah, brainstorming. The idea is to collect a bunch of people that can design a great game with me and then I'll implement it. So far it's been a great ride and you're both very welcome to join us.

12
In particular I strongly suggest get something properly playable very soon. 

Well, I just added the link. Strictly speaking, it's playable but lacks all kinds of stuff. Tell me what you want in there.

13
* Have clear development goals and target dates that you publicly state and try to adhere to (and accept advice on - others may disagree on how achievable or advisable your targets are)

In every software development project there are three variables, of which you can only lock down two. The variables are scope, time and resources. Committing to a specific scope within a specific time would mean I'd need to have flexibility in terms on resources, ie. manpower. I will be the sole coder on this project, however. Also, the fun part for me in this project is to have no clear scope. That's something that emerges during development.

14
No such thing as too many well wrought Roguelike projects.   :)  I like the gist of the plan, as it seems like a natural evolution of sorts of the classic "Talkie"---though more inclined towards manageable success than pie in the sky alongside more folks chiming in ideas.

-Turn based?
-Sound/Music?
-Intentions on full-screen and resolutions?
-Color range?
-Platforms?


Once things get spec'd out in detailed fashion, it would likely help to gain some traction.  Also, I'd highly recommend getting the Bay12 forum folks in on this at the "Other Games" board-----big fans of Rogue Survivor and Catcaclysm in those parts.

Thank you for the encouraging words. I'll address a couple of the points you made.

I don't plan on "speccing things out in detailed fashion" as you put it. The idea is for the people assisting plus me to do it together on the fly. The way it works is that I present what I've done so far and then people brainstorm around the question "What can we do to make it better?". Obviously there'll be ideas like "let's turn it realtime with hexes, have a* pathfinding with a complex multi agent based artificial intelligence model and infinite sized worlds". But that's not how agile planning works. The way it works is that people come up with stuff that they feel would contribute towards making it a better game. For instance:

-"I think we should add sounds that are played when you hit something." After that, we proceed to assess the end-user value of that feature. We decide that it's perhaps 6 points out of 10 because it's pretty important yet not critical. After that I estimate the work it would take to implement it. Adding sounds is pretty straightforward so I'll give it 2/10 points for effort. So now it has a priority of 6/2 = 3.
-We repeat this process for everything suggested and produce a prioritized backlog and I'll start implementing.

Of the five points you just posted, I'm quite confident only one actually has to be decided up front and that's the first one. That's a major part of the architecture that affects pretty much everything: If it's realtime, we have a lot less time for tasks like pathfinding and AI for example. The rest are up for discussion.

I'll post this on Bay12 too. Thank you.

15
Java with the blacken library. I wrote it down on one on the locked down req's

Pages: [1] 2