It's easy to see all this literature and become discouraged.
It's easy to see all of this analysis and think, "wow, I don't
understand even half of this -- how can I make a proper start?"
So I think it's useful to take a survey of these ideas to inform our
own -- but my example is Sal Khan, who put his head down and recorded
one video at a time.
Anyway. For me, the key open question, for right now, today, is this one:
Do we continue with Akihabara, or do we move forward with another framework?
That's what I'm working on today and through the weekend: comparing
and contrasting Aki with the other tools mentioned. I will share
notes as I have them.
--g
How many of them allow users to edit the source?
Not very many. In the Flash era, almost none. That's the opportunity.
> Question: would any of the RPG frameworks allow you to make use of
> widgets like widged has listed? If so, that would multiply the options
> of the game, while cutting down on development time.
Maybe, maybe not. Don't know yet. I think a key goal is to have
mechanisms to separate content from presentation, and in-game widgets
that can drop in content from anywhere. Puzzle libraries that take
question-bank data and transmogrify it into fun puzzles in the gaming
environment.
> Question: In your multiples of 5's and 3's example, what if I don't
> get the concept? What if I try 26 and 19 and 4, and after 5 times
> still have not picked the right combination? Does fixing this matter
> in the choice of a framework? Or do the type of kids who love RPG not
> care about getting such help..i.e. its the repetitive negative
> examples that makes the game good for them?
It's a good question.
One potential long-term advantage: instrumentation and sending data to
the backend. "Does this puzzle just suck? Do most players get it
wrong? How long does it take for a player to get it right?"
My sense, though, from watching kids play a lot of games: assuming
it's not so impossibly hard that they shut down, they'll keep trying
until they get it right, especially if getting it right stands between
them and completion of their quest.
--g
Sure it does. If I get the time to focus, I can turn around a
perfectly playable, self-contained, useful game in a week. If I find
10 people like me, that's 2 new games a day. :)
> Software like MissionMaker have been around for 5+
> years. Yet, their adoption has been very limited. For instance, in NZ,
> they ran a pilot in 2007 and dropped it --
> http://www.core-ed.org/portfolio/using-game-based-technologies-to-support-learning-mission-maker.
So we'll try again. :)
Also: MISSION MAKER COSTS MONEY.
I can't overstate the importance of a development environment that's
open. It means that your potential development audience is "anyone
who's interested in playing around with it", not "anyone who's
interested enough to spend money."
> The major issues were : "Of these the technical and infrastructural
> issues received most comment, and included experiences with hardware
> that was not powerful enough to run the software, difficulties with
> having versions to use on their personal laptops at home, lack of
> facility for exporting finished products to run-time versions, coping
> with version updates that occurred during the pilot and the lack of
> ability to import graphics from other applications." A framework like
> Akihabara would present similar difficulties.
Well, let's see.
* "Difficulty running on personal laptops." It's HTML5. Early
adopters can all run HTML5, and we can safely assume that everyone on
earth with a computing device will catch up.
* "Lack of facility for exporting finished products to run-time
versions." Yes, we'd need an uploader for participants, but the fact
that it's all just HTML5+JS, and can actually run on a local computer
practically identically to how it runs on a server, is a potentially
significant advantage.
* "Coping with version updates." Yes, this is potentially a painful
problem. Always.
> Waiting for a chance to read your "vision" document. My own
> understanding is that if your goal is to encourage more teachers to
> look into gaming, then you have to build bridges.
No. No, it's not. My goal is to *write some games*, and then
encourage people to *play the games*, and make it as easy as possible
for people to say "gee, I wish the game would do this." And then have
a bunch of people who can say, "yes, we can do that!" Or "no, we
can't do that yet."
To the degree that the teachers play the games and say "do this not
that," then getting teachers on board will be a big win. We don't
have to make them coders to make them useful participants.
> Most teachers would
> feel lost, not knowing where to start when about to create a game like
> that. Make it as easy as possible for them to author their own
> content, without having to deal with the technology. Provide key
> knowledge they will need to be successful in their new activities. Let
> them start with concepts and approaches that they are already familiar
> with. Something that could help is a book similar to flash games
> university -- http://www.flashgameu.com/ , but for javascript / html5
> (you won't see mainstream users invest in html5 before another 2
> years), more focused on how to adapt the code to change the content
> than how to write the code, and with information about game-based or
> game-like learning activities design.
What you say all makes sense. To me, though, the key problem is
sprinting to get some open games that illustrate the core concepts:
* Free to edit any way you like, the open source way;
* Crazy cross-platform;
* Small enough to make that editing a non-impossible task for someone
with moderate coding skill;
* Aligned to bite-sized curriculum pieces;
* Fun and based on the notion of "levelling up".
I think Akihabara is good enough for this. It's not the only tool,
and it may not even be the best tool. But it's certainly good enough
to get started -- and the time to get started, for me, is right now.
> For me, I do have a focusing tool. It's very different from Greg's,
> but it does limit my applicable choices. It's "What potentially
> contributes to public school Assessability?"
>
> IE, what patterns are transparent enough that they have a hope of
> helping demonstrate that a child actually is learning what she's
> supposed to?
>
> In that sense, an RPG (for the foreseeable future) parallels a video:
> its a learning tool, but not a candidate for assessment. Whereas, an
> online multiple choice, true-false, fill-in-the-blank has hoops to get
> through, but directly maps to a paper-and-pencil tool, so its future
> is probable.
Oh, I completely disagree. It's an excellent candidate for precisely
that kind of assessment, and I'm shocked that no one has figured that
out yet.
Why could a game not involve a "boss puzzle," wherein Our Intrepid
Adventurer must negotiate a series of rooms that ask questions, and
those questions are drawn from massive open assessment banks?
Answer wrong, BOOM! Lightning bolt hits you, -1 health! Your health
at the end is directly comparable to a score on a test. In fact, one
can go so far as imagining submitting the score data to a Moodle
server. But it feels *completely different*.
Will schools accept this metaphor? Until examples exist in a way that
is tangible to them, how can they?
> My interest then is in the sphere of patterns which have a near-term
> hope of joining with the old standbys.
I suspect we're not as far apart as you think.
--g
LOL.
So this is the difference between what I call "low-stakes assessment"
and "high-stakes assessment". And school systems are so obsessed with
"high-stakes assessment" (will our scores go up? Will we get funded?
Will I keep my job?") that they have absolutely no incentive to pay
attention to "low-stakes assessment" (did the kid learn something?)
I want to avoid the "high-stakes assessment" discussion for as long as
possible. I can see it from here, but I'm not willing to deal with
the moat and the piranhas and the quicksand. Yet. But the low-stakes
assessment -- which really serves as a mechanism to unlock the kid's
next quest -- is absolutely at the heart of what I think we should be
doing here.
--g
> There is no real difference between a paid iphone app and your open
> source RPG if users don't have the option to modify the content. It's
> open in theory but closed in practice.
Yes, completely agreed about this. If we can't ultimately present a
simplified interface for "adding quiz questions" or "adding a room
where a smart NPC presents content X," then we're doing it wrong.
We'll get there, but we've got some other things to do first.
>> * Aligned to bite-sized curriculum pieces;
>
> Can you easily open a window with custom content in Akihabara or
> temporarily replace the game screen by a custom screen, one out of the
> RPG logic? It really is not unusual in games to have a different
> screen layout for fights and challenges. That would give more
> flexibility than having to step on tiles to mark answers.
There are a lot of Aki forks on Github that are doing this: using
jQuery to pop up modal windows. I really need to look into this, from
a number of gameplay perspectives:
* Creating a shop to allow the character to buy things.
* Presenting a popup video to a player.
* Incorporating widgeds into the gameplay experience. :)
> You can then isolate activities from game genre. To use always the
> same RPG format is likely to be boring. Expressing problems in a way
> that they can be played in different interactives is a plus. If you
> isolate activities from game genres, you can then more easily
> integrate activities from other projects, like the Khan exercises --
> https://github.com/Khan/khan-exercises
Yes, I agree with this, to some degree.
For me, the central question that trumps all other questions: How
easily can you fit element X -- whether X be an instructional video,
or a game element, or something I haven't yet imagined -- into the
narrative structure? Because that's where RPGs absolutely excel: in
their ability to place a character into an immersive narrative.
--g