Planet RIT FLOSS

Oooh, no blog post for a week. I've been doing all sorts of stuff! The FOSS RPG research team finalized our high concept document and our treatment document last week. Those will both be available on the GitHub repo early this week. With a solid framework for game design, things will be getting even more interesting from here on out.

The highlight of last week was being able to start hacking out some code. I did a little web work for tahrir and made a ton of progress on our FOSS dev character sheet, both Pyramid applications. I have really gotten a handle on basic Pyramid development.

More exciting news came in the form of a hackathon announcement: the FOSSBox will be rocking the 2012 Hack for Change, located back home in Syracuse and sponsored by Twilio. Even more exciting news came in the form of a 4-day adventure to Boston. From August 9-12, the FOSSBox will be roaming the streets of Boston, and writing some awesome code, too. "But wait", you say. "David, how can you be going to Boston when your research symposium is on the 11th?" The answer to your question is: "We're broadcasting our research presentation from Red Hat Boston." Aw yea.

I've been working for a little while on fedmsg, a set of tools for developing a Fedora Infrastructure message bus... and I need to share it with you.

If you want to get involved, hit me up in IRC on freenode in #fedora-apps -- I'm threebean there.

After today, I feel better about our project. We were able to meet with SJ and discuss our thoughts and worries. We're finally working in FOSS integration to the game design, and our discussions about the metrics available through APIs like GitHub's and Ohloh's are guiding the development of the game's setting, story, and goals. We came up with some seriously cool ideas on how FOSS data might shape our world.

I have been pinned as the more technical team member, so it'll be my responsibility tomorrow to get more in-depth information on what sort of data we can pull from each of the APIs we're interested in, and the technological feasibility of implementing that data. I will also be looking at methods of tracking non-code contributions and hacking a bit more on a Pyramid app to generate a "FOSS character sheet" based on a dev's metrics from sites like Coderwall and GitHub. It feels good to have some awesome stuff lined up.

The Fedora RPG team spend the rest of the week discussing setting, gameplay, and paper prototypes. There seemed to be most support for a Tron-esque setting with influence from famous novels Neuromancer and Snow Crash. Moving from there, we discussed how gameplay might might work, and ended the week with some initial numbers and concepts for playtesting our combat system. For me, all of this game design stuff is painstakingly slow, but I'm having a good time in the FOSSBox nonetheless.

Speaking of FOSS, the team finally reached discussion about FOSS-related stuff. Big surprise -- turns out integrating FOSS metrics into an MMORPG is going to be somewhere between tricky and impossible -- exactly what I've been saying this whole time. We were pushed forward into setting and gameplay decisions without first discussing the premise of the game or -- most importantly -- how FOSS is going to work into all this. The obvious problem is exploitation. The statistics generated by sites like GitHub, Coderwall, and Ohloh are all open to faked data. For instance, anyone can make as many Git commits of as many lines of code as they like. Users can make a dummy GitHub repo for each programming language in order to "earn" every language-based badge on Coderwall. Ohloh is similarly exploitable, being based on other exploitable data sources, like GitHub. If players' stats in our game were based on data from sources like these, the system could be easily manipulated.

And so the overarching problem I feel we now face is the value of accurate data. At the moment, a dev would prefer his metrics on sites like Ohloh to be, above all, accurate. That dev wouldn't want, for instance, a handful of repos he never touched sitting on his GitHub account, but if they are earning him points in a game, he is less motivated to delete them. I tried to get some feedback about this from the team, but SJ popped in and told everyone to not worry about these things for now. He reminds us that our goal this Summer is the design doc, and that we're mostly interested in what is technically possible and how the game would be balanced. Additionally, I feel like some of my teammates -- all game design students -- don't care much about FOSS or its place in our project. That's alright, but I am seeing now that I misunderstood the level of FOSS's involvement in this research fellowship.

I just released a minor update to SuperParamiko which adds just one new cool

feature. This feature is the ability to call multi word commands as if they

are nested attributes in python. So if you want to git pull, with SuperParamiko

it can be called as ssh.git.pull(). That is the only change in 0.1.1, the next

version will probably be a code cleanup and documentation focused release.

Github page: http://bit.ly/PASRTf

One of the largest portions ofmy job as the developer of Fedora Badges is to

package all of my work and get it into the fedora repositories. This process is

very time consuming as I found out. The first step to getting a package into the

repositories is to get a spec file, and an srpm. First you write the spec file,

this is used to generate the srpm. Once you have those two files, you should

run a koji build on the srpm. (ie: koji build --scratch f17 /path/to/srpm) this

builds the rpm in a clean environment on a fedora server, It is a good way to

catch any problems that might have been fixed by local packages on your

machine. After you have a successful koji build you need to submit a package

review request on the redhat bugzilla. For a first time packager you will need

to mention that this is your first package, and also add a block for

sponsorship. Doing that lets potential sponsors know about your request. It

might also be prudent to get on irc (irc.freenode.net) and talk to people

in the community. Gaining relationships in the community will make it easier to

get a sponsor for your first package. Once you have been sponsored and your

package has passed a review you can flip the flag indicated you need a git repo

for your package. On bugzilla this flag is called fedora-cvs. Flip that to ?

and submit a specifically formatted comment with the repository branches you

need. The branches are used to differentiate between different repos. Added a

f17 branch lets you push packages to fedora 17, while adding an el6 branch

allows for updates into EPEL 6. Now that you have obtained the repo for your

package you need to import the srpm and spec using fedpkg import. Once you have

that imported push to master (which goes direct to fedora rawhide) and run

fedpkg build. This will do a final koji build of your package. You need this

build to succeed before you can release an update with fedpkg update. Once

the build succeeds switch to each branch and merge in master. Then repeat

fedpkg build for each branch. Once that happens you can release an update

using fedpkg update. Now that you have released an update you can monitor

it's status at https://bodhi.fedoraproject.org Once it has been in

updates-testing for a long enough time you can choose to push it into stable.

So thats how to package stuff. This is just a quick howto kind of thing so lots

of stuff isincomplete. For an actually how to guide read

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

Yesterday's NetHack binge was awesome, I played for seven hours starting at 2 PM. My roommate Trevor and I left before most other people but it looks like I secured the top position. There were at least four people there more experienced with NetHack than I, but I absolutely rocked that monk. It was my first game of the binge, too.

My coolest game however goes to a Gnomish Wizard who started off with a blessed potion of polymorph. Being the resourceful player I am, I whipped the bottle at my kitty, who transformed into a master mind flayer and began restoring my power points and eating everyone else's brains. This was moments after Remy told us of a wizard of his who has a master mind flayer for a pet. If that wasn't enough, shortly after my kitty's transformation, I got the opportunity to change form myself. I couldn't pass up the opportunity -- I became a master mind flayer wizard accompanied by his trusty master mind flayer pet.

I am enjoying my day off (despite the heat), looking forward to a Fourth of July evening spent with friends.

Friday we nailed down four solid setting ideas for the Fedora RPG, some of which were compatible with eachother. We bounced around ideas about a Tron-esque megaopolis, a MegaMan: Battle Network style world where users "jack in" to a computer world, augmented reality, and colonization fantasy. If none of those sound freakin' awesome, you can leave.

Over the weekend, haly and I received Unknown Horizons dev nihathrael in #rit-foss. We had an awesome conversation wherein he gave opinions and thoughts on our work. His input was incredibly valuable, and Remy was thrilled. Nihathrael voiced many of concerns shared by haly and I. Is an MMORPG the right choice for this? Perhaps a web game would be better suited? Have we considered that many open-source people do not care about gaming at all? What about the hardcore GNU FOSS people who won't touch anything without the proper license? All valid points, and ones we're sure to discuss tomorrow morning.

It's a good feeling to see that the open-source community is interested in our research. Moving into week 5, I feel like we're going to have some cool stuff to show very soon.

By this point in the week, the Fedora RPG team has rocked two solid brainstorming sessions, compiled lists of ideas and potential mechanics, and finalized our outreach attempts. In the brainstorming field, we've gathered general ideas, combat system ideas, and a list of things that suck in video games and how they might be improved. Tomorrow, on Work From Home Friday, we will be focusing on setting and goal concepts.

On the outreach side, we utilized our gathered contact data to send emails to developers of software like Pyramid, FIFE, Box2D, and SQLAlchemy. We also contacted leaders at metrics sites like Ohloh, Coderwall, and Codecademy. Their responses to our carefully-tailored questions will be invaluable in guiding us through the next few days of design. We want to know who is excited by what we're doing so that we know where we can find community support.

On the personal side, I have learned some seriously awesome Python stuff this week. As I make progress on my little text-based game, I am finding uses for all sorts of functionality I haven't used before. For instance, this week marked my first use of Python lambdas, maps, and filters, which helped me make my code a whole lot more Pythonic. I'm having fun adding new features and playing around with new modules. I'm actually enjoying debugging -- problems are solvable in a reasonable way and I'm learning how the language works from the errors I'm getting. Cool stuff.

I recently replayed Mass Effect 3 with the “Extended Cut DLC Endings”. While having me replay 2 hours of content to see a chance in the last 4 minutes was a little much, after seeing the “new” ending, I realized that people will still be angry. Sure enough, checking the plane of the Internet today, many thought that Bioware did just a bad job with these newer endings than they did with the older endings. Why? Were the ending badly written? Produced poorly? Laughable Voice Acting? No I think the actual reason is nothing to do with the developers and all to do with the audience. Whenever an audience has to experience something they have invested in ending, they want to find ways of prolonging it. This is why Star Wars and comic book conventions exist. At these conventions, the audience can gather together and ravel in their favorite moments in the entertainment, prolonging their enjoyment of the entertainment. In a game, the audience’s attachment to the entertainment is so much higher that in books or movies due to the audience playing out the main character’s life. This instantly connects the audience and the game, making their want to continue in that world higher. With a game like Mass Effect 3, where most players have invested more than 50 hours into the game’s lore, characters, and themes, players have put themselves into that world. They have become apart of that world. Ending their connection to that world is gonna be a nasty breakup. Worse than the time the love of your life walked out on you. In the middle of a restaurant. And threw her drink in your face. So its no surprise people are mad at Bioware. People want to keep experiencing the Mass Effect universe and by ending the game with a definitive a way as it was ended, many feel they will never get a chance to delve back into that universe. What can developers do? Have Closure. The original ending to Mass Effect 3 did not have closure with all the characters met in the game, leaving the player wondering what happened to their favorite characters. The newer endings add this to the game. This is all a developer can do to combat the hate that will eventually come their way. But fret not! This means the developers has succeeded in getting their players to invest not only their money and time in their game, but also their feelings, thoughts, and beliefs into their game!

Today the team spent most of the day coming up with ideas of a combat system for the game we are developing. Many great ideas were brought out to dry, such as a game with an economy based soley on resources dropped in the game. No money, just bartering between players. These resources are then used to craft items, weapons, and armor. A really cool idea and one that I want to see in a game (if it exists please let me know so I can look into it!). I hope to see that idea make it into the final game! Another idea was a conditional turn based system (every actor in a battle is given at least one turn per round, those with higher speed may be given more) with a classless leveling system. Players would level up various abilities/skills/stats when their character leveled up, giving players to freedom to multi-class to their whim. A simple game where only health and magic points matter was also mentioned, where players had to time actions against enemies so that they could “get in” an attack, and not just horribly missed. A lot of cool ideas that lead me to realize, there are way to many game styles/combat systems that fall under RPG. Are they any useful sub-classes for RPG. Sure there’s turn-based, real time, tactics and action, but I haven’t heard of any truly specific or useful classification that mention the combat system. Only dealing with the “time” for combat or how much player thought is needed to play the game. I hope that there is either answer out there in the collective thoughts of the Internet, or that someone will come up with a classification soon. Having to read a few paragraphs about every RPG to understand the battle system is a little tedious, especially for newer Final Fantasy games.

Yesterday I push out an update to the python-pyramid package in fedora. Now

everyone can enjoy a slightly more up to date version of pyramid. This also

unblocks me from pushing out python-pyramid-tm which in turn blocks me from

pushing python-tahrir. Once I get python-tahrir into the repos, the fedbadges

branch of fedmsg will be the last thing I need to package before I can start

deploying the fedbadges stack to staging.

This week, I have been toying around with the idea of an RPG economy based on material drops (crafting ingredients), with no set currency. In a single-player game, the player would have to quest about and explore to find the resources they needed, and perhaps even other places to acquire the items NPCs want so that the player can trade with them! In an MMO, the entire player enconomy could be based on this principle, and players may end up creating de-facto currencies out of the resources most widely used and most universally valuable. Even in the single-player situation, the community of the game's players may lean toward "must-have", well-known items. This sort of phenominon is seen on a higher-level scale in the NetHack community, where no experienced player is a stranger to things like GDSM/SDSM, the wand of digging, and the amulet of life saving. These things are staples for success in the game, and almost always more valuable than Zorkmids, the game's currency. Expecially once you become powerful enough to blast away shopkeepers in their doorways.

Anyway, I am excited to look into implementing this concept in the Fedora RPG. The rest of the team seemed keen on the idea during brainstorming today, which is awesome. But before I get to put it to the test in the Fedora RPG, I'm going to try to implement it in the Python text-based game I started writing this week. I hope to use this text game as a testing ground for game mechanics and as a way to learn some new Python modules.

Today the game team had a big session of brainstorming various things we want to see in the game.  At first the team had a hard time getting into the idea of brainstorming. I had simply asked, “What game experiences to you want to see in the game?” It was not well received. Actually it might have be well received and got all the team thinking, but rather than discuss with one another about what experiences they want to see in the game, they were all still and quiet. So I changed the question. “Let’s take a game we all know. Final Fantasy. How can we add hooks for things like ohloh.net, codeacademy, and github to Final Fantasy?” This question lead to a great discussion. I do not want to go into detail what the discussion was (maybe at a later date), but from this brainstorming session, I have realized that the truly useful sessions are from direction. Having brainstorming that is just about _______ are worthless, having brainstorming sessions about “Hooks into Final Fantasy” give people a jumping off point. Then they can go into their favorite sections of a game (social, economies, combat, crafting, etc) and talk about them in detail. Just from that one question the game team now has over 35 solid game mechanics and ideas that blow the water out of any of the mechanics we had researched for the past two days. Keep checking back for more info on what those mechanics are, and which ones we plan to use!

Yesterday, we combined all of our game-playing experiences, notes, and anecdotes and compiled a brief list of things we'd like to see in the Fedora RPG. Things like:

• Grey morality
• NPC dialog trees that guide the player
• External activities earn better crafting resources in-game
• A day/night cycle
• Puzzles based on player knowledge
• Player housing

Today we're pushing farther into design and hoping to compile a solid list of mechanics to include in the game. From my experience, I find it best to decide on things like setting, purpose, and feel of a game before selecting mechanics. Unfortunately, we are a bit disadvantaged in that our communication with upstream is spotty and delayed. We have to operate through our boss, SJ, who is our conduit to Red Hat. We can't reasonably bounce ideas off Red Hat, and they've left us with total creative freedom. Freedom is nice, but no guidance or constraints is not. I want something to work with, a challenge, some goal! Anyone can sit down and pretend they're going to hack out a video game. Without anything beyond "we want a Fedora RPG", I have the uncomfortable feeling that we're tackling too big of idea for a 10-week research fellowship rapidly closing in on the halfway point. That leads me to this:

It was after we became involved with this Summer Undergraduate Research Fellowship that we learned that our purpose and expected output was not a game, or even a prototype. All we are expected to produce is a design document that maybe Red Hat will pick up. There is a good chunk of the FOSSBox that wants us to be able to start hacking, but that's not how things are being directed. I'm all for planning and design, but I also like to take a solid concept, sit down, and see what I can start hacking on. We have a couple of guys in here working on Fedora Badges, itself related to Mozilla's Open Badges concept. The Fedora RPG team could have come in here, done some research, and started hacking away at a cool little web-based RPG prototype that hooked into a badges infrastructure, and bam, we'd have something. Not that we don't have something now, it's just not code. Or any sort of game. I prefer code and games. But I'm definitely still having fun.