No More Relics!

Gonna be completely honest: I’m freaking out right now.

The semester is winding down, and it’s go-time for Fortune Hunter.  My team has been working for weeks on refreshing this old game for the OLPC  laptops.  I’m the artist, which is a welcome change of pace and an awesome way to increase my game designer well-roundedness, but I’ve come to a horrible realization.

You see, when you write code, you may have your own style.  However, code is code.  You don’t perceive it in the same way as art.  If it works, it works.

Art is different.  Style is hard to imitate.  You can get close, but the point is that it’s difficult.  I would hate to leave this overhaul incomplete.  It would be a tremendous disservice to whoever decides to pick the project up in the future.  In fact, it would be worse than doing nothing at all.  It’s discouraging.  It’s taunting.  I hate finding art relics, and I refuse to perpetuate this nonsense.  It’s the least I can do.

So, tl’dr: I’m going to finish this art overhaul even if it kills me.

Feel free to peruse the repo too.  Some of my stuff is already up. 😀

Advertisement

RocPy 11/19/13: The Day My Brain Melted

I thought I could program.  After a few years of studying games and writing code, I assumed a bit of competency on my part.  Call it pride if you want, but it is what it is.  Yesterday, I went to the Rochester Python user’s group meeting: RocPy.  Python isn’t my forte, but on that day it really wasn’t my forte.  The topic was database management in Python.  I’m not particularly good at database anything, so it was already difficult.  Throw on an explanation of ORM’s and my head starts to hurt.  Finish it off with a comparison between SQLAlchemy and Django and you can consider me humbled.

I needed this.  I was too big for my britches.  The true programming masters are the ones who know what they don’t know, and I learned exactly what I don’t know: a lot.

Thoughts on Evgeny Morozov’s “The Meme Hustler”

Here it is, if you’re interested: http://hfoss-fossrit.rhcloud.com/static/books/evgenymorozov-thememehustler.html

Published 2013

This article is entitled “The Meme Hustler,” and it’s all about Tim O’Reilly, founder and CEO of O’Reilly Media.  The articles serves to analyze O’Reilly through the lens of his published work.  Morozov tears deep into O’Reilly, as he attempts to show that O’Reilly is actually a bit of a self-perpetuating monster with flawed ideals and too much power.

The Good

• Clear and consistent voice, an easy read.  Not super-academic or dry.
• Stays focused on picking apart O’Reilly’s actual words instead of simply attacking him out of opinion
• Provides context by mentioning the people around O’Reilly (friends, foes, and influences), like Richard Stallman and Alfred Korzybski

The Bad

• Progresses chronologically and conceptually, which can be confusing
• Ends abruptly
• Not a clear indication of a specific point to be made other than “This guy is kind of awful”

I’m still wondering…

1. What does Tim O’Reilly think of this article?
2. Just how much influence does he realistically have in government and politics?
3. Who is O’Reilly’s main, current opposition?  Is there an anti-O’Reilly with a similar amount of power?

What I think…

I liked this article.  It stuck to the facts, and Morozov is clear about exactly what he doesn’t like.  Every section of paragraphs serves to show something clear and focused, with plenty of quotations from the man himself.  Morozov thinks that O’Reilly is a bit of a madman, but in Morozov’s defense, O’Reilly isn’t doing himself any favors.

Morozov attacks his topic from multiple angles, and while I would have love a better organizational scheme for these angles, they are there nonetheless.  I learned about O’Reilly’s philosophical roots, his vast self-marketing resources, and examples of self-contradiction abound.  Clearly, this author has done his homework.  Actually, he does talk about that a bit in the author’s notes at the bottom of the page.

Anyway, I wouldn’t take this article as the definitive guide to Tim O’Reilly.  Everyone has bias of course.  What I will say is that Evgeny Morozov has done a wonderful job of saying his piece without sounding like an angry, bitter old man with a grudge.  Even if you disagree, and you totally love Tim O’Reilly, give it a read first and be salty later.

5/5 for doing your homework and delivering an enjoyable read.  Good job, Mr. Morozov.

Solarus: Open Source Re-Arting Without Pissing People Off

Open source software is great.  Well, great for programmers.  As a new artist (I volunteered to do art for my current FOSS project with my team), I’ve found the environment to be strange for artists.  Are patches really welcome?  Isn’t that like ambushing someone and giving their child a makeover?  Isn’t that insulting?

Well, I’m gonna give it a shot.  Meet Solarus.  It’s an open source Zelda game.  I’m gonna re-skin the thing, and more importantly, I’ll document the experience to help future open source artists.   There’s gotta be some methodology for creating “texture packs” or re-imagining a project in your own eyes..

RocPy Again!

Last week I went to the Rochester Python Meetup again with my FOSS class.  This time, we were on a mission.  We were pitching our One Laptop Per Child game projects to the group (which was like 90% us but whatever).  The meeting was weird because most of the projects were only related in that they are going to be coded in Python, keywords here being “going to be.”

Awkwardness aside, the other projects were pretty cool.  I was in a weird position as the artist of my group, but there were still things worth saying.  Fortune Hunter needs a visual update badly.  Balance issues abound.  There’s tons to do and very little in the way of upstream mentors.

Talking about it made Fortune Hunter feel real, it was inspiring.  Now we just need to get it to run on the XO…

Easiest Bugfix Ever?

Why do we not fix bugs?

Before you spout out your answer, focus on what I didn’t say.  I didn’t say “Why do we not find bugs.”  I specifically asked about fixing them.  Yes, there is a story for this one.

I was semi-frantically looking around the cramped, crowded alleyways of GitHub for a small bug to fix.  I’m no code-vigilante, it was an assignment for my Free and Open-Source Software class.  Intentions aside, I stumbled upon the strangest phenomenon.

In the Issues section was a bug observation that actually contained the solution.  Now, I’m not simply applauding my own luck for finding a fixed-but-not-actually-fixed bug to easily complete my assignment.  Rather, I’m quite puzzled.  This person seemed quite competent, so why didn’t he fix it?  It was literally a single line of code.  That was all it took to fix this issue.  In fact, to even notice the problem, he had to have been looking at the code.  I didn’t see a pull request.  Was he waiting for the core team to fix it?  Do a lot of people do that?

If not for FOSS, would I have done that?  Hmm…

Extra Random Thoughts on Weber’s Open Source ch3

So, Weber has these 8 Principles…

1. Make it interesting and make sure it happens
2. Scratch an itch
3. Minimize how many times you have to reinvent the wheel
4. Solve problems through parallel work processes whenever possible
5. Leverage the law of large numbers
6. Document what you do
7. Release early and often
8. Talk a lot

And opensource.org has these 5 Pillars…

1. Open exchange
2. Participation
3. Rapid Prototyping
4. Meritocracy
5. Community

Weber’s principles are functional. They deal with the “how” of FOSS.  In contrast, the pillars are descriptive and explain the “what.”  As such, the principles can be seen as demonstrations of the pillars.

• Principle 1 demonstrates pillars 1 and 5, as communities form around making cool stuff and talking about it.
• Principle 2 deals with pillars 2 and 5, as people come together naturally to solve problems that they encounter themselves.
• Principle 3 is best viewed through the lens of pillar 5, as one should rely on the community’s efforts to avoid doing that which has been done already.
• Principle 4 is pillar 3 in motion, but draws on the advantage of pillar 2. With enough prototypes and branches, progress is made in an evolutionary way.
• Principle 5 to me is purely an expression of pillar 2. The law of large numbers is basically used here to show that when a lot of people work on a project, more bugs are found and more progress is made. Pretty simple.
• Principle 6 may be hard to relate to the pillars for some, but I’ve found it to be closely related to pillar 5. Documentation is like the constitution of an open-source project. The understanding granted by it is a unifying factor in its community.
• Principle 7 is the pure form of pillar 3 and is a strange phenomenon, akin to a carefully moderated, intelligently designed evolutionary process. Basically, it’s iterative development. Fail a lot, then profit.
• Principle 8 is the fuel for the community (pillar 5). Communication is the lifeblood of a community (hence the same root). If developers didn’t talk, nobody would be able to get a feel for what is going on or what needs to be done.

Steven Weber drew heavily upon the analysis of Eric Raymond, specifically his essay “The Cathedral and the Bazaar” which is closely related to Fred Brooks’s “Conceptual Integrity.”

http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/