RIP: A Remix Manifest Vid/Lit Review

Who
    This was a film Written and Directed by: Brett Gaylor

What
    RIP: A Remix Manifesto

Where
    It's on Vimeo over here: http://vimeo.com/8040182

When
    Date Published: 2009

The Gist
        It's an overview of the state of "Remix Culture," the challenges it faces and the social implications by the precedent it sets. It outlines the battle between consumers and corporations over who controls media and why you should care about who wins.

The Good

1. Did a good job outlining what copyright is and what is currently wrong with it
2. Gave good examples of the current effects of the copyright laws
3. Made you understand and sympathize with the opinion of the author

 The Bad

1. Spent a bit too much time with Girl Talk
2. A bit overly doomsday-ish to subvert your emotions 
3. It preaches to the choir a bit

The Questions

1. Where is this out of date
2. Has Girl Talk received any legal action
3. What are the current actions being taken to fix copyright law other than breaking it

Your Review
        While it may be a bit inaccessible to those unfamiliar with copyright laws or to those who don't care, if you want a good overview of the state of copyright law and you want to learn a bit more on the subject this is a good watch.

Team Proposal - Number Munchers

Members:

Honeybunch - amt3824@g.rit.edu
Faokryn - faokryn@csh.rit.edu
Susan - slunn@csh.rit.edu

Project - Number Munchers:

Our team decided to work on a Number Munchers clone. Number Munchers is a game where you need to eat all numbers that meet certain criteria (i.e. multiples of two) while avoiding nasty monsters.

Roles:

We're kind of forgoing roles at this point. We don't need a whole lot of graphics or sound so everyone's job is just going to be writing a bunch of code. 

Source Code:

Will be hosted here

Upstream Mentors:

Easy Parts:

Setting up PyGame
Getting the basic game working
Making sure that the content matches up with the NY state math requirements

Hard Parts:

Optimization
Troggle AI
Balancing random content

How to overcome obstacles:

Getting the base game done is the main goal and overall should not be that difficult. It's a game praised for its simplicity so re implementing it should not be impossible. Obviously we won't be doing the exact content from the original but will be mixing it up with Fractions, Geometry and other requirements from the common core for 4th graders. The hard parts are just going to take work. Troggle AI is going to take a decent amount of work without overloading the hardware as later levels will be having multiple AI routines. It's just going to take a lot of playtesting to make sure the game is fun yet challenging.

Super Late Roc Py

So I'm really late on this one but I decided to do it anyway. Last month I went to something called Roc PY, the Rochester area Python meetup. I'm not really one to go to Hackerspaces, they're nice for socializing but I never seem to get much out of them. Roc PY wasn't really much different for me but that was for a lot of reasons.

First off, I'm not a Python guy. It's never been my language. I appreciate it and I think it's great for small scripts, web development and as a scripting language paired with something like Blender, but it's never my go-to language for projects. It's very easy to write but it lacks decent performance and frankly I don't like the syntax.

About the meetup though. It was tucked away in a dark scary corner of one of the back rooms at the University of Rochester. Okay it wasn't dark or scary but it was tucked away where if I wasn't in a group, I would have probably gotten lost. Besides the abundance of HFOSS students there weren't really too many other people there. A few U of R students showed up but other than that it was just a few older guys who use Python a bunch.

Really throughout the meeting nothing really stood out to me except for one guy who wanted to do a lot of geometry tessellation with Python. Not CPython or something like Blender scripting, just Python. While I did mention that Blender would probably be the fastest pure Python solution he said he had already brought Blender to its knees. I feel like this was a problem of "Use the right tool for the right job." Python's forte is not speed, it's ease of use. If you need to do complex things really fast, especially something like tessellation, you use something like C or, ideally, you use GPU accelerated compute shaders. That kind of irked me more than it should have.

I honestly don't think I'd go again by myself. I don't think I could find my way back to that room on my own to be honest, and Python just really isn't my cup of tea. Heck even if I was into Python I feel like hanging out on /r/Python or /r/LearnProgramming or some other Python related board on your website of choice would be a better way to interact with the Python community.

NY and MA Math Curriculum Comparison

How are the NY and MA 4th Grade Math Curriculum Similar?:

Well since the Common core has been implemented, they are virtually the same. They both focus on:

Multi-Digit Multiplication and Division
Dealing with operations in Base 10 up to 1,000,000
Understanding Fractions
Dealing with Measurements and Data
Identifying lines and angles

I really haven't been able to find many differences. In face both seem to be line for line identical save for the following discrepancies:

In MA, students are expected to "Know multiplication facts and related division facts through 12 x 12."

One that seemed an interesting concept to explore with a game was 4.G #2:
Classify two-dimensional figures based on the presence or absence of parallel or perpendicular lines, or the presence or absence of angles of a specified size. Recognize right triangles as a category, and identify right triangles.

I thought it may be cool to make a simple matching game but with images of different angles and intersecting lines instead of generic images.

The IGM Department and Curriculum

Depending on who you talk to at the school of Interactive Games and Media at RIT you'll get very different answers to the question "How do you feel about the curriculum?" Most of us will give a general thumbs up. While I'm in the general thumbs up boat I feel like there's a disconnect between what we're taught and what we need to know.

Lets talk the intro sequence. When I was here under quarters we started with Java and moved to C#, now in semesters it's all C# with XNA & Monogame. Frankly the move to just one language was probably a smart one, however there's something C# really lacks and that's a decent Command Line Interface (CLI). Anyone who does C# will straight up laugh at you for wanting to use the Microsoft or Mono command line tools.

Many of my peers will give me hell for saying that using Visual Studio for everything is a bad idea. Everyone here loves Visual Studio, even I do, but it's not a good learning tool. It's true that you'll spend a lot of time, when doing actual development, plastered in front of an IDE like Visual Studio but IDEs will change while the Command Line is timeless. I'm not saying that CLIs don't change or that the *nix command line never changes but that being comfortable without a GUI is really important. Anyone who uses Git on a regular basis will tell you that no matter now nice SourceTree is, you will still need to know how to use the Git CLI.

This is getting to the point where I'm sure you're asking me "Well what's your alternative?" And that's a totally fair question. Frankly there is no right or wrong way to learn programming, but every programmer will need to learn to use the command line at some point. I suggest moving from C# and Monogame to Java and a library like the LightWeight Java Game Library (LWJGL) which powers Minecraft. Java's command line compiler is robust and a good set of debugging tools. Not to mention LWJGL gives a better intro to OpenGL and transformations / matrices than Processing does.

Now I don't expect students to be using Vim to write Java and manually link LWJGL for the entire intro sequence, but spending at least the first semester in the command line would be largely beneficial. The lack of auto completion would facilitate more direct learning, Java is a widely used language, especially on Android and being competent with the command line will make learning other essential tools like Git and Mercurial much easier later on.

Texture Leaks in Unity

Textures in Unity are easy. Super easy. Until you mix them with editor scripts. That's when all hell breaks looks. For you see, with C#, you cannot clean up your memory by yourself the way you can in something like C or Rust; you're at the mercy of the Mono Runtime. Now this makes games pretty easy to write, but when you work outside the game runtime and start writing editor scripts, things can get out of hand.

The short of it is, if you make a texture, and it's not passed to another texture variable, clean it up. Use DestroyImmediate or else you will be leaking dozens of megabytes every GUI update cycle. This sucks very badly. For Tyle, my tile editor, this problem was pretty nasty and the only way to see if I was making any improvements on the texture leaking was with the Unity Profiler. The profiler rocks, but is only available in Unity Pro, so I didn't always have access to it. This means that Tyle had some nasty leaks for many many commits.

The worst was with the selection texture. If you hover over a tile with the mouse, you'll get a nice transparent texture over the map texture to show you where you're selecting. Neat huh? Well turns out it wasn't so neat. because I wasn't destroying the previous texture before assigning a new one (it would change color or disappear depending on various settings), it leaked textures like no tomorrow.

If you create a texture in a script, you can still run into this problem but in an Editor script it can be much worse. It's not just about eating up memory of your game, it's about eating up memory of Unity, which can get very scary very quickly.

But Textures are just variables right, how are they leaking? You have to remember that Textures and Materials in Unity are not regular variables. They represent assets that could be on the disk, or written to the disk potentially. Not only that but caching them means that the engine can actually render them. Textures and Materials don't get cleaned up until you clean them up. Most of the time this is no problem because normally you'd just load a texture from the disk and apply it to a blank material. If that material already has a texture though, delete it before you apply the new one, or the old one will remain in memory.

Hudl Presentation

So last night (Thursday) instead of heading to the regular HFOSS class we were shuffled over to the MAGIC center at RIT for a presentation from the folks at Hudl. For those not familiar, Hudl is a service for coaches to upload and annotate footage of games and share that with their athletes to break down and analyze game performance easily. It's a pretty interesting concept and it's been doing well. They have about a third of the video traffic of YouTube which is an impressive 32 hours of minute uploaded a minute.

The presentation was done by a nice fellow named Rob, a software engineer at Hudl who has been responsible for a large deal of interaction between Hudl and the Open Source community. He gave a nice run down of why businesses do or do not use open source software. He also explained where OSS is used at Hudl and how it's been a generally positive experience and their goals to contribute even more back to the community.

Overall I really liked the presentation. It was well delivered and well thought out. He did a nice job juxtaposing different businesses that would or would not use OSS and why. He also did a great job remaining mostly agnostic when it comes to the holy war that is OSS vs Proprietary. My only real complaint was that, well, he was kind of preaching to the choir. Maybe that wouldn't have been the case for anyone there that wasn't a student in HFOSS but I think most of the people were. I think, in general, most of use want to be using OSS but I guess I'm speaking too much on the behalf of others.

I would have recommended the talk to anyone not familiar with OSS or curious about the role OSS plays in the business world.