I am starting right now, using the code in my roguelulz article
( http://www.kuro5hin.org/story/2007/11/29/5715/1869 ) and in addition
reserve the right to use any random code snippet from wikipedia or
roguebasin (e.g. for los).
See you in 1 week,
Ido.
Good luck Ido!
A programmer after my own heart. Happy hacking!
--
\_\/_/ some girls wander by mistake into the mess that scalpels make
\ / are you the teachers of my heart? we teach old hearts to break
\/ --- Leonard Cohen, "Teachers"
I'm also attempting one, but I'm not sure I'll have time to finish it.
I will post success(or defeat) on Thursday.
Malorzean
This is a "me too" message. Since 1992 I´m trying to code a roguelike
but unsuccessfully until now. I think is time to finish it or die (¡!)
Im going to accept the challenge just for fun. See you all in one
week. (I¨m going to show my progress in my blog http://www.micronosis.com
(spanish)).
Cheers,
--
/\+++/\
< agnas >
\/+++\/
Hombre, Agnas, no esperaba verte por aquí :)
Good luck with your 7DRL. It's now or never, SKATE OR DIE!
Remember to include a good deal of orcs.
Hi Alkhwa!
Well actually I´m a roguelike fan long before I put my hands on
interactive fiction... back to the roots??
Saludos,
I have tried only since 1995, so I'm just a newbie.
Then onto random map generation (probably the hard part). After that
I'll add different types of enemies (currently there are only
"m"onsters that have 2 hp and 1 damage), dungeon levels & winning/
losing conditions.
Then we'll see if I have time to add anything else...
-Ido.
RoguelikeLib would do it for you ;)
> Then onto random map generation (probably the hard part).
The same here :)
> Then we'll see if I have time to add anything else...
That's why I made the RoguelikeLib - to focus only on the interesting
stuff.
I had hope that people will use it, but I see that nobody is interested
in making a game, but in doing the basic algorithms all the time...
regards,
Jakub
Hi Jacob - I want to implement all the basic algorithms by myself at
least once.
I actually find a lot of them to be quite interesting and my goal
isn't only to make a game as quickly as possible, but also to learn as
much as possible from the experience.
-Ido.
Jotaf
Jotaf
Currently:
- FOV
- Map (generation, utils)
- Distance counting
- Pathfinding
- Randomness
regards,
Jakub
Defeat! I had internet troubles in the last few days so it was rather
difficult and I couldn't post.
Oh well, at least it gave me a few more ideas about design
possibilities.
Malorzean
I am sure the experience would help succeed next time - maybe in next
month's challenge?
I am more or less done and am adding a bit of glitz and polish. I also
have to come up with a name...
-Ido.
Well I´m not sure if 7DRL is just to demostrate that is impossible to
finish a RL in one week but
to motivate the developing of new RL. If this is the case, the
chalenge in my case was a victory because I´m a few days from deliver
a new fresly developed Roguelike game.
As I said before, I started this project around 1992, and the dungeon
map generation was finished in1998 (I´m not sure but I believe that I
workd on that part something like 40 hours or something). The sources
remained untouched until 7 days ago. Now I believe I have a RL nearly
completed:
· map generation full tested.
· npcs/monsters generation and moving ai ready & tested.
· dungeon system full working: the engine allow some control over the
randoness, so I could design a castle, its valley and so.
· inventory
· basic battle system
This is a independent codebase, I develop everything with my bare
hands.
What is missing?
· Balancing
· Only 50% commands ready
· History and mission testing
· several key monsters & npcs special ai.
I believe that in one week more I could drop this beauty to
betatesting, so if you are interested please raise your hands. (I will
announce this in the apropriate group stay calm...)
Its windows only, full developed with the Win32 API. A SDL version is
planned sometime before 2019.
Stay tuned.
··
<spaninglish>demostrate</spaninglish>
demostrate== prove
I forgot to mention...
· Full C++ (containers, classes, one file for each class (no templates
though). Nothing like the 64K Moria files.
· LOS/Lighting/Shadows full working.
· Anti savescumming system (I know... useless) but was very fun to
implement I´m sure somebody will ask how I did that. Back in 1985 I
was amazed how the original rogue anti savescumming system was
implemented.
···
Suddenly I was curious the LOC numbers of others RL. This is my
discovery:
Rogue (original version) 10375
Hack (original version) 13418
Umoria (Amiga version) 38047
I dont know and I dont want to know how many lines of code has
Nethack, but I suppose its a number close to the Graham number
(http://en.wikipedia.org/wiki/Graham%27s_number).
Here is the shell script I use to get the metrics:
<code>
#!/bin/bash
let "p = 0"
for filenm in `ls *.c *.h *.cpp` ; do
c=`wc -l $filenm | awk '{ print $1;}'`
let "p = p + c"
echo -n "."
done
echo
echo $p
</code>
Have fun!
My 7DRL it's exaxtly 5200 ... it's a sign of destiny??
There is a nifty program called "LOCMetrics", I use it to keep track
of my projects (currently Pixelwars at http://szdev.livejournal.com)
It gives much better stats :P
--
Slash
> I was checking how many lines of code (http://en.wikipedia.org/wiki/
> Lines_of_code) has my program now and it come to be 6250 LOC. That is
> 2800 LOC in 10 days (aproximately). Its not my best number but. I´m
> happy with it.
>
> Suddenly I was curious the LOC numbers of others RL. This is my
> discovery:
>
> Rogue (original version) 10375
> Hack (original version) 13418
> Umoria (Amiga version) 38047
>
> I dont know and I dont want to know how many lines of code has
> Nethack, but I suppose its a number close to the Graham number
> (http://en.wikipedia.org/wiki/Graham%27s_number).
Hmm, I think Nethack 3.43 has 157,644 total lines in .c and .h files.
Here's a question for C/C++/Java programmers: how many of your LOC are
just a { or }? A little work with
grep '^[ ]*[{}]$'
(that's a space and a tab in the first brackets) gives me 17-18%.
If I was making a LOC counter for C++/Java, I'd count the number of
semicolons and closing brackets. Aside from preprocessor stuff, that
would give you a pretty good estimate.
--
Gamer_2k4
My C++ code has pretty much *no* preprocessor constructs; between
templates and inline functions, there's not a great deal left that needs
them :)
Arrgh!! I said I dont want to know it!
>
> Here's a question for C/C++/Java programmers: how many of your LOC are
> just a { or }? A little work with
>
> grep '^[ ]*[{}]$'
>
> (that's a space and a tab in the first brackets) gives me 17-18%.
My rustic shell script counts that as an additional line. But, my
friend, do you know the effort and knowledge needed to put a bracket
in a line?? Yes, definitely, a line only with a { counts as a line of
code. (as is stated in http://en.wikipedia.org/wiki/Lines_of_code its
a phisical line of code)
Cheers,
A single line is enough :
wc -l *.[ch]* | tail -1 | awk '{print $1}'
TCOD : 17089
TCODLIB : 3163
It's scary to see that I already have more lines that rogue and
hack... and yet no game...
--
jice
> There is a nifty program called "LOCMetrics", I use it to keep track
> of my projects (currently Pixelwars at http://szdev.livejournal.com)
> It gives much better stats :P
For Lair of the Demon Ape, LOCMetrics gives:
LOC: 27615
BLOC: 4440
SLOC-P 20078
SLOC-L 12302
C&SWLOC 847
CLOC 3097
HLOC 284
HCWORD 819
McCabe VG 3038
- Gerry Quinn
--
Lair of the Demon Ape (a coffee-break roguelike)
<http://indigo.ie/~gerryq/lair/lair.htm>
Heh, why not just use sclc? it will also show you how many non-
comment, non-empty lines your sources have.
-Ido (aka joe6pack)
>On 8 f=E9v, 00:45, agnas <gustav...@gmail.com> wrote:
>> <code>
>> #!/bin/bash
>> let "p =3D 0"
>> for filenm in `ls *.c *.h *.cpp` ; do
>> =A0 =A0 =A0 =A0 c=3D`wc -l $filenm | awk '{ print $1;}'`
>>
>> =A0 =A0 =A0 =A0 let "p =3D p + c"
>> =A0 =A0 =A0 =A0 echo -n "."
>> done
>> echo
>> echo $p
>> </code>
>>
>
>A single line is enough :
>
>wc -l *.[ch]* | tail -1 | awk '{print $1}'
>
>TCOD : 17089
>TCODLIB : 3163
>
>It's scary to see that I already have more lines that rogue and
>hack... and yet no game...
Are you a Java programmer by chance? ;)
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
Not even. I'm a C/C++ guy... Shame on me... :(
--
jice
>> Here's a question for C/C++/Java programmers: how many of your LOC are
>> just a { or }? A little work with
>>
>> grep '^[ ]*[{}]$'
>>
>> (that's a space and a tab in the first brackets) gives me 17-18%.
>
> My rustic shell script counts that as an additional line. But, my
> friend, do you know the effort and knowledge needed to put a bracket
> in a line??
Hmm, I suppose it does take a bit of work to figure out how to get the [
key to make a {.
I know it's standard practice to count those lines in curly-brace
languages, but I do have a specific reason for asking. Being primarily a
Lisp programmer, my programs don't have extra lines for opening or
closing braces, e.g.:
(loop
(simulate-a-*WORLD*))
rather than
while(1)
{
simulate_a_WORLD();
}
That's a 100% increase due to braces right there. Obviously that makes
it a little difficult to compare my LOC (currently < 1k, hopefully I can
unwrite some of that) to, say, a C programmer's. Real curly-brace code
(written by me) seems to be < 20% braces for Allman-style indentation. I
suppose that works out to < 10% for K&R. So maybe it's not a significant
contributor to LOC anyway. I'll just go back to boggling at everyone's
numbers.
I'm at about 1kloc of plain c (not including [comment|empty] lines,
with'em it's about 1.5kloc), but about 400 of these lines are from
Nicholas Kisseberth's code for handling fancy keyboard input portably.
Since I don't really need all these [ctrl|alt]+something keycodes i
can probably trim that by 200+ lines.
-Ido.
> I know it's standard practice to count those lines in curly-brace
> languages, but I do have a specific reason for asking. Being primarily a
> Lisp programmer, my programs don't have extra lines for opening or
> closing braces, e.g.:
>
> (loop
> (simulate-a-*WORLD*))
>
> rather than
>
> while(1)
> {
> simulate_a_WORLD();
> }
>
> That's a 100% increase due to braces right there. Obviously that makes
> it a little difficult to compare my LOC (currently < 1k, hopefully I can
> unwrite some of that) to, say, a C programmer's. Real curly-brace code
> (written by me) seems to be < 20% braces for Allman-style indentation. I
> suppose that works out to < 10% for K&R. So maybe it's not a significant
> contributor to LOC anyway. I'll just go back to boggling at everyone's
> numbers.
The SLOC-L value given by LocMetrics is equal to the number of terminal
semicolons, plus the number of terminal curly braces.
So SLOC-L for the C example would be reported as 2.
> That's a 100% increase due to braces right there. Obviously that makes
> it a little difficult to compare my LOC (currently < 1k, hopefully I can
> unwrite some of that) to, say, a C programmer's.
What is the roguelike?
- Gerry Quinn
> my programs don't have extra lines for opening or
> closing braces, e.g.:
>
> (loop
> (simulate-a-*WORLD*))
>
> rather than
>
> while(1)
> {
> simulate_a_WORLD();
> }
even in C and C++ the following is possible:
while ( 1 ) {
simulate_a_world(); }
Would be the same with your LISP-Code in LOC. BUT! We have to put an main
around that... Thats at least 1 more LOC:
void main () {
while ( 1 ) {
simulate_a_world(); }}
But hey... I can write that as one line:
void main () { while ( 1 ) { simulate_a_world(); }}
But thats going to get OCC :-)
It's a stealth game, nominally styled after the Thief games, but I don't
suppose I'll actually import the mythology or anything from them. The
plan is to implement stealth in terms of shadow, learning guards' patrol
routes, and guard FOV+direction. At present, lighting is the only one of
those components that is implemented, although I've got guards that
wander around and a combat stub. My aim is to keep the game as simple as
possible. It will probably damage replayability, but this project is
largely intended as a way to come to grips with all the aspects of
writing a RL engine. I'll save the task of balancing a complicated game
world for the next one.
> Am Sat, 09 Feb 2008 00:48:04 GMT schrieb Paul Donnelly:
>
>> my programs don't have extra lines for opening or
>> closing braces, e.g.:
>>
>> (loop
>> (simulate-a-*WORLD*))
>>
>> rather than
>>
>> while(1)
>> {
>> simulate_a_WORLD();
>> }
>
> even in C and C++ the following is possible:
>
> while ( 1 ) {
> simulate_a_world(); }
>
> Would be the same with your LISP-Code in LOC.
Exactly. While the number of lines that actually "do something" may not
vary between Lisp and C, the actual number of lines in the program is
inflated by traditional C indentation, and deflated by Lisp style. My
idea is that there is some average ratio by which putting a C program's
braces on their own lines increases code size, and once this ratio is
discovered, it would be possible to calculate the number of "do
something" lines in a C program. In a Lisp program, any non-empty,
non-comment line can be assumed to be a "do something"
line. Actually, I suspect that if you were to adopt C-like style
for Lisp code, the ratio of brace only lines to "do something" lines
would be even larger than for C code (which is probably why Lispers
*don't* put braces alone on lines).
It's really a moot point. You can't compare LOC between Lisp and C (or
whatever) in any meaningful way in any case. I just think it would be fun to
figure out a collapsed brace conversion factor.
Well, a common metric for C/C++ is the number of terminal semi-colons,
plus the number of terminal curly braces.
Maybe an equivalent metric for Lisp would be some sort of appropriate
statement count, plus the number of closing brackets? (Since in Lisp
the brackets seem to fulfil approximately the same functions as block
delimiters in C.)
> In article <87fxw1m...@plap.localdomain>, paul-
> donn...@sbcglobal.net says...
>
>> It's really a moot point. You can't compare LOC between Lisp and C (or
>> whatever) in any meaningful way in any case. I just think it would be fun to
>> figure out a collapsed brace conversion factor.
>
> Well, a common metric for C/C++ is the number of terminal semi-colons,
> plus the number of terminal curly braces.
>
> Maybe an equivalent metric for Lisp would be some sort of appropriate
> statement count, plus the number of closing brackets? (Since in Lisp
> the brackets seem to fulfil approximately the same functions as block
> delimiters in C.)
Hmm, perhaps. I'm not sure how you'd come up with a statement count for
Lisp. The number of close parens might give you something like it, but
it wouldn't really be counting "statements" in the way that LoC in a C
program does. Compare:
x = y * z + a / b % c ^ d; // All one "statement".
(setf x (+ (* y z) (/ a (mod b (expt c d))))) // Six "statement"s?
That's why I figured I'd stick with lines as a metric, with the
assumption that one line does "one code thing" in both Lisp and
C. Modulo lines that only contain a brace, I figured a LoC comparison
would be a direct comparison of "lines that do things" to "lines that do
things". Not much of a comparison in any real-world way, of course. It's
just one of those things where my brain starts problem solving a silly
"problem" on its own.
>In article <87fxw1m...@plap.localdomain>, paul-
function1(function2(x,y),function3(x,y));
1 statement under your metric.
>Maybe an equivalent metric for Lisp would be some sort of appropriate
>statement count, plus the number of closing brackets?
(function1 (function2 x y) (function3 x y))
Well, there are 3 closing parens, and I'm not really sure what do you
count as statements, but it seems to me that these metrics are not even
remotely equivalent.