Some work on the Piglet logo

Piglet is the renamed successor to WideEyes, which I've been talking about on here for a while - I'm looking to start working on it over the summer.  I mocked up a very very quick logo that I'll be iterating on soon, so I thought I'd throw it up here for a blog post.

The idea is that Piglet could be animated in different states (happy, sad, concentrating), and I could overlay them onto the program.

Advanced FOSS retrospective

It's been an entire semester in Advanced FOSS, and I'm supposed to write a blog post as both a retrospective and as a final wrapup of what's happened over the summer.  I mentioned a couple of blog posts that there were a number of final tasks I wanted to work on and possibly finish up before the end of FOSS.

I ended up closing around 6 of them:

• Send the Construct 2 wikipedia article upstream and get some feedback from the community and let them know what my plans are for it (https://www.scirra.com/forum/viewtopic.php?f=156&t=104286&p=784029#p784029)
• Open source Halloween Touch (https://github.com/danShumway/Halloween-Touch)
• Decide on a new name for the AI (https://github.com/danShumway/WideEyes/issues/1)
• Decide on a license for the Piglet (https://github.com/danShumway/Piglet/issues/3)
• Get the basis's of our puzzles working in Python Math (https://github.com/danShumway/python_math/issues/22)
• Get a playable prototype up and running for Python Math (https://github.com/danShumway/python_math/issues/22)

Both Advanced FOSS and Humanitarian FOSS have been great experiences for me.  They've kept me extremely busy, kept me writing a lot of blog posts (maybe slightly more than I wanted), and given me an opportunity to get more involved in FOSS communities and to get more used to the tools of the trade.  I have no regrets over taking these courses, and I'm looking forward to interacting with RIT's FOSS community in the future.  Thanks for reading so far!

Playtesting Games with 4th Graders

We recently had the opportunity to try out Python Math: Adder's Garden Adventure (and another game I won't mention here) with some fourth graders near RIT - it was a great experience.  We got a lot of pretty useful feedback, mostly related to graphics and the way we were laying out levels.

We also stopped for ice cream, and just had a chance to get off of the RIT campus for a while, and that was pretty nice as well.

The best thing though is that events like these remind me why I like making games in the first place, so it was a great opportunity for me to kind of recharge.  Watching a bunch of 4th graders figure out how a puzzle works is awesome.  There are a lot of things that go into making a game, and when they get silly or annoying it helps to realize what the end goal is.  I spend a lot of time advocating for stuff like this in games, both in the proprietary and Open Source ends of the spectrum.

Know what the heck you're making and why you're making it - that way when you have to deal with stupid hard stuff, you know why you're subjecting yourself to this crap.  When I watch people playtest the games that I make and I see them smile, I realize how ridiculously worthwhile everything is, and it helps me to stop being so wrapped up in the minutia of what I'm doing.

Quiz: Lit Review

When?

1. April 2012

Who?

2. David McCandles
3. Marley Whiteside, Kathryn Ariel Kay, Peter Ayres
4. N/A

Where?

5. http://hfoss-fossrit.rhcloud.com/static/books/rhetological_fallacies.png
6. Wikipedia, FallacyFiles.org, Internet Encyclopedia of Philosophy, Skeptic Dictionary, ChangingMinds.org, LogicallyFallacious.com, e-ducation.net, EvolutionWiki.org, Infidels.org, Philosophical Society, Sjsu.ed, TVTropes.org, Santarosa.edu, A concise Introduction to Logic (patric J Hurley), Beginners Guide to the Scientific Method (Stephen S Carey)

What?

7. Manipulating Content, On the Attack, Faulty Deduction, Garbled Cause and Effect, Appeal to the Mind, Appeal to Emotions
8. French, Spanish, Italian, German, and of course, English.
9. Creative Commons

Lit Review: Common Fallacies

   Who
        David McCandless

    What
        Rhetological Fallacies: Errors and manipulations of rhetoric and logical thinking.

    Where
        http://hfoss-fossrit.rhcloud.com/static/books/rhetological_fallacies.png

    When
        April 2012

    The Gist
        An infographic explaining some of the more common logical fallacies out there.

    The Good

Clear use of colors to divide into sections
Pictures and text worked well.
High quality, useful resource.


    The Bad

Limited article, didn't include all fallacies.
Citing sources like Wikipedia and TVTropes (not necessarily a bad thing, but does decrease credibility)
Would have worked better in responsive HTML5 than as a single image.


    The Questions

What went into choosing the fallacies to include?
What was the original intent and target audience of the graphic?
What were all of the fonts used in the infographic?


    Your Review
        You're seriously going to ask for a linear rating from 1-5 on an infographic about logical fallacies?

Issues: Stuff I'm working on or want to work on soon.

Wikipedia

• Fix errors/add sources to the Construct 2 article (http://en.wikipedia.org/wiki/Construct_(game_engine))
• Expand on the Construct 2 article (http://en.wikipedia.org/wiki/Construct_(game_engine))
• Send the article upstream (post it on the Construct forums) and get some feedback/help with it.

Halloween Touch

• Get the code up on github, open source the project.
• Adding some assets, making some issues, thinking about where exactly this thing is supposed to go.
• Write up Gamasutra article about Halloween Touch design explaining what decisions I made/why I made them, what people's reactions have been.

WideEyes

• Decide on a new name for the AI (https://github.com/danShumway/WideEyes/issues/1)
• Decide on a license for the main engine. (https://github.com/danShumway/WideEyes/issues/3)
• Set up my gitignore for the engine (https://github.com/danShumway/WideEyes/issues/2)
• Set up repo for secondary component, monitoring chats on Twitch  (https://github.com/danShumway/WideEyes/issues/4)
• Start legit development on WideEyes (uploading code that runs).

Python Math

• Get the basis's of our puzzles working (https://github.com/danShumway/python_math/issues/22)
• Get a playable prototype up and running (https://github.com/danShumway/python_math/issues/19)

HFOSS and Advanced FOSS

• Making a proposal to the course syllabus to restructure the way that we approach assignments. (https://github.com/decause/advfoss/issues/110)

Wikipedia Edits: Moving forward with the Construct 2 article.

For a third community contribution in my advanced FOSS class, I decided to go back and follow up on the edits and structural changes I had been planning for the Wikipedia Construct 2 page.  There were a couple of reasons for this.

• I still feel like I'm at least mildly qualified to make the changes, and
• I hadn't followed up on them, and I didn't want to just keep jumping around from project to project.

You can see the edits I ended up making up here.  The big point of all of this is to make it easier for the page to be expanded in the future, which I hope to contribute to.  The biggest structural change is to shift the article from focusing on Construct: Classic, which is outdated anyway, to focusing on Construct in general, with Classic and Version 2 being separate sections under releases.

Features, etc... which are the sections that would be most likely to be expanded, are now relating back to the current version.  I plan in the future to go back and try and add some of those features, and to get the article out of it's current "stub" label.

Design Stuff with GitHub

One of the goals of Python Math is to have a project that's at least to some degree centered around design.  It's debatable how well we're going to pull that off (it's a very quick project, and we're working on a small team), but I wanted to take just a paragraph or two to talk about what something like that would theoretically mean.

You could do drive by commits of assets or levels
We'd accomplish something like this by having really clear documentation of what the goals are for each level /asset and by putting that document into an easily accessible place.  We're hoping to simulate this sometime either this upcoming week or next week by getting assets from some external people who aren't connected with the project.

Actual design could be contributed to by committee
This is where everything starts getting hugely hugely complicated.  What we need for this is a clear, pre-decided "ethos" for the game.  Something we can use to tell if something is 'fun' or not, and what 'fun' means anyway.  Design docs will help, but there's something even more evasive that I want to capture, and I don't really know what that is yet.

Basically, we're trying to find a way to get around the semi-law that the more cooks you add, the worse everything goes in the kitchen.  Having a small team adds unity to a project - it's something people have gotten around with code, but we don't have good mechanisms for doing anything similar with design yet.

Any suggestions?

Hey, have you heard about this spyral thing?

https://github.com/platipy/spyral

There is this thing called Spyral.  It is a library built on top of the Pygame library built on top of the Python language, and it is designed to help you build

There are many things that I like about Spyral, and some things I don't like.

It's source is convenient to read and easy to figure out.
I like that the entire Spyral library is basically just in one folder, and you can pretty much open it up and crawl through it.  It is way easier to mess around with Spyral's source than it is to dig into something like monogame.

Yes, I know that Monogame is more complicated than Spyral, and is doing more things, but I don't care and you need to stop talking now.

It has extensive documentation...

The creators of Spyral have an awesome wiki, and it's super helpful -

http://platipy.readthedocs.org/en/latest/

but it's not enough.

Getting set up with Spyral isn't too bad, and learning to use it is fine.  But installing/compiling/running python on the exo is weird and confusing.  Depending on what tutorial you read, the directions seem to vary.  It's bizarre to me that a device so centered on being an open platform would be so obtuse and weird to develop for.

Maybe that's just my inexperience with python showing through though - maybe a number of these things will be clearer for me as I get more familiar with the platform and language.  It's a distinct possibility.

In any case, with Spyral, we'll have our engine up and running (in some form) fairly quickly, and the team and I will get some help getting it on the exo pretty soon as well.  I'll keep the blog updated as this all happens.

WideEyes and some Future Plans

I wrote a while back about WideEyes, a generalized AI that attempts to play Gameboy Color games with mildly interesting results.  I'm looking to expand the AI in the future and possibly tie it into some Twitch integration.

Some stuff I want to add/try:

• Culling Data: A big problem with the first iteration of WideEyes is that it gets flooded with irrelevant data.  I plan to solve this using a number of different algorithms to mark certain sections of data as important or unimportant.  This will save on processing time, allowing me to implement more processor intensive tasks later, and help WideEyes not to be confused by irrelevant data later.
• Basic Causality: I plan to allow WideEyes to understand and use cause and effect relationships to learn more about the game worlds he finds himself in.  This will be implemented using a modified N-tree, along with some accompanying data structures to model what a "cause/effect" actually is and how it can be observed.
• Bayesian Probability: I plan to model WideEyes model of causality after a simplified version of Bayes Theorem.  This will allow WideEyes to talk about a sequence of events as being somewhat likely, or very likely, or not likely at all, rather than just in absolute certainties.  WideEyes will be able to weigh the likelihood of different reactions occurring and choose his actions more intelligently.

Team Proposal: Python Math

Team Members: 

Brian Escriche
Danny Shumway
(3rd?)

What we chose:

We decided to do our own project
Python Math: Adder's garden adventure

Description:

A puzzle game designed to teach early math concepts about addition, subtraction, and order of operation.  Players try to get their length (total) to equal a set number by going back and forth through addition and subtraction gates.

Roles:

Danny: Documentation, Engine work (core)
Brian: Design, Engine work

URL: 

https://github.com/danShumway/python_math

Upstream Mentor: 

deCause, Mansam
We'll communicate through class, email, and outside meetings.

Easy parts:

hopefully our engine will be easy to build - that's one of our focuses of the project at least.

Hard parts:

documenting design
get another team member (we may already have one found)
outside contributions

Our plan:

We're going to knock out the engine quickly, and get to focusing on the design as soon as possible.  This is a proof of concept for us that we can build a well-documented design for a game, that could be picked up by other people or contributed to by other people.  We may post the project around places to help with this.

Common Core Standards and a FOSS game: Massachusetts 1.0A

One of the most exciting points of  my Humanitarian FOSS class is getting to make educational games using the Common Core standards.  Our class is working on the math curriculum, 4th grade or younger, and I'll be working with Liam Middlebrook and Brian Escriche.

For this assignment my team and I are looking at section 1.0A - this section deals with introductory math for 1st graders.

Both Massachusetts and New York have almost identical math criteria for this section, which is nice.

• Represent and solve problems involving addition and subtraction
• Understand and apply properties of operations and the relationship between addition and subtraction
• Add and subtract within 20
• Work with addition and subtraction equations

Massachusetts adds one additional requirement as a sub-point to addition and subtraction equations:

• Write and solve number sentences from problem situations that express relationships involving addition and subtraction within 20. 

Our game won't be addressing number sentences.  We'll mostly be focusing on the second and third points, understanding the properties of addition and subtraction and how they relate to each other, and performing subtraction and addition within constraints of 0 to 20.

Open Frameworks for Game Distribution

Lately I've been thinking a lot about indie markets. This has been brought about by conversations I've had at college. I'm starting to notice that at RIT a lot of people own and buy games but don't play them; and when they do play them, they don't finish them, or they rush through them.

There are problems with this approach. It encourages players to speed through games and not really think about them.  Because gamers are buying games based less on actual interest, and more on a fear of missing out on the game or the sale, it elevates the importance of single markets to developers.  Getting your game out there, with press, on Steam on a sale, is in some ways more important than the full game experience.  Have a clever twist, get good reviews on the four or five biggest review sites, etc...

It's a somewhat messed up way for the market to work.

Now, everything I just said is an overstatement.  You can get and find a larger variety of games right now than you could ever get - ever.  And if you're an indie - this is one of the best times, ever, in history, to be an indie.  The tools you have, and the people who are willing to look at your games, and the way people interact with your studio and the freedoms you have to publish, and public perception of indies - this is the best that we have ever had before in the history of gaming.

I don't want to discount any of that, and it's important to keep that stuff in the back of your mind.  But there are some problems and difficulties, and maybe if we could get past those, we could be *even better* than we are right now.

One of those difficulties is that as gaming audiences have grown, our distribution markets haven't grown as much.  The big thing people are using still is Steam - Steam pretty much allowed for the modern indie movement in the first place, and it's still the big place you want to see your game if you're an indie.  But if you have 800 people looking at Steam, there's a set number of games you can put on the homepage.  And if you get 20,000 people looking at Steam, that number doesn't go up or down.  As the market widens, exposure doesn't become less important, and the space to advertise doesn't rise at the same rate.

There are ways we can handle this.  Markets have a tendency to consolidate unless there are forces keeping them fragmented - but games are by nature pretty fragmented, and we ought to be able to feed off of that to fragment our markets as well - which could potentially be beneficial to both new developers and gamers.

It's something I'm still thinking about, but it's something I think can be helped by making more Open distribution methods for games. Steam is making some progress in this area, but stores like Humble Bundle have done better in the past, and better servers/distribution methods running on Open Source software could potentially do better.  It is something I'm still thinking about though, so at some undisclosed point I'll write more, maybe on the other blog.

TimeScrub.js

TimeScrub.js is a NodeJS middleware application that allows simulations to record multiple steps along time and save those steps for later recalling.

To use, follow the following template.

var timescrub = require('timescrub');
var yourVariable = new timescrub.app();

//best fed JSON objects, but timescrub will try to work with anything, with varying degrees of success.
yourVariable.AddWatch(objectToWatch, "nameInStorage");

//In the gameloop.
yourVariable.Watch();

//And when you want to save.
yourVariable.Save("filename.json", function() { }); //Works via callback.

//And load...  Gives you a variable with the JSON in it.
yourVariable.Read("filename.json", function() { console.log(yourVariable.data); }); //Works via callback.

You can also install via npm!

Monogame Community Architecture Analysis

Monogame:

What we did:
My team and I researched Monogame primarily through its Github page, main website, and Google.  Before the project, I had crawled through the Monogame source and interacted with its developers on Github.  We attempted to augment our own research with "Git by a Bus", but coding limitations prevented us from running the sofware on a project of Monogame's size.

Some context and history: 
"From the website:  MonoGame is an Open Source implementation of the Microsoft XNA 4 Framework. Our goal is to allow XNA developers on Xbox 360, Windows & Windows Phone to port their games to the iOS, Android, Mac OS X, Linux and Windows 8 Metro.  PlayStation Mobile, Raspberry PI, and PlayStation 4 platforms are currently in progress.

In 2009 José Antonio Leal de Farias, an active member of the XNA community, started an open source project called XNA Touch with the goal of porting simple 2D XNA games to mobile devices.  He started from Bill Reiss’s SilverSprite and some bits of Mono.XNA and in December 2009 the first release which only supported iPhone was posted on Codeplex.
...
In March 2011 the project was renamed MonoGame and was moved to GitHub.  That same year support for Android, Mac, Linux, and OpenGL on Windows appeared.  Dominique Louis who joined the project in 2009 took over as the full time project lead."

What is the community?
Monogame has had 8 main developers over the course of its entire life.  Currently there are 4 : Steve Williams, Tom Spilman, Andrea Magnorksy, and Jacob Anderson, who also approve patches.  Over the course of the project there have been 138 contributors, and 6,089 commits.  Tom Spilman acts as the lead developer for the project, and is probably the best person to contact if you have additional questions.

Monogame has a large community of developers behind it, which has steadily been growing as more and more indie developers use it and give credence to the project's credibility and stability.

Would the project survive the raptor test or if 20% of contributers were killed?
My assumption is that because monogame is starting to get essential, and because the people using it are in a position to also write code for it, it would get picked up again.  While killing a large portion of the developers would be a huge detriment to the project, it would probably recover. One of monogame's strengths is that its userbase is often involved in development - this means that there are a lot of people with stake in the project, and an ability to code and improve upon it.

Monogame's Documentation/ Bug Reporting/ Quickstarts to contributing: 
Monogame has a large amount of documentation by pure virtue of being able to use most of the old XNA documentation.  It's very easy to start using.

The source code itself is also well documented; there's a good quickstart guide and the code is well-commented.  Outside of that though, you'll be somewhat on your own as to finding what bugs/features to work on.

Bugs/issues/milestones are managed through GitHub's issue tracker, which is managed by the lead developers.  This is also where most of the conversations take place - it's here you'll find talks about release schedules, future changes and merges, and so on.  Monogame has no mailing list and little activity on any IRC channel.

Is contributing to Monogame right for you?
It depends on what you want.  Monogame isn't terrifically helpful getting you set up or helping you through problems.  That may be something you like (independence, less scheduled accountability) or it may be a problem for you (less help when you run into problems, harder to talk about specific issues, harder to get people to work on things)

Any conclusions?

• There are a small number of people in charge, but those people are taking input from a large number of independent contrubuters, each with a fair amount of power over the direction.  Merging in large amounts of code requires communication and getting to know the community.
• There is a large sense of independence in the project.  The largest amounts of development are being done in forks by other people, and then after significant amounts of development (getting a game released, etc...) then merging it back in.  There are positives and negatives to this approach.
• The community doesn't do a great job holding your hand, but there's room to experiment. There's a strong DUI ethos, at least that we saw.

Callaway Coefficient of Fail : I was less than impressed with how this list is calculated.  It has less in common with a serious, accurate assessment of quality, and more in common with a series of half-joking attacks on the author's personal pet-peeves. That being said, it was a requirement.
-------------------------------------------
Size: + 0
Source control: + 0
Building from Source: + 50
Bundling: + 0
Libraries: + 20
System install: + 20
Code oddities : + 20
Communication : + 15
Releases : + 0
History : + 10
Licensing : + 10
------------------------------------------
145 - So much fail, your code should have its own reality TV show.

Our assessment: Monogame is here to stay.  The community is still growing and the project is still maturing, but nothing's going to get rid of it anytime soon.  It is, by all sane measures, a highly successful project.

Open source proposal: vAnalyze.js

vAnalyze.js: Daniel Shumway

Description : vAnalyze.js is a script that can be pasted into the Chrome Dev Console to infect any javascript functions being called on a webpage and allow the user to run real-time analytics and to inject code into those function calls.

Dependencies : None.  vAnalyze.js is a pure javascript library.  It is intended to be used with Google Chrome.

Upstream Repo : Github and Github Gist.  Because vAnalyze.js doesn't, and indeed, can't be installed on a computer, it doesn't make sense to bundle it as a library.  The most useful way to show people the code and make it available is to put into a single location that can be easily copied and pasted directly into a console.

Hardware Needed :  None (Will be running/demoing the code on a raspberry pi)

Upstream Mentors : Cody Van De Mark

License : MIT

Milestones : 

• Week 2: Setting up the functionality and planning out the architecture.
• Week 3: Finish code up, get individual components working together.
• Week 4: Testing code/documentation, adding additional tools for code analysis as time permits.
• Week 5: Packaging, more documentation

Javascript: Viral Functions and "Use Strict"

I've been making a lot more progress on viral functions over the course of the last couple of weeks.  The big breakthrough has been rewriting a method to get access to calling functions, and figuring out a feature of the Chrome Dev tools that allows easy access to those functions.


Functions in javascript are either passed by reference or value. I'm honestly still trying to figure that out, because I was almost sure this code wouldn't work until it did.

Regardless, this is a big deal.  I use arguments.callee.caller to get references to the functions that interact with my infected functions.  If it didn't work, I'd have no way to infect other functions that called mine.

The other big thing that I alluded to earlier was learning that "use strict" will only ever apply to the current script.  If this wasn't the case, I couldn't use arguments.callee.caller at all, because scripts that included "use script" would just throw errors as soon as I injected my code.  But.... that's not the case with Chrome, and it remains a viable tactic.

RIT Linux Users Group: Compiling the Linux Kernel

I recently joined the RIT Linux Users Group, for a couple of reasons.  Firstly, as part of my FOSS classes, I'm required to regularly attend tech meetups in Rochester, and the LUG was one of the few that I could actually get to.  Secondly, and obviously more importantly, I'm interested in getting more of a refresh on Linux.

When I got into college, the OS and I had a bit of a falling out, in that I stopped having the time and hardware to run it.  I want to be able to learn some of the more intermediate topics without forcing myself to exclusively use Linux or do a ton of experimentation on my own, and LUG is absolutely perfect for that.

Anyway, this week's presentation was on compiling the Linux Kernel!

I won't get too detailed about this, because I was still trying to wrap my head around the topic when our meeting ended.  That being said, the big takeways I had were:

• It's very valuable to do customization like this - contrary to what you might think, the Linux kernel can actually waste a lot of space and processor time in it's default state.  You're not just looking at trivial gains from an exercise like this.
• The big things you're looking to do is disable things that you don't need - like Mac OS drivers on your Lenovo laptop.
• You can do this graphically!  Which was a cool surprise, but it still doesn't necessarily make it easy.

Not having a Linux box I'm willing to test this on, I'm probably not going to go much farther down this particular rabbit hole, but I'm OK with that.  Like I stated above, I want to be able to tiptoe back into some of the more intermediate topics, and this was an awesome chance to do that - I'd have never researched any of this stuff if I wasn't at LUG.

Team Proposal: Monogame Community Evaluation.

Team Proposal


List your other team members below



Name
email
Daniel Shumway
shumway.danny@gmail.com
Liam Middlebrook 
ljm2906@rit.edu
Brian Escriche
bke2759@rit.edu




Which project did your team choose?

We'd like to examine the monogame community to examine their community's health and the long term feasibility of the project.


2-liner description of the project?

Monogame is an Open Source implementation of Microsoft's XNA API, started to revive the API after Microsoft abandoned it and to expand it to other platforms.

What will each team member's role be?

Team roles are still under discussion.



Daniel Shumway : Research, writing

Liam Middlebrook : Research, writing

Brian Escriche : Research writing


Source Code Repository URL?
https://github.com/mono/MonoGame


How will you communicate with them? (i.e. IRC Channel, Email Addresss, mail lists, issue trackers, etc...)
Monogame has an IRC channel, but Github will likely be the more active place.  In addition, we plan to try and talk with Ethan Lee, who's been behind a large number of the recent game ports.


What are the easy parts?

The monogame community is large, and it's a well established project.  It shouldn't be too terrible finding information for it.



What are the hard parts?

My experience thusfar has shown that the community doesn't communicate overly well on IRC.


How will you overcome both?
We'll communicate on Github and via personal messages to key parts in the community.

Getting started with contribution: Wikipedia, Github

What's all this?

I don't have a lot of experience working with other people on Open Source code, so within my FOSS classes, I wanted to try a couple of different methods of contributions just to get my feet write in a variety of ways.  These are both areas that I'd like to do more work in, so expect me to (assuming I have permission), do additional contributions for both of these projects.

Wikipedia :

• What I edited: Construct 2
• What I did: Added sources, reorganized article, proposed further changes to the community that will be implemented soon.
• How I approached: I spent some time learning the editor with small changes (adding sources), before I thought about larger formatting changes.  Once I felt comfortable with the interface, I switched the formatting around an extremely small amount and waited to see if anyone would yell at me.  I then attempted to write out my proposed changes in the community talk page to give people yet more time to tell me if I was about to kill someone's baby.  I'm now ready to implement the changes.
• Links to the logs: https://en.wikipedia.org/w/index.php?title=Construct_%28game_engine%29&diff=597145775&oldid=596445136, https://en.wikipedia.org/w/index.php?title=Talk%3AConstruct_%28game_engine%29&diff=597369714&oldid=596070839
• The moral: I've kidnapped the Construct 2 page, and if my demands aren't met I will kill one hostage every hour.

Github:

• What I patched: Monogame
• What I did: Fixed a bug that caused deactivation and activation events to be fired off multiple times during Monogame initialization.
• How I approached: I downloaded and got familiar with the source code before even looking for bugs to fix.  Monogame makes compilation interesting; you need to set up a test project on your own in order to test anything.  When I found bugs, I tried to avoid stepping on people's toes as much as possible, so I tried not to attack bugs that would require me to refactor lots of code.  I went with the assumption that because this was a large project and I wasn't familiar with it, the more code I touched the worse.  Before I did a commit I tried to talk about the changes with the community and get feedback on it.  The monogame community isn't overwhelmingly active, so this was sometimes more of a challenge than I expected it to be.
• Link to the log: https://github.com/mono/MonoGame/pull/2255
• The moral: When I put this on my resume, I'm not going to mention that the end result was just moving around two lines of code and re-commenting stuff.

AT&T Civic App Hack-a-thon Announcement

The Gist:

AT&T

• AT&T will be partnering with RIT to sponsor the 2014 Rochester Civic App Challenge.
• Part of the future of innovation is in the mobile sphere - AT&T is interested in furthering that process.
• We want to engage students in the creation of app technologies, not just the consumption of them. 

Andy Phelps (Magic)

• We want to get students thinking about how things are made and how they could be made - with a focus on civic issues and a sense of usefulness to the technologies that we create.
• Contestants in the Civic App Challenge will be competing for around $18,000 of prize money.
• The deadline for submissions is on April 23rd.
• There will be a "check-in" in March to make sure projects are going well.
• On the 21st, the whole contest is started off with a Hack-A-Thon in the Magic Center.

Joe Morelle (NY State Assembly, Competition Judge)

• A personal focus on innovation and government. 
• Innovation is going to fuel our future economy, we are shifting away from an industrial driven economy.
• In order to keep government smooth, and transparent, and running well - to "peel back the onion" and make things less complicated - we use technology.

Andy Phelps (Magic)

• We don't have expectations - we want to see what people do.
• The goal is to have developers surprise us - and by surprising us to make our lives better.

Thinking about Open Source Design

Last week I was able to interview David White, the original creator of Battle for Wesnoth, about the way Wesnoth’s community has influenced the design of the game.  This has started to evolve into a small side project for me. It started out with me being curious about the way that FOSS games were designed and if there were patterns that emerged from the really good games.

Open Source games tend to have an aura of not being as polished/developed/generally good as their proprietary counterparts, a stigma that occasionally holds true. My goal up to this point is to figure out why that is, and if there are ways to approach community design that compensate for “designed by committee” types of problems.

At this point I still don’t  have any conclusions I want to draw, but I’m running into a number of hypothesis’s that I want to research farther:

• FOSS development lends itself more to derivative games or retreads of existing genres than new IPs or gameplay.
• FOSS development lends itself more to games with high replayability, rather than narrative experiences.
• FOSS  game development goes smoothest when it borrows from proprietary development practices.

Again, these aren’t conclusions, or even likely scenarios.  They don’t represent what I believe, or what I want to believe, or anything like that.  What I’m attempting to do is develop multiple angles to approach research from, so I know what to look for, and I have a context to think about what I find.

They are the most extremely early form of a thought I can have, and they’re serving purely to define for myself what I should be looking for, and what to research next.

Assuming I finish all of this and draw some actual conclusions, I’ll most likely write some sort of essay going over them, and at that point I’ll both describe in more detail what I found and put forward some theories based on those findings.

In the meantime, any readers want to suggest some of their favorite FOSS games, or articles/people they think I should be looking at?

I know I want to talk to the community around 0 A.D, and possibly ToME.  I also want to do some research into some propriety games that have strong community influence in their design – specifically Dwarf Fortress.  There’s not a lot of research being done in this area, and I don’t plan to change that, but I’m really interested in the topic now, so while I don’t think I’ll write or do anything conclusive or scientific, I do want to try and at least start some type of conversation around the topic.

Quiz writeup 1: Principles of Open Source

1. What are titles of each Pillar?

Open Exchange

Participation

Rapid Prototyping

Meritocracy

Community

2. What are the titles of each General Principle?

Make it interesting and make sure it happens : An open source project should be “cool”, it should offer a tangable benefit to the people volunteering.

Scratch and Itch : Give people something they need.

Minimize how many times you need to reinvent the wheel : Don’t do everything from scratch.

Solve problems through parallel work processes whenever possible : Allow people to work on different tasks.

Leverage the law of large numbers: Use your community to solve bugs and other problems.

Release early and release often : Don’t get sucked into chasing perfectionism.

Talk a lot:  The flow of communication fuels development and allows you to draw in more contributors.

3. What are the similarities between Weber’s eight principles, and the five pillars?

Both have an emphasis on quick release schedules, and on effective community involvement.  The principle behind both sources is that when managed correctly, largescale community involvement allows you to more easily surmount obsticals.

4. What are the differences?

That being said, Weber focuses mostly on implementation of Open Source, not on the finished result.  His general principles are designed as advice on how to make an Open Source project succeed, not as a description of the final state of that project, or what ideals it should shoot for.

5. Bonus questions

Weber draws heavily upon Eric Raymond’s writings from the Cathedral and the Bzaar, which is another book I haven’t read but probably should.

Lit Review: The Success of Open Source (Chpt. 3)

This is a pre-formatted review of an article by Steven Weber, written for a college class.  The content being reviewed can be found at : hfoss-fossrit.rhcloud.com.  Additional publication information can be found at the bottom of this review.

Summary : The Success of Open Source details how Open Source projects exist and survive when confronted by various problems.  How and why do people contribute, how are decisions made, and what social structures exist to help a project survive?

The good stuff : 

• An uncommon insight into how Open Source projects are organized and executed.
• A realistic approach to the problems of open development, and one that proposes interesting and innovative solutions to the problem.
• Well written, and easily quotable.

The bad stuff : 

• Limited in scope, the chapter spends more time thinking about the problems of open development and how to avoid them than how they could be fixed.
• No clear picture of how a project could be passed into other hands without forking it.
• Closed, centralized design feels limited, and the article doesn’t really propose any solutions.

Questions : 

• Are there ways to coordinate community into software design without breaking it?
• How do we encourage volunteers to participate in areas that are not glamorous or highly attractive?
• Are there ways we can better control group dynamics and politics in the power structures of Open Source Projects?

 The Review : The Success of Open Source is a long article, and I don’t feel equipped to make any decisions on whether or not I agree with everything in it.  That being said, it’s a fascinating decent into the structure of FOSS communities that paints a picture of a society that is in no way anarchist or unstructured.  Along the way it raises a large number of interesting questions about how group-think can interact with software development and be managed to create incredibly end-products.  As a conversation piece, the article is fantastic; as a reference it’s even better.  The Success of Open Source diffuses a number of misconceptions I had about the nature of FOSS development, and gives a fantastic jumping point for greater analysis and further research.

Final Rating : Out of 10 stars, I give The Success of Open Source a bucket of ice-cream and three puppies, because finite, linear rating systems are just as meaningless and inapplicable to the dissemination of knowledge as this sentence.

Publication Information : author: Steven Weber, date published: November 30, 2005, source:http://hfoss-fossrit.rhcloud.com/static/books/Weber-SuccessofOpenSource-Chap3.pdf.