CORWIN: Okay. So I'm gonna start with my demo Emacs here.
Erik, we're ready.
AMIN: We are live.
ERIK: Okay, so you're starting then.
CORWIN: I guess I'll start right now. Here we go.
So I'm a Windows user, as we talked about yesterday.
I'm going to try to start Emacs for you now.
I've got it pinned to this thing,
but mostly what I actually do
is grab a file explorer and head to my desktop
where I have all sorts of Emacs.
Erik, can you make sure that your VLC is muted?
ERIK: Okay, give me a second, please.
CORWIN: I do. Okay. All right.
We should be working again now. My apologies for that.
All right. Handling technical problems in real-time
is what Emacs is all about.
As we're coding, we're constantly making errors, and fixing them,
and learning from the kinds of errors that we make,
and adjusting the editor to be easier to use.
So today we'll try to build on some of the ideas we introduced yesterday
around how a community can help us learn Emacs faster,
and how we can think broadly about the people in our team
when we decide how what kind of Emacs configuration
we're going to have going for our project.
So I'm just going to fire up my normal Emacs config now,
so that we get hopefully a nice pretty demo
or at least some slides.
For safety, we're going to avoid the server,
because I hate it when it crashes.
It's a little less stable under Windows, I think.
And well, while this starts up,
I'll just briefly introduce
my lifelong friend Erik Elmshauser
who's hanging in the wings and waiting impatiently
for us to be able to start our slides.
ERIK: Hello, everybody. I'm Erik.
CORWIN: So you've heard plenty from me already this conference,
I suppose, so I'm just going to...
So Erik and I have worked things out
so that he'll do most of the talking today.
I'll drive us through some code parts,
but the hope is that we'll just focus
a little more on the game.
If you have questions about the game at all,
please don't hesitate to ask those as well as your Emacs questions.
I think we're starting out.
Welcome. Let's cut away here so we can show some faces.
I lost you, Erik.
ERIK: Why would you do that?
CORWIN: There he is.
Let's just do one more thing
because that's just kind of offensive.
I'm going to kill off that cute wallpaper
we all were playing with yesterday,
although that's not so bad anymore.
Oh, that's terrible. It's got to come back.
I'm sorry, everybody.
Oh my dear. All right.
We just opened Emacs, so I have to open my slideshow,
and there we are.
Okay, Erik, I think I'm about as ready as I get.
ERIK: Cool. Well, let's begin here.
Welcome to the dungeon, everybody.
As you're aware, I'm Erik and this is Corwin,
and this is the Dungeon project that we've been working on
for about a year now.
The Dungeon game is based on
a tradition of gaming
that came out of the University of Minnesota
back in the 1950s,
as far as we can tell.
It is a predecessor, an ancestor of
most of the commercial role-playing games
that you have heard of or maybe tried out
from various stores and friends, what have you.
So one of the first things we want to talk about is:
What is it that sets Dungeon apart?
why is it... what is it about this game
that makes us want to continue bringing it forward,
when there are so many games already commercially available
that are descended from it?
Dungeon is kind of a simpler game.
Like we don't do a lot of the mechanics that you think about.
What is it that defines your character? Stats and skills and attributes?
We just don't deal with it in Dungeon.
But Dungeon... The simplicity of it allows it
to be a vehicle for creativity more than just a numbers project.
So that's kind of why we like it,
but also it makes it a tricky problem
when it comes to writing a computer game to mimic
the game that we played with paper and dice around a table.
CORWIN: So when we look at it as kind of a technology problem... Whoops...
When we try to... Heyo. I'm sorry. I got ahead of us.
I'll cut back.
ERIK: I thought we were doing fine
CORWIN: Okay, well then. I'll just... yeah. Either way.
ERIK: So we've been friends since...
It was our parents' idea, basically.
Our parents are friends, and we learned this game from our parents.
Specifically, I learned it from Corwin when I was 7 or 8.
CORWIN: Yeah, that's where... that's my cue in, right?
My folks and Erik's folks were really tight.
They used to run science fiction conventions together.
Our play featured imaginative role-playing.
Usually we would find ways to work the computers into things.
I don't know. I hardly have memories that precede Erik.
ERIK: Also, it turns out we're both kind of nerds.
I learned to program from my mother back in the early 80s,
and for as long as we've been friends,
basically we've also been into playing with computers.
Over the years, we've worked with many, many different systems.
We've played with Ataris, Apples, and Amigas
for a long time before either of us got PC clones
and Windows or DOS or Linux or any of those systems.
We went through all of them, and kinda liked them.
So we also always thought, like,
how is it that we can use these cool computers that we're into
to build this Dungeon game that we're into?
'Cause that's what you do, right?
CORWIN: That's certainly what we did.
So after some decades of bike-shedding
where we saw really a lot of changes in the technology field,
cell phones were invented,
smartphones were invented...
Text messaging in particular had a dramatic impact
on what we thought Dungeon would have to be able to do to be more fun
than scribbling in graph paper.
Yeah, either way.
ERIK: We've been using Linux since the mid 90s
I don't remember exactly when I did my first Linux install,
but I really liked it from the get-go,
and I think it was shortly after I installed it on a 486,
I went over to Corwin's house
and we spent a couple of months screwing around with it.
CORWIN: I'll add, I remember the day that I learned about the formation of GNU.
It had a life. I mean, I read lots of licenses.
I think a lot of us have written our own SWAG license code
and I definitely credit the formation of GNU
to my being interested in thinking about that.
Right. I am working the slides here. Okay.
Well. So yeah, this is your turn.
I already mentioned Jeff yesterday,
so your turn to take it for a few slides.
ERIK: Along with learning Linux, we started learning the various tools
that were available through the GNU free software movement.
It didn't take very long before we got into using Emacs.
When we were working as software developers back in the 90s,
we both were using Emacs in an office environment
with some other developers.
It was obviously a very powerful tool,
and we have really enjoyed using it for a couple of decades since then.
CORWIN: I'm not going to go on at length about my love for Emacs here.
So we put together a project.
Each time we rehearse this,
Erik introduces it with it's my story to tell,
but since our flow is already to hell
and we're just having a conversation with you today,
I'll just jump in and say from a project standpoint,
the project owes its inception
to a tremendous number of people in fandom
that encouraged us to just do crazy projects.
In this case, to our friends
that were hanging out with us on Discord all the time
while we played different games.
And through that, and while I was
fooling with Emacs,
generally other people played games,
the pieces fell into place.
We were all there, so we could talk about it,
and the idea got exciting again.
We started going back to all the places
that we had had trouble with it in the past.
It really did seem to add up.
We built proof of concepts to do hard stuff quickly.
I guess we'll probably head into that that area now.
ERIK: This slide mentions: Why build a role-playing game in Emacs?
I was watching the last presentation
and there was a slide about all of the problems
that Emacs poses for retro gaming,
where it interrupts the game loops and it waits for user input.
That was a whole list of reasons why
Emacs actually does exactly what we want in our project
and why Dungeon is a natural fit for Emacs.
CORWIN: Hey there. Yeah, go ahead and continue.
I just got a phone call, I think from Leo,
so I'm going to mute.
ERIK: So what we did in the project was basically
come up with our minimum play-testable candidate.
We listed all of the things
that we need to be able to make the project do
in order to recreate the Dungeon experience that we had
with paper and dice sitting around a
table when we were kids.
And, I mean, we've, you know, it took a while for us to kind of
tease apart the problem in a way where we could actually
list out all of the features, like, what are the problems
we have to solve and how do we solve them?
So, creating any free software, any self-organizing free
software project is challenging to start with, and we're
generally people with a bunch of other responsibilities by
the time we get to it. So, it's not just, hey, you know,
the general herding cats, it's, you know, trying to make it
a part of your life, too.
That being kind of a, you know, challenging battle, we kind
of aligned on some principles that we wanted to adhere to
once we started taking the project seriously.
Like, you know, particularly recognizing GNU in specific as
we focus on giving back to the community.
Taking what we learned as Perl programmers and, you know,
bringing that spirit forward into our work and maybe
specifically support, making sure that we can, you know,
write functions for the game in Perl if we want to.
And then to use the game as a vehicle to make people look
beyond the typically open source – sorry, typically nom
inally open source at best, generally pretty closed world of
computer gaming.
A lot of Windows users out there, a lot of non-free
communication tools, and a lot of, you know, a lot of
ground to cover from a free software perspective.
So what can Emacs do from a gaming standpoint to open that up?
And not to mention the hubris of the, you know, the two of
us with a few friends basically deciding to take on what
amounts to a huge project.
You know, we're essentially a year in now and we haven't
really gotten over halfway to our minimum play testable candidate.
It's a work in progress. We've got a long road to go.
There's at least 50 items on the things that we think are
critical to be able to introduce it to my younger kids, for
example.
Okay, so we're in the accomplishments section. So we're
supposed to be talking about the things that we have
succeeded in doing in our first year.
We have succeeded in working with data in org documents,
using org mode tables to store the data that we're going to
use in the various parts of our game.
And we've had a lot of success with svg.el. It started with
drawing maps and we have another talk about our mapping
specifically coming up next.
So we'll put off some of that discussion for a separate talk.
But we've also succeeded in getting into a bunch of
different elements of the game where we're, you know,
making a lot of progress using this drawing engine we
developed to also draw this other thing and also draw this
other thing and also draw this other thing.
And we kind of backed into, we've got this aesthetic
and we're using it to draw interfaces for all of the different
parts of the game.
So let's talk a little bit about what works now.
First of all, there's the mapping part that Erik mentioned
and we'll jump here into, we'll start opening up some files
and looking around.
But then also later we'll fire up an IELM and look at some
of the other proofs of concept.
So hopefully we can pivot the second talk more toward the
demos as we skip some of the interactive stuff that might
be mentioned in the slides that we go by.
Okay.
So, maps, visual battleboard.
The battleboard...
I'm just going to skip it Erik, we'll hit it in the next one.
Okay.
Hang on.
Okay, so I'm just going to go ahead and open up maps and
let you talk from the SVG process itself, because that's
the interesting part to me.
Okay.
Talk about the SVG process, like what do you think exactly
we want to talk about? How we turn our data into an image
or what are you hoping for?
Yeah, so I mean did you want to talk more from the hand-d
rawn SVG graphics at all?
I thought we were going to save that stuff for the pathing talk.
Okay, that sounds fine.
But we can go into it right now if you want.
Yeah, so we've got about 10 minutes before the turn where
we thought we would first take any questions that are
hanging out there.
I unfortunately closed the Etherpad, but I can open it again real quick.
Or you can jump into the pathing stuff now, or I can just
throw open an IELM and we can start the demos.
So let me invite Amin or Sacha back in, or Leo, if any of
you want to join the conversation and make a suggestion as
to how we balance between the remaining time.
The rest of what we have left starts in on toward the
technical, so especially if there would be questions about
the game right now, that would be awesome.
And I'm going to get seated again.
I'm not sure if I talk over the stream, if you'll hear it,
because I'm just watching your stream, but I can try writing on IRC.
Sure, yeah, questions would be cool. Or, yeah, well Erik,
why don't you just go ahead and start walking us through
the hand drawn SVG stuff just a little bit, because I think
if that isn't interesting to people, we can just preempt
for a question.
Okay, so historically when we decided to actually start
writing code, one of the very first things we wanted to do
was the maps, because initially it seemed like the maps
were going to be one of the biggest challenges in terms of
how do we get a text editor to draw pictures for us.
So, we pretty quickly decided we wanted to work with SVGs
because it allowed us to leverage the power of Emacs as a
text editor and a text manipulator to write text graphics
with the SVG format.
So we did some SVG graphics by hand, we went in and just
started hand coding things that looked visually like the
maps we used to draw by hand on graph paper when we were,
you know, sitting around the table.
Yep, absolutely.
What emerged from that is as we started working on some of
these files, this particular image is a test of some 20
wide water with some beaches around it and a special
chamber kind of off to the side called a clapper.
And this was the way we would code is by sketching by hand
all of these things to look right. And then we would take
that code and we noticed it became real repetitive as we
would go like chunk of water chunk of water chunk of water.
And we're like okay so what we really need is to define a
set of, we call it tiles, but like you can think of it as
rubber stamps where we write this graphics code, and then
we're able to repeat it in different places around the map.
You want to flip over to code view and show that or do we
want to move into. Sure.
Code view.
So, you know, you can see just really obviously here the
only thing that's changing from chunk of water to chunk of
water is the x and y coordinates.
And, you know, we can skip getting into the SVG directives
and how all of the path statements actually work, but you
can trust us, all of these D equals and there's m's and h's
and V's that turns out to be horizontal lines and vertical
lines and cursor moves
kind of like turtle graphics if anyone remembers that far
back, and we're picking up our pen and dropping it and
drawing lines around on our map.
Okay, so we do have a few questions if you want to take
them now otherwise we can also jump in.
Let's get them while they're fresh. Okay, sounds good.
So we'll probably shift to question and answer mode for up
to 15 minutes here. So if you do have questions, maybe
stack rank, go ahead and sort the questions a little for us
or comment on them to let us know which ones you want to
see us get here if we start getting a little long winded or
not just a long, we'll take direction.
But thanks for your questions.
I'd like to see a demo as well we'll look at that with the
remaining time after this question block.
More about what the game is okay sure. So let's let's take
our one minute each swing at what the game is, you want to
go first, I called weapons.
Okay.
Dungeon is like role playing games, but you don't really do
role playing like the, for me the thing the core of being a
role playing game is you take on the role of being your
character and you play your character and dungeons not like
that dungeon.
You can play.
So, the dungeon party always has eight characters in it.
There's four in the front row and four in the back row and
you march through the dungeon, fighting, whatever you encounter.
And if there's one player you play all eight characters.
And depending on how many players you have you split up the
party in whatever way seems fair and equitable to everybody.
And similarly I said the dungeon is kind of a simple game
like there's only three races and there's only three
classes, all of your characters are either human elf dwarf.
They're all a warrior, a priest or a wizard, and all of
these characters have, you know, special properties and
special talents, that is why they come together in this
party of eight.
So essentially dungeon is a game about making up all of
these eight characters and stomping through the dungeon
killing things taking their stuff.
Well you're way over but I don't know how much I have to
add to that. I will just add that if, if you're.
If one's passion as a dungeon master is killing player
characters this game is meant for you. You don't have to
build your game like that. But that's definitely a thing
that people do with this game.
And then as Erik said, it just encourages you to put your
creativity on the table to bring all the different elements.
Hopefully, this may be clear in our slides since we were a
little fumbling for the first few minutes of the talk
but there's also a kind of a player's guide that I started a few years ago.
That's not super complete, but does cover some
of the high level basics of the game that Erik's been talking from.
And I would add that some of the things that you know some
of what makes dungeon great is that there's a lot of
mystery about it, like the player's handbook doesn't tell
you all of the rules, or like any really mystery and like
there's mazes and there's puzzles,
and you have to figure out how things work, and like we've
got all of these treasure items in there that could help
you deal with a particular monster if it occurs to you to use it.
And, you know, like that. There's a lot of.
You don't know what's going on you're dropped in the middle
of this situation and you have to try and survive and level
up and figure it out. And if you succeed in doing that for
a long enough eventually you start realizing that there are
big picture puzzles that there are, you know, there is more to this than just
killing things and taking their stuff.
And that's where the joy of designing these games comes in
for me is like designing the mazes and designing the
puzzles and like, oh yeah and then they're going to come
out of this room and you know what they're going to do.
They're wanting to go that way.
So I'm going to put the trap right there.
And I walk right into it every time.
And then when the party does get in your map
and they do exactly what you thought and they hit the trap
it's just really satisfying
to watch the look on their little faces
as they squirm and struggle to stay alive.
Yeah, that's, that's what I was trying to get at. Thanks.
All right, that was perfect for me. All right.
So so highlight your question for me if you think it's
important we grab it here before we jump into demos,
but otherwise I think it's time to try running some code.
Let's say.
Okay, I say do it. Okay, so you less less camera more more emacs now.
And hopefully I could find the right emacs the right
desktop. All right, there we are.
So we'll try to fire up
a command right now. And I usually like to do the full path to emacs.
When I'm going to run it under minus q.
All right.
Let's have some IELM.
All right, and then I'm also going to do a load file on the
net script that you can find in the repository in the emacs
user and it's init scripts
users folder
nice.
And it's called init-dm because that happened to fit with
my naming scheme, potentially terrible.
All right, and with that loaded in theory some very basic stuff will work
even without us doing anything in IELM
so I think the last thing Erik was talking about
was the SVG code behind the maps.
There as kind of the technical thread so we'll just fire
open the maps, pick a dungeon level.
Let's pick a pretty one.
Okay, if I show this.
Yeah, whatever.
Is that the surface. Yeah.
And let's scale it here I think if I recall that fun like
once, once we got the engine up and running a little bit.
We decided to do some experimentation about seeing
what we could do to push the limits of our tile engine.
So we more or less on the surface map, I basically started
with almost no tiles from below like the water
and the beaches and the general store and the stairs were existing tiles
but then we were like this is going to be surface maps.
We're outdoors so I want hills
and I want trees, and I want grass, and it took a little
while playing with SVG to come up with some acceptable code,
but once the like the grass gets tiled out, it kind of,
you know, gives the illusion of grass, and, you know, these
are all in my estimation
of crude graphics, but we're at the proof of concept stage,
and it definitely proves that we can use our graphics
engine to decide what we want our maps to look like, and
real quickly compose new map tiles and stamp out a bunch of
new maps.
So now I'll show off one of the other things. So the next
thing we did once we once we had the maps doing, and we
haven't gotten into the features of the maps we can we can
appoint time to that or not, but there are a number of
features there that we can look at.
The, we then wanted to try to see if that could make other
interfaces more appealing so we built stuff like, that's
going to be the map again.
I'll just run it here through I am so it's more obvious
what I'm doing.
So let's look next to the character sheet.
Oops.
And alt P doesn't work. Okay.
That's a bummer.
That is not auto loaded.
So this, this project is a bit of a mess right now, y'all,
it does some stuff that's really exciting to us but the
code is terrible and we need all the help we can get being
told what our problems are and how to fix them.
So that is if you take nothing away from this talk.
Take away from it that we could use your help.
Yeah, that doubles back to when we were talking about
Larry Wall's cardinal virtues of programming like we definitely
took on some hubris, thinking we could do this.
We might not be wrong, but we could do it easier with more
hands, you know, many hands make light work. All right.
I'll bite.
Yeah, and the character she won't load for us today I had
some problems with my version control I had to revert my
thing I threw all my local changes in a stash and it's it's
a terrible mess let's look at stuff I tested already today.
Before you got the battle board available.
Let's find out.
First of all, the library.
In fact, actually, your basic require should work.
No.
You can try a load library. You know what, let's, I'm just
going to go ahead and give it to you as a lab beast, since
that's probably more fun to watch.
So we'll take it from my own and this is more likely to be
healthy.
Since only some of the time.
First we have to control x, all the IDM.
All right, and having then loaded the net control you have
nine should give me the maps, and we can verify things work
in a basic way just by changing level.
Let's look at something else.
I mentioned, there were a number of bindings, show them
briefly.
We wrote our own functions to handle movement. Some of
those in SVG dot el the left, left and right movements
didn't seem to work quite quite likely coding, of course.
Um, all right, enough.
So let's, let's see if battle board works now.
I really thought that was on F7.
Up that's the character sheet suite.
Okay, how to use your bindings.
So that looks a little better.
So let's talk about the character sheet.
Yeah.
So the character sheet was our first big repurposing of the
engine that we couldn't do the battle board program that.
Let's see if that runs now to.
It's not interactive if it does.
Good.
So,
try smex guess? No joy. All right, I'm not sure what's
up with the battle board Erik.
We haven't messed with that one for a while in fact we had
discussed using its code as an example so maybe we'll debug
it with you.
I'll certainly check for questions first.
Um, the. So the character sheet which is not scaling
ideally here.
See if reloading it does anything.
Nope.
As far as I can tell, assuming you don't have this
implemented character sheet.
That's right, there's everything in scale, it take in order
to get what you were looking at there.
All right.
This, this whole thing is hard coded, basically to the
gills, except for things like this.
This program represents a re implementation of the drawing
engine using all of the same things. Let's see that
selected so
we'll just try bringing up a map again.
There's one and you'll notice DM map doesn't know anything
about the new draw engine, and there are a couple of places
where the new draw engine is still hooked in to the.
For example, particularly the sizing of the graph paper
background. So I've started the work in DM draw.
Of trying to show how exactly we did this removing the, how
did we get data out of org mode that I talked about
yesterday with our ETL flows, and just focusing on what how
did we solve the problem of predicated drawing, which I
realized we didn't really talk about so should I jump into
that.
Yeah, I guess.
How are we on time, we have time for detours.
Um, yeah, it looks like we could spend two or three minutes
on that and then come back for the questions.
Cool.
And I'm just going to peek into my org mode into my chat
conference and I don't see anybody talking to me from the
organizer channel, so I'm gonna assume that's a good guess.
All right, so let's go ahead and play with the map a
little then that is pretty fun and so much fun that we
had to curtail play sessions in order to keep working on
the project.
So, I'll, I'll do the.
Um, we'll try to find something different from any gift
I've shared here right.
So here we are in a random. Go ahead, Erik, you feel.
Okay, so what we're, what Corwin is doing here is he's
about to put the map into play mode, which is going to turn
on the fog of war.
And then we're going to use the fog of war and the, the
play mode to kind of reveal the map, one square at a time
like we would during a play session.
So we'll just drop the party randomly somewhere onto this
map looks like we're on alpha maze level three here.
And then we'll walk around a little.
Okay, so we're halfway there. I'll have to, I'll have to do
a full redraw the sketch the sketching stuff has has has
broken things here like I said, the two aren't separated
once I run them in the same instance, they're not
predictable.
Okay, so let me elaborate here when he says the sketching
stuff. The current focus of our work is to turn all of this
map stuff we've got into a basically a WYSIWYG map editor,
where we can get into the tiles, and we'll be able to
select the tile and basically rubber
stamp it into a map graphically, and then save the map file
out and load it back in later, so that we're able to just
pound out these maps real fast.
Using a graphical editor rather than having to hand code
every symbol and every square of the tables.
So the process of doing that.
I hate them on things are a mess we've got covers off those
wires hanging out different stuff works on different days.
Well, I will say in our defense this is exactly why we
staged a complicated thing, and probably we should have
just gone with that instead of trying to give you the
experience of, of what it's like to use Emacs to do this
which is sort of the last
thought there and my apologies for that if that's made it
harder to follow the thread. Let's check back now for
questions and see if anybody wants to redirect at all.
Oh yep, this. So what you're looking at all uses
progrmamatic SVG generation for question number four there,
have you played with generating SVGs programmatically in Emacs.
That is what the maps are doing in terms of
being more explicit about that we started hand coding
things and once we got the, the idea of what the code was
going to look like we switched to doing it programmatically.
So, we were going to open up maybe now we've got time we
can get into the tileset real quick. Sure, we definitely
didn't do any of the pathing slides and so now we've
skipped over some stuff we were going to present.
Yeah, that's right we skipped a whole bunch of slides and I
can certainly go back to them they're open here obviously.
I'm right I was just showing off the sketching tool,
briefly in that context but I think you're right, let's, we
can jump over to the actually I should finish with this now
having teased it.
So let's do the same thing here Ctrl H M, and you'll see in
this case there are very few key bindings that are set up.
This shift delete has a terror or shift with a control
delete, it would seem to be. So that has a couple obvious
bugs with it right didn't pick it didn't pick up those
control points until I reuse them not clearing that stack.
I think we can also should probably think about whether the
origin should return and hey marking that origin would be
nice. So there's a tremendous amount to do here this is
just showing that it is possible to use, essentially like a
touch input to,
yeah, and then also we can switch over to our place tool,
and hopefully we can get a nice big menu of all the tiles that
Erik prepared for the game maps.
That was probably a terrible choice but there you have just
a bit of corridor right.
That looks.
And even the click.
Yep, and this click action here is the last thing I
was working on before I dropped everything to build the
decks that we will soon share for this conference.
So okay, back to the tile sets.
So the way we approached drawing it programmatically is we
broke our code up into little snippets we called tiles.
And so this is where I was going to open up the tiles out
here, basically each tile has a name, and then with that
name we place data into different layers of the image.
Some of the layers are just SVG paths, and the data is just
SVG commands, like we saw in that handwritten code, and
some of it is compositions of other tiles, so a tile can be
made up of other tiles.
Furthermore, some of these tiles have conditional code in
it, where like some of this stuff is talking about elf and
bang elf.
So the map is going to be drawn differently depending on
whether or not there's elves in the party.
So, and that's the demo they broke.
So the engine has to make all those decisions.
And that's what we're calling predicated drawing. Oh, there's
a special room here. Do you have any elves? You do. So I
draw it the "there is elves" way.
Yeah, so we built up the set of tiles, and then we
basically made map files, which take our map and break it
up into XY grids, and then we drop these tiles into
positions on the map.
So we can use the same tile square after square after
square. When there's a corridor north-south, it's the same
tile over and over again. And that makes it easy to reuse
the code.
And also, when we go to present the -- what am I trying to
say -- the drawing in fog of war mode, as we move down the
corridor, we can just add the necessary code one bit at a
time to the visible image, so that what we're displaying
doesn't contain any data except what the party has already
discovered.
And thus we have kind of spoiler-rich documents sitting on
the GM server, and then less -- and spoiler-free data that
flows down to the org mode files on the player system.
And the only real challenge is making sure that nothing
that the game does can mess with the users -- the players'
data file, in case they might have their own notes and
things in it. That would be the one, you know, number one
thing to avoid.
Another thing we can talk about here is that there are
layers. You can see this table at the bottom has tile and
overlay. The overlay column is just going to contain some
actual SVG XML style tags.
So that's where we can add whatever text elements or other
SVG, like raw SVG tags we want. Whereas a lot of the other
layers are going to be like path layers, we've got water
layers and beach layers.
And our plan was to have a style sheet that defines how
each of those layers are represented. So like when the
water gets drawn blue and it's got arrows on it giving it
direction, all of that can be customized with a style sheet
to change the water to be whatever you want.
And like we have beaches as yellow, but maybe you like
beaches as red or, you know, whatever.
So we also built some test programs and various -- I'm not
sure what kind of shape we're going to find these in, but
we can try running them.
Here, for example, is just a very basic -- using the same
file to define the tiles and then the layout, so to speak.
Oh, look at that.
There's the layout. Okay, so that actually looks fine. Tile.
And it's path. So this is defining a tile named "seas" and
it's going to have a list of tiles defined above.
And you'll notice also that we can just sort of freely
define and redefine and it sort of figures out, oh, this
must still be part of the B row.
We could also have done this.
Okay, so this would work as would this.
>> Early on in development when we were talking about
getting data in and out of these org tables, it was kind of
a priority to us to leave the way the data is organized
open to the users and to the dungeon masters.
So while we set our tile set apart from our map sets, this
clearly shows that you can cram a tile set and a map into a
single file.
So in situations like the surface where we're using
different tiles from other maps, maybe it makes sense to
move, you know, those tiles just into the file with your
map.
But we also wanted to make sure, like, it's hard for us to
predict how other people are going to want to use this when
they design their games.
So we wanted to leave it as versatile as possible about how
you can use it.
>> Where it matters, right? Not support every feature in
the world.
I can't count the number of times I said, Erik, Erik, Erik,
hey, if we do it like this, people will be -- and he just,
like, does it have to do that?
Like, do we need it right away? Do you have to really
rewrite everything so it can all do that?
And a lot of those conversations, too.
But the key flexibilities are really there.
People might want to use a lot of different files.
They might want to lay the tables out however they want.
They have to be able to say, hey, this is a table that has
data that's controlled by the game, and everything else in
the file is not the game's problem.
>> And our table, some of our tables started getting really
wide, so we started striping the tables.
We'll repeat the same table over and over and over again to
get all of the columns in there without making it, you know,
a million miles wide.
>> Yeah.
Do you want to -- should I go ahead and pull open, like, a
level here, do you think?
>> Sure.
>> Just to have shown it.
>> The file set's a great example of striped tables if you
look down, like, in the level change feature.
>> Oh, sure.
>> Sorry, I'm not quite sitting well to my keyboard here.
I can just readjust things real quick.
So what, you know, you can see here, like, some of these
tables got real wide when we're stuffing SVG tags into them.
And what we -- oh, maybe it's not in these.
I thought it was.
It's special, probably.
>> Yeah.
No, there it is, yeah.
It was in level change.
It does the table key repeat.
>> Okay, great.
>> You were just scrolling up and down so fast I didn't
realize.
So this first table, we've got path and what is that,
stairs?
So the stairs level is one that draws in, like, a pink
color to highlight places where you can change level.
And then if we scroll down to the second half of this
section, the second table is going to have all of these
same tiles in it, but instead of path and stairs, we're
going to have other columns.
Can we see the next table?
There we go.
So the same tiles, only here we've got overlay,
documentation, and behavior.
And I guess we haven't talked about this at all.
The behavior column was our concept of a way that we could
attach functions, basically, to these different areas of
the map.
Because sometimes when you enter an area, we want it to do
something.
Like when you enter a stairs down, maybe we want it to
change to the next level and draw the stairs up behind you
and draw you where you are on the next level.
So these are like hooks where we could attach functions or,
you know, macros or whatever to make the map have these
behaviors as we get further towards automation.
Cool.
So that's that should be pretty close to our time.
Questions or just say goodbye.
Yeah, so there's the I'm sorry we couldn't show it earlier.
There is the battle board.
And so this is used just to keep track of hit points.
So with this example, battle board, dm battle board.el,
there's there's a complete example of not only in a single
file reaper, we filling out the tell the cells and the
tiles, but then coming in and keeping the org mode file in
sync with with clicks.
So, and I can press the star key and set my damage to minus
one and take the damage back off.
I just haven't spent a lot of time building up fancy bind
ings for this, you'll also find that the crew probably find
how I figure out what was clicked on in the code hard, but
if I just assign something recognizable for damage, and
then come into.
It will now have opened the org mode file behind the scenes
because it's changing it.
And we can then look at that file a little bit and
hopefully that is on large enough you can kind of see there
's our 17 damage landed in armor.
The logic that sits behind that to figure out the part of
the screen is not necessarily our finest work.
But it does work and that's one kind of stuff was used on
the map a little bit too. We didn't really get to show that
in the demo but as you're scrolling around there's like a
highlighter that that, you know, we were drawing on.
Oh sure, show you which square you've got selected.
We were having trouble with that code. Initially, and we
were sometimes revealing the wrong.
Okay.
And I don't know how we're set for time but I just saw a
message from Trixie that she could jump on if we want her.
Oh, that would be amazing. Yeah, go ahead and invite her in
I'll just cut to the scene as soon as she's in.
I think.
Yeah, so we're reaching the ask me anything portion of the
program here with what, with what time we have left for
your questions.
Please correct me if we're still like 10 minutes, you know,
if we're, if we're more than like 15 to 20 minutes from our
time but I suspect we've left way left way less than that
and out of respect for all the other presenters.
I don't want to close that actually.
I think I may have found an old version of my slides that
can have some good stuff.
It's been an event for a couple of weeks here I had a break
in and my somebody got into our bank accounts and nasty
business, just a lot going on over, over this whole year I think.
Any more questions to share.
Sure. So, I think there was at least one we deferred a
little bit with the game is
always eight characters that can be divided right that's so
always eight characters that can be divided between the
party is the classic formula, it actually works pretty well
for a conversational group.
I think the idea that role playing games are about talking
to each other and being good at them is about taking
excellent notes. So, when you're sitting around with a
group of people and you're going to have to wait for them
while they dig through their notes and listen to all of the
things they find interesting to say, and try to reach an
imaginative place that you can stay together.
And when you're doing all that and working in dice and
remembering the rules. It's actually a complicated activity,
I liken it more to a bridge game, then to like, you know,
part cheesy or perhaps even like risk or access and allies
or other games that have have definitely the strategy to
them but I don't.
Erik, your thoughts.
I think that's fair.
You know yes definitely. The, the tradition is to always
have eight characters in the party, and, you know, one of
the great things about dungeon is that everybody who writes
their own dungeon gets to write their own rules, and is
free to change whatever you want.
I've definitely seen people try to take on challenging that
always eight characters in a party thing.
I've seen people take approaches like every player gets two
characters and then you can have a party ranging from two
to 10, or there's always going to be 10 or there's, you
know, this or that or people have tried stuff, and none of
it has really worked out very satisfactorily we always seem
to keep coming back to our party of eight.
It's, it's one of the things that dungeon that you can't
change when you write your own dungeon. And that's the
reason it's so complicated as a, as a software project why
it's taken us decades, because trying to model the data for
example or really any attempt, quantify it in specific
terms always falls to examples.
You know dungeons usually have elves, elves, dwarves and
humans. They have priests, wizards and warriors.
They have eight characters in the party. The Balrogs are
particularly nasty and live in a room of some specific shape.
And they have spoilers.
So let's touch on special power real quick since that's one
of the things that is kind of unique to dungeon. And one of
the things that is the biggest challenge to us and trying
to code a system like this for automated play.
And that's that every character gets a unique special power
and traditionally you negotiate your special power with the
dungeon master when you create your character, and
occasionally throughout the course of the characters life
their special power might change due to game circumstances,
usually it improves but sometimes not.
So those are the most fun conversations right sometimes we
have fun gaming sessions where we barely get all the
characters created and started, because we get off into
arguing about the special powers no Zelda special powers
obviously the candle Come on.
Also that was like, not so.
I still have my t shirt. Hey, there she is. Let's cut scene.
I'm going to be working with fun filters today, because
that's what we got going on over here. All right, I'm going
to recut everybody hang on tight.
All right, there's Erik.
This is going to be Erik for a second home.
No worries. And welcome to that welcome to the stream. Trix
ie horror.
Who is one of our project team members somebody who's
learning Emacs as part of the project, and.
Yeah, I particularly wanted to invite you on to talk about
your experience learning Emacs I think you have run into
places where it's a pain in the butt to learn Emacs and that
this is a safe space to talk about that.
I'll jump in by saying the Emacs cheat sheet.
I think it's the one that can do puts out is a lifesaver.
I think there's a little bit of a vocabulary disconnect,
like, and this actually kind of comes up a lot in
conversation with Corwin and Erik and I, but coffee paste
versus what yank and w, whatever w killing yank.
Yeah.
Why would you even do that to us right where where were you
when zeros park happened. No, I understand that makes sense.
What else.
I mean you don't have to sit here and rag on Emacs but we're
here for that. That's all I'm saying.
I think that's the biggest thing, like, I'm, I'm used to,
like, just kind of the very binary nature of like, nope,
that didn't work, try something else.
So, as long as you're willing to try other stuff like Emacs
will be fine. So, it's a tough cookie it can take it.
The only thing that happens is you have to install it
through your file that you hopefully have a backup of.
Um, are there more questions in the hopper.
If anybody does have any questions up there for hope for
Erik or I so just to summarize, I've known Erik, I've known
Erik, my whole life, I've known hope around a decade we
work together on a project for, for a science fiction
convention.
Yeah.
I've written a few conventions and then I also helped with
I just wrote a bio. So this should like all theoretically
be in my head right.
I want to refer to my own bio project coordinator for
dungeon mode.
I was a bird assistant good credit.
And family friend to the Bruce. Oh,
yeah, we've gotten a ton of support from a lot of our
lifelong friends people, and also people that we just met.
Maybe that's a that's a great segue.
Do throw your questions in there I'm going to fill for just
a second and then we'll probably cut away.
But, I'm thinking thematically actually, that's that's too
abrupt so we need to go around the room, Erik you had hours
and hours to rehearse hope kind of jumped in on the last
minute.
So let's let's, is it okay to pick on you or do you want me
to get mine.
What are you asking me to do what do you what do you want
people to take away from this talk, you know, as we think
about dungeon and sharing it's sharing its tradition, as we
think about learning Emacs, and like making that awesome.
And just, you know, generally what's up with free software
and trying to make computers a tool to make people freer.
Yeah, I'm going to ask like five questions. Yeah, so just
jump in.
I think that dungeon is a lot of fun. And, you know, I'm, I
've played many commercial role playing games over the years
, and I've enjoyed all of them.
But there's very few of them that I've had as many belly
laughs and as much just joy, playing as from dungeon. And I
think, you know, the magic of it is, you know, like any
game like the real magic is the people you play with and
having fun with your friends.
And what I would hope that people can take away from is
that dungeon has the ability to be that magical thing. And
hopefully we can get our project to the point where it gets
out of the way and lets you have that fun with your friends.
So I think there's a lot of work to do we could use some
help. So if you're interested in having fun. Come help us
build this fun tool.
Alright so I just got the call that we've got just about
two to three minutes left, and we should start our wrap up.
Wrap up.
Yeah, so I'll see if I can charge the room with some energy
unless you're ready to have that at home.
Here, here's, here's what I want people to take away.
Were you like, No, okay.
I'm not getting your audio hope.
So my end, maybe I just need to speak up.
Is this better, let me know when I'm coming through.
Okay, cool.
I was gonna say go ahead.
I didn't. Okay. I mean I don't know that I know what I want
to say either except a whole ton of thank you. So, I will,
I will save those for the, for the literal end here.
And instead, what I would say is, as we build our amazing
innovations and explore our ideas in Emacs.
We are fighting our own ego for the will to get them done,
it's hard and we're not sure if they're going to be a good
idea and will it excite people and part of our
responsibility is to excite people so that they can feel
good about liking them.
If you come off and you're like hey this is a terrible idea
it's really hard to be like, no I love that idea works
theatrically but in larger groups may not scale.
So that's a crucible for ideas and a crucible for teams.
The first part is definitely healthy. The second part,
there's a lot we can we can do, you know, having a front
and and and good faith conversations on that subject.
Anybody else want to want to wade in after that sorry that
that was more of a calm down than a fire out.
Okay.
I think.
The first part of this but I think we would be remiss not
to highlight org mode, a little bit. Yeah, like, that's,
that's our bread and butter. Yeah, our whole project is
built on org mode.
Right. And I'm just really excited because, like, I have, I
don't have ADHD, but I have like something similar. And so,
like to know that there's something that exists, that is
like purely hierarchical.
It's incredible, like I can just run a report, basically
and get all of my like to do lists that I didn't have to
put in one specific place.
And, like, that's kind of been a complex issue for me of
like, okay, I have all these to do lists, like in Google
Keep or whatever like what do I do with them now.
So being able to like pull them into one list.
And then recycle through them is really incredible.
And I think taking dungeon and like using it to like
combining it with org mode basically really.
I'm excited about it and I'm excited to see like what it
can do for player groups.
Especially now that quarantine like I was excited about
dungeon mode.
Before the pandemic and now like I'm only more enthusiastic.
So, yeah, definitely the pandemic has been the greatest
thing that happened to this game, terrible terrible as it
is to say that it, if we needed a hobby and it turns out
role playing games are are really good.
So, so I think that's probably about our time. I'm guessing
that's my call. And thank you very much.
Thank you everybody will be around for discord and stuff
later come catch us if you want to talk.
Okay.