Temple of The Roguelike Forums
Announcements => Other Announcements => Topic started by: Tuplis on June 11, 2012, 05:10:15 PM
-
Hey everyone,
I'm Tuplis, a new guy here on the forums. I'm a 25-year-old fresh Master of Science in Technology with software engineering as my major. I'm currently coding full-time for a software company. I specialize in agile software development processes.
I've been playing roguelikes on and off for about 15 years now and decided I'll finally make one of my own. During these years I've come to realize that one person can make a really great roguelike because of the ability to focus on "the good stuff" instead of drawing 3d models and all that stuff. So, here's my attempt at combining my specialization - agile development - with the process of making a roguelike.
[outdated]
I currently have a very simple game, simply called "Zombies". There's only one test map and a player character can run around and kill a bunch of zombies that will be randomly generated on startup. That's it. And there's where you lot come in.
[/outdated]
The central idea in agile development is to constantly publish release-level-polished functionality in small increments. This allows the product to rapidly evolve in face of changing requirements. So my idea is to have the community of players playing the game define what those requirements are - literally (nearly) almost all of them. Here's the complete run-down of the functionalities I've so far "locked", everything else is up for discussion:
-Roguelike. No emphasis on graphics beyond what ascii can represent. I've committed to writing in Java with the blacken library which I find sufficient.
-Zombie apocalypse theme. It's just what I want to do.
If I can gather a group of 5-10 active people, I can start churning away at it. I can work perhaps around 10 hours a week as I work full-time on the side. Agile development hinges on writing continuously excellent quality code in order to avoid rework and the idea is to constantly (weekly to monthly) release everything made up to that point so there will be constant progress. That amount of active people should suffice in creating me a backlog of work to chip away at. More are also welcome of course!
So, who would be interested in this project?
Here's the link to what I have so far: https://dl.dropbox.com/u/84930267/Zombies-0-12-8-6-0.rar
Keybinds: https://docs.google.com/document/d/1nZK3IR_2ra0mXIB25uAFNfHphHMRocTD309Zuw-P-SY/edit
Changelog: https://docs.google.com/document/d/1vgiqPBb-hJozND57uWOs2mRmPbKJfXF4BY97iZD23Nw/edit
Backlog: https://docs.google.com/spreadsheet/ccc?key=0Ar3Z_84uVAcldDNNeW14SUI3N2VpN1lUU2tPajMzTkE
Rules for the backlog:
-Anyone can add stuff but use common sense about whether we need to discuss the feature first (eg. don't add stuff like magic spells)
-Every new backlog item needs to have end-user value. The value can also change over time: A random map generator is nearly useless in a game with almost no features and thus will increase in value over time. Conversely, a minor shift in game scope might make an otherwise important feature obsolete.
-When adding a new item, consider whether you can break it down to independent functionalities out of which at least one has end-user value in itself. Iterate this process until you can no longer break the feature down.
-Add yourself a column in the value-area if you want to contribute on that
-Ignore Effort unless there's a ? in there
-Add yourself a comment column if you need to. We'll need to address that if it becomes too wide/unreadable.
-Don't remove/change anything other people added (outside of typos)
-If you know what you're doing, you can stylish the file. Just remember that usability comes first.
Remember: It's never too late to get on board!
I'm getting suggestions on bay12 forums too (http://www.bay12forums.com/smf/index.php?topic=111369.0) so feel free to check out what's going on in there as well. And tell me what you want in the game.
Troubleshooting:
-Check that your java path is set (http://java.com/en/download/help/path.xml)
-Target Java version is 1.6, make sure you have that or higher.
Regards,
Tuplis
-
What language / libraries are you using ?
T.
-
Java with the blacken library. I wrote it down on one on the locked down req's
-
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.
-
I'm always willing to give feedback and try something out.
-
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.
-
Maybe this is also something for the roguelike incubator?
-
* 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.
-
Yeah, I don't think the incubator is suitable for this - too restrictive. However you should keep an eye on it for inspiration. In particular I strongly suggest get something properly playable very soon. Don't be afraid to add things in that you can take away later. For anyone to give real feedback they want something playable (and preferably completable) first. It's easy to doodle on a sketch than draw on a blank slate.
-
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.
-
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?
-
Playing! :-)
-
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.
-
Oh wow that thread already has a lot of activity. I guess I'll catch up reading it and then say whether or not I'm in.
-
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.
-
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.
-
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.
So it's not a roguelike. I don't want to be skeptic, I'm just interested to see what happens, as always.
-
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.
-
Krice is trolling you - you're best ignoring him before he derails your thread. His definition of roguelike is more exclusive than anyone else's.
-
What do you mean it's not a roguelike?
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.
-
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.
-
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.
People like different things. I think it's best to have one person as a designer who really knows why games are good, rather than ten random guys who all have their own ideas. If you had an idea that anyone can be a good game designer you will soon learn how wrong you were. It looks like you don't respect game design really that much, maybe because your background as "real" programmer. Well, that view is going to change too.
-
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 :)
-
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.
-
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.
-
Krice generally has good points. It's his delivery that turns people off. My take is that you should go and experiment however you want. Design by committee is almost always a bad idea, as long as you maintain a firm hand with your 'team' it should be alright.
We'll see.
EDIT: Confused as to where to put suggestions. So I'll do it here.
Smelling and Hearing should not be treated the same. Smells may have a small radius but they should linger on tiles so that a wandering creature is activated and follows the smells. Some can smell better so can detect older smells, some cannot smell at all. Hearing is totally different, it is a radial feature (extends out from the player), it can also activate zombies who will go straight at the sound as opposed to following a trail. Also, some creatures are deaf.
Just my two cents. I like the Hearing, Seeing, Smelling modes of activating and detecting the player.
-
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
-
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.
-
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 :)
-
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:
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:
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.