A Seven Day Roguelike is a roguelike created in seven days. This means the author stopped writing code one hundred and sixty eight hours after they started writing code.
--------------
A Seven Day Roguelike (7DRL) can be written at any time. However, a general agreement was reached that it would be fun to schedule a specific week for a challenge. This allows the various authors to know that others are also desperately tracking down a bad pointer reference on the 167th hour.
The week has been chosen for the Fifth Annual 7DRL Challenge!
After an unscientific straw poll, the following scientific-looking graph was generated:
Feb 21 - Mar 1: ########### Feb 28 - Mar 8: ####### Mar 7 - Mar 15: ##################
A discursive analysis of this shows that the use of the # sign makes for an aesthetically pleasing method for representing bar graphs.
The week for the Seven Day Roguelike Challenge has been chosen!
Within the week of March 7th to March 15th, you are hereby challenged to write a roguelike in 168 hours!
To participate, follow these simple steps: 1) Any time on March 7th or March 8th (as measured in your time zone), post to rec.games.roguelike.development that you have started work on your Seven Day Roguelike. 2) Write a roguelike. 3) After 168 hours, if you have completed a playable roguelike, post your success to rec.games.roguelike.announce! If not, post your lack of results to rec.games.roguelike.development, where we will all commiserate and agree that given a few scant more hours, it could have been great.
Good Luck!
I will try to post a reminder message the Wednesday before the challenge. -- Jeff Lait (POWDER: http://www.zincland.com/powder)
Excellent! Is it expected that source will compile natively in Windows, or are submissions written for Macs also welcome?
I keep my sourcecode machine-independent, but I don't have a PC at home so I can't compile PC binaries or use PC interface API's. My brother and I hacked together our own roguelike front-end for getting keystrokes and displaying colored characters.
> Excellent! Is it expected that source will compile natively in > Windows, or are submissions written for Macs also welcome?
> I keep my sourcecode machine-independent, but I don't have a PC at > home so I can't compile PC binaries or use PC interface API's. My > brother and I hacked together our own roguelike front-end for getting > keystrokes and displaying colored characters.
You can cross compile from mac to linux and maybe even linux. You can use a VM or some sort of mac software whose name I don't remember to run/emulate windows on your mac. Not to mention that macs these days are basically PCs and you cam install windows/linux and dual/triple boot them.
At any rate, releasing the source will be greatly appreciated :)
> You can cross compile from mac to linux and maybe even linux. You can > use a VM or some sort of mac software whose name I don't remember to > run/emulate windows on your mac. Not to mention that macs these days > are basically PCs and you cam install windows/linux and dual/triple > boot them.
I cross compile Hellband from mac to windows. It is possible.
> At any rate, releasing the source will be greatly appreciated :)
On Jan 29, 2:25 pm, Ido Yehieli <Ido.Yehi...@gmail.com> wrote:
> You can cross compile from mac to linux and maybe even linux. You can > use a VM or some sort of mac software whose name I don't remember to > run/emulate windows on your mac. Not to mention that macs these days > are basically PCs and you cam install windows/linux and dual/triple > boot them.
Maybe YOU can do these things, but I am not nearly proficient enough :)
Perhaps it would have been more accurate to say "I am not willing to gain the skills and procure the software necessary to compile PC binaries or use PC interface API's." :)
> At any rate, releasing the source will be greatly appreciated :)
> Perhaps it would have been more accurate to say "I am not willing to > gain the skills and procure the software necessary to compile PC > binaries or use PC interface API's." :)
> > At any rate, releasing the source will be greatly appreciated :)
> Always!
Any platform is welcome, you just limit your playing group. Just concentrate of getting a working game, I am sure there are plenty of mac users out there. I played moria for 6 years on a mac. Release the source to the world, ask for help and after the compo someone may help you.
On Jan 30, 2:34 am, Jeff Lait <torespondisfut...@hotmail.com> wrote:
> Within the week of March 7th to March 15th, you are hereby challenged > to write a roguelike in 168 hours!
Because I have a history of bending the rules, I will ask this question. Is level design, (e.g. using the new Ascii Paint program to create text levels), a fair thing to do before starting date? Considering that it is content I am guessing not? Or is it just coding that should really be done. And yes I know variations of this question are asked every year and I read the answers every year.
On Jan 30, 12:04 am, corremn <corr...@gmail.com> wrote:
> Is level design, (e.g. using the new Ascii Paint program to create > text levels), a fair thing to do before starting date? Considering > that it is content I am guessing not? Or is it just coding that > should really be done.
I wouldn't consider it cheating, since a lot of people also start with their old code/frameworks or just rip code out of their old games to create a new one.
Remember that the purpose is to produce a game. just tell us in advance what you start with before the challenge, so it's all out in the open.
On Jan 29, 11:34 am, Jeff Lait <torespondisfut...@hotmail.com> wrote:
> What is a Seven Day Roguelike?
> A Seven Day Roguelike is a roguelike created in seven days. This means > the author stopped writing code one hundred and sixty eight hours > after they started writing code.
> Excellent! Is it expected that source will compile natively in > Windows, or are submissions written for Macs also welcome?
1) There is no requirement to submit source. 2) There is no official platform.
It is quite acceptable to submit a binary that works only on a C64 as your challenge entry. Of course, that makes it less likely anyone will be able to play it...
> I keep my sourcecode machine-independent, but I don't have a PC at > home so I can't compile PC binaries or use PC interface API's. My > brother and I hacked together our own roguelike front-end for getting > keystrokes and displaying colored characters.
It is quite reasonable for your initial 7DRL release to only work on your favorite platform and to add support for other platforms later. If you release source, it is even possible that someone else will provide the other platform support. -- Jeff Lait (POWDER: http://www.zincland.com/powder)
On Jan 29, 6:04 pm, corremn <corr...@gmail.com> wrote:
> On Jan 30, 2:34 am, Jeff Lait <torespondisfut...@hotmail.com> wrote:
> > Within the week of March 7th to March 15th, you are hereby challenged > > to write a roguelike in 168 hours!
> Because I have a history of bending the rules, I will ask this > question.
> Is level design, (e.g. using the new Ascii Paint program to create > text levels), a fair thing to do before starting date? Considering > that it is content I am guessing not? Or is it just coding that > should really be done.
I'd say level design, as in pen and paper sketching ideas, would clearly be acceptable. When you start producing finalized levels ahead of the challenge? I dunno...
Using levels from other projects would seem acceptable, much like using code from other levels is acceptable. But consider Fatherhood. Would it be acceptable for me to have built the maps ahead of time? Well, practically I couldn't, because they had to match the game mechanics I didn't fully know at the time. And, weakly, I did, because I started the map by cutting and pasting the village map from You Only Live Once.
The same question arises for artwork. Can one build a tileset for a 7DRL prior to the 7DRL? I would think not, but I'd have nothing to object to using a tileset you happened to have built before in your 7DRL...
If you would make these maps even if you weren't writing the 7DRL, then they are acceptable. Ie, if you are playing around with AsciiPaint and create a bunch of maps, you can then say, Hey, I'll swipe these for my 7DRL. But if you have a work-order of maps that are needed for your 7DRL and you start cranking them out prior to the challenge start, you are bending the rules. -- Jeff Lait (POWDER: http://www.zincland.com/powder)
On Jan 30, 8:06 pm, Jeff Lait <torespondisfut...@hotmail.com> wrote:
> On Jan 29, 6:04 pm, corremn <corr...@gmail.com> wrote:
> > On Jan 30, 2:34 am, Jeff Lait <torespondisfut...@hotmail.com> wrote:
SNIP
> If you would make these maps even if you weren't writing the 7DRL, > then they are acceptable. Ie, if you are playing around with > AsciiPaint and create a bunch of maps, you can then say, Hey, I'll > swipe these for my 7DRL. But if you have a work-order of maps that > are needed for your 7DRL and you start cranking them out prior to the > challenge start, you are bending the rules.
I say, just release something before the end of the 7DRL deadline, all the rest is honor or shame :)
> On Jan 30, 8:06 pm, Jeff Lait <torespondisfut...@hotmail.com> wrote:
> > On Jan 29, 6:04 pm, corremn <corr...@gmail.com> wrote:
> > > On Jan 30, 2:34 am, Jeff Lait <torespondisfut...@hotmail.com> wrote:
> SNIP
> > If you would make these maps even if you weren't writing the 7DRL, > > then they are acceptable. Ie, if you are playing around with > > AsciiPaint and create a bunch of maps, you can then say, Hey, I'll > > swipe these for my 7DRL. But if you have a work-order of maps that > > are needed for your 7DRL and you start cranking them out prior to the > > challenge start, you are bending the rules.
> I say, just release something before the end of the 7DRL deadline, all > the rest is honor or shame :)
Ok, ok.
I feel the need take these words back, my reply was really misleading.
So, this is what I actually think in short words: The 7DRL challenge has degenerated a bit, partly because too much freedom has been given. The spirit of the challenge has changed, the development of the games is starting weeks before.
I think part of this happening has been caused by the need of having better products and filling them with worthy content, which has transformed the allowed "planning" phase into a detailed "data entry" or "tool making" phase in which everything goes; now, it is clear that 7DRL challenge is not about who codes faster, but rather who can start and end a roguelike with a delimited scope in the faster and better way (IMO).
So, what tops my head now?
1. Maybe we need a 1MRL challenge (1 Month Roguelike Challenge), where projects with higher scope and quality (and quantity) of content could be produced.
2. For the 7DRL challenge, the guideline for the planning phase (previous to the challenge timeframe) would be something like "doing whatever planning and dreaming, as long as you are not using computer aided tools". I know it may sound rough and needlessly restrictive, but what I want to disallow is the use of computer tools to compile a real ammount of content, which you can then use for your game.
In the end, I think developing a game is not just about coding; content makes up for great part of it.
On Feb 4, 8:11 pm, Slash <java.ko...@gmail.com> wrote:
> 2. For the 7DRL challenge, the guideline for the planning phase > (previous to the challenge timeframe) would be something like "doing > whatever planning and dreaming, as long as you are not using computer > aided tools". I know it may sound rough and needlessly restrictive, > but what I want to disallow is the use of computer tools to compile a > real ammount of content, which you can then use for your game.
> In the end, I think developing a game is not just about coding; > content makes up for great part of it.
I definitely think this would be a good idea. It would make me more interested in actually writing a 7DRL.
On Feb 4, 9:11 pm, Slash <java.ko...@gmail.com> wrote:
> I think part of this happening has been caused by the need of having > better products and filling them with worthy content, which has > transformed the allowed "planning" phase into a detailed "data entry" > or "tool making" phase in which everything goes; now, it is clear that > 7DRL challenge is not about who codes faster, but rather who can start > and end a roguelike with a delimited scope in the faster and better > way (IMO).
It never should have been about who can code faster in the first place. Sure, some people plan before the actual week (I'm definitely guilty, and you all will see why once my game is released), but maybe it's because they simply won't have time to do design during the competition week, or even that they have good ideas that they don't want to lose. Another thing: what's wrong with a desire for worthy content? Is that some sort of admission that 7DRLs are going to be lousy? The point of the 7DRL challenge is to produce fun, playable, complete games; as long as that's accomplished, what's wrong with a few out-of-competition design documents?
> 1. Maybe we need a 1MRL challenge (1 Month Roguelike Challenge), where > projects with higher scope and quality (and quantity) of content could > be produced.
I don't like this idea. It's too easy to lose focus, too easy to have too large a scope, and generally won't do what the 7DRL challenge is intended to (that is, get developers to release playable games).
> 2. For the 7DRL challenge, the guideline for the planning phase > (previous to the challenge timeframe) would be something like "doing > whatever planning and dreaming, as long as you are not using computer > aided tools". I know it may sound rough and needlessly restrictive, > but what I want to disallow is the use of computer tools to compile a > real ammount of content, which you can then use for your game.
That's a tough call for me. As soon as the challenge is announced (and maybe before), people are going to be thinking about what their game is going to be and what will be in it. If you force them to use inefficient tools, you risk losing a lot of great ideas.
> In the end, I think developing a game is not just about coding; > content makes up for great part of it.
True, but you need a good engine before you can develop good content. Restricting the coding to a single week forces the developer to complete that engine.
On Feb 5, 3:11 am, Slash <java.ko...@gmail.com> wrote:
> So, this is what I actually think in short words: The 7DRL challenge > has degenerated a bit, partly because too much freedom has been given. > The spirit of the challenge has changed, the development of the games > is starting weeks before.
> I think part of this happening has been caused by the need of having > better products and filling them with worthy content, which has > transformed the allowed "planning" phase into a detailed "data entry" > or "tool making" phase in which everything goes; now, it is clear that > 7DRL challenge is not about who codes faster, but rather who can start > and end a roguelike with a delimited scope in the faster and better > way (IMO).
I disagree personally. The "challenge" was invented, as I see it, to encourage actual games to be released, and the RogueBasin article places strong emphasis on this. It also restricts people's scope in games - there are far too many behind-the-scenes projects that are designing the moon and the stars. The 7drl projects force people to put their feet back on the ground. And further to this it encourages a little more creativity and originality through simple games that stand out more for their theme and special features.
The actual challenge of coding quickly is irrelevant in my eyes, as long as there are releases. "All the rest is honour and shame" as you put it before - I agree with that sentiment completely. The RogueBasin article makes it clear that using pre-existing code is fine, as is using libraries, or even whole games if you think you can seriously make something original from it. These games don't get rated and many of them never get played again unless they're really special. Much like the 1kbrls they're meant to be experimental and fun. Too many rules would take away the fun.
> So, what tops my head now?
> 1. Maybe we need a 1MRL challenge (1 Month Roguelike Challenge), where > projects with higher scope and quality (and quantity) of content could > be produced.
Will lead to vapourware in my opinion. Give people too much room for scope and quality and they'll return to their dreams of moons and stars. Very few 1MRLs would actually be released, though many would be started.
> 2. For the 7DRL challenge, the guideline for the planning phase > (previous to the challenge timeframe) would be something like "doing > whatever planning and dreaming, as long as you are not using computer > aided tools". I know it may sound rough and needlessly restrictive, > but what I want to disallow is the use of computer tools to compile a > real ammount of content, which you can then use for your game.
And yet libraries and pre-existing FOV and map generation algorithms would still be allowed? Seems contradictory. Exactly what are you trying to prevent anyway? Unfairness? If that's the case then I think you're taking it too seriously. It's a bit of fun, let's not get all heavy about it.
This discussion stemmed from someone saying they wanted to play with map designs in AsciiDraw beforehand. How's this different to doodling map designs on paper? Or using pre-existing map generators? And like Jeff said it's quite likely that any design beforehand gets altered within the seven days to fit around the actual game mechanics (which are much more important). Overall such work beforehand is unlikely to save them more than a few minutes.
Personally I'm against restrictive rules, especially in a challenge where winning is just a matter of completing the race. If people want to bend the rules to make it more enjoyable for them, then so be it. The only thing I'd say is that everyone should be honest about everything pre-existing they've used.
On Feb 5, 12:38 am, Gamer_2k4 <gamer...@gmail.com> wrote:
> It never should have been about who can code faster in the first > place. Sure, some people plan before the actual week (I'm definitely > guilty, and you all will see why once my game is released), but maybe > it's because they simply won't have time to do design during the > competition week, or even that they have good ideas that they don't > want to lose. Another thing: what's wrong with a desire for worthy > content? Is that some sort of admission that 7DRLs are going to be > lousy? The point of the 7DRL challenge is to produce fun, playable, > complete games; as long as that's accomplished, what's wrong with a > few out-of-competition design documents?
I'm kinda with slash on this side of the fence.
I think its one thing to plug in some existing code (libfov,tcod whatever), but if you start making maps, well that IS your game and that seems not to be in the spirit of the thing.
using maps that already existed, again is one thing, but CREATING content before hand is like some backhanded slap.
> That's a tough call for me. As soon as the challenge is announced > (and maybe before), people are going to be thinking about what their > game is going to be and what will be in it. If you force them to use > inefficient tools, you risk losing a lot of great ideas.
> > In the end, I think developing a game is not just about coding; > > content makes up for great part of it.
> True, but you need a good engine before you can develop good content. > Restricting the coding to a single week forces the developer to > complete that engine.
a 7drl isn't about an engine, to me thats way out of scope of a 7drl.
if you want to write content for an engine, make your content the entry and write it for an existing engine or hworld or something.
Is there a line to be crossed? some people probably see a line, some a blur and some no line. but I dont think we can turn around and say all code must be new and force people to write their own curses drivers or sdl drivers, no one can plan or do this or do that.
I dont see a difference between the content and the game. they are not separate entities.
Seeing as, traditionally, the last few days are dedicated to level creation in these contests (in games that have that), I agree that it would be against the spirit of the contest to create them before. It's hard to define a line that cannot be crossed, so IMHO the only way to know what's ok and what's not is to look at previous contests and see if what authors propose (ie, making levels beforehand) is too different from previous 7DRL's (in this case, it is).
I wouldn't try to define rules like "no authoring tools allowed", but rather discuss each case, like we're doing now.
And one of the most important things is that every contestant must state *explicitly* what he/she is using! There's a difference between saying "I came up with this on the 2nd day through" and "I had this part done beforehand". Not that there's anything wrong with it, but it should be stated.
> Seeing as, traditionally, the last few days are dedicated to level > creation in these contests (in games that have that), I agree that it > would be against the spirit of the contest to create them before. It's > hard to define a line that cannot be crossed, so IMHO the only way to > know what's ok and what's not is to look at previous contests and see > if what authors propose (ie, making levels beforehand) is too > different from previous 7DRL's (in this case, it is).
> I wouldn't try to define rules like "no authoring tools allowed", but > rather discuss each case, like we're doing now.
> And one of the most important things is that every contestant must > state *explicitly* what he/she is using! There's a difference between > saying "I came up with this on the 2nd day through" and "I had this > part done beforehand". Not that there's anything wrong with it, but it > should be stated.
> Jotaf
After thinking about it more I changed my mind. I think it should be allowed as long as the fact that the levels were (for the most part) pre-designed is stated explicitly in the 7DRL's description. That would be enough of an indication that the quality of the levels is due to them being done without the time pressure, and so this 7DRL can be compared fairly to others that didn't do the same thing. Too many rules and it starts draining the fun, so IMO this would be the best way.
|
