So apparently I'm supposed to be doing more blog posts OOOPS.
I figured it was time to write about something then. How about Waifu Quest? Yea that sounds good.
What is it? Well it's pretty much the best game that's not out yet.
For my Game Design & Development 2 class (GDD2) we have to make a game every 5 weeks. We started with an analog game that we called Jailbreak which turned out pretty okay, and now we've concocted something weird. Waifu Quest is a working title for a JRPG + Visual Novel hybrid. It's so strange we don't even know what to call it yet. I don't want to talk about the game design just yet because it's still in the fledgling stage but I can talk about what I've been programming for it so far.
We decided to use Unity 2D for this because we were all somewhat familiar with Unity and it seemed like it would streamline the process of making this game. The only thing that Unity 2D doesn't have that would have helped though, is a tile editor. This was a problem considering that our top down maps would need to be done somehow and it's not nice to do tile based work in Photoshop exclusively. So I set about trying to write a simple tile based map editor before we started really had the whole game design ironed out.
My first idea was to have an editor script generate Quads in Unity in a grid. I thought this would be awesome, I just change the associated tile and I can save the whole map as a prefab; Perfect, right? No not really... Turns out that having 10,000+ game objects in a scene is a bad idea even with 2D. The engine could take a while to generate a big map and trying to move a big map after making it would be hell. Also I never even tried to consider what would happen if the user moved a tile off the grid. So that was a bad idea.
What I've done now is create a texture based system that allows a user to paint textures from tile sets found in their Resources/Textures/ folder. Creating maps is simple and painting them is even easier. I got smart and just implemented a way for tiles to be saved into a map object that can be serialized out. This way we don't have to actually *save* the texture that we're painting, just the metadata about where the tiles are on the map. This makes saving collider data also really easy because we can just save it all as metadata in the JSON file.
Loading maps is going to be kind of challenging but WyrmTale Game's MiniJSON fork makes it pretty easy. It's MIT Licensed too which is pretty handy. Just using MiniJSON wasn't enough because I have custom Tile and Map objects that I want to serialize out, but MiniJSON doesn't take care of custom data structures very well. WyrmTale's JSON script lets me define how my objects get read and written as JSON object. It makes my life super easy now that I know how it works.
That's it for now, I'll probably post more about WaifuQuest later seeing as it will be a cool, open source and ongoing project. Maybe next time I'll talk about the completed tile editor!
Tuesday, September 30, 2014
Commarch Report
For our Commarch Report we decided to analyze the great media player VLC by VideoLAN
If you're looking for our slides you can find them here.
Here we have links to:
1. The project's IRC Channel
2. Source Code repository
3. Mail list archive
4. Documentation
5. Forum
6. Project Website
A. Describe software project, its purpose and goals.
VLC is, to put it simply, a media player to end all media players. It supports nearly every video codec, audio codec, metadata/tag type, subtitle format etc. It’s not designed to organized your media, but play anything you throw at it.
B. Give brief history of the project. When was the Initial Commit? The latest commit?
VideoLAN was started in 1996 as part of a school project by students of École Centrale Paris. The original goal was for the students to watch television on their PCs. They began writing VLS(VideoLAN Server) and VLC(VideoLAN Client) to stream and run MPEG2 images. In 2001, the school’s director agreed to change it to the GPL License and developers from around the world started working on the project. VideoLAN hosts Dev Days once a year, which they call a technical “unconference”. The last meeting was September 19th-21st, 2014
C. Who approves patches? How many people?
All patches are submitted to the mailing list, which has four admins: Konstantin Pavlov, adminvideolan (an unidentifiable person), Jean-Baptiste Kempf, and Felix Paul Kühne.
D. Who has commit access, or has had patches accepted? How many total?
Rafaël Carré is in charge of the GitHub repository currently. They don't identify who else has commit access. Over 800 contributors have had patches accepted. List: https://github.com/videolan/vlc/blob/master/AUTHORS
E. Who has the highest amounts of "Unique Knowledge?" (As per your "Git-by-a-bus" report. If there is a tie, list each contributor, with links if possible)
F. What is your project's "Calloway Coefficient of Fail?"
We calculated the Callaway Coefficient of Fail for VLC and the project scored a solid 40
G. Has there been any turnover in the Core Team? (i.e. has the same top 20% of contributors stayed the same over time? If not, how has it changed?)
Many of the top 20% of contributors have only joined the project since the last few years. The initial contributor, according to GitHub, Jean-Paul Saman, is still on the project but has not contributed as much in recent years.
H. Does the project have a BDFL, or Lead Developer? (BDFL == Benevolent Dictator for Life)
Jean-Baptiste Kempf is the President of VideoLAN, the non-profit organization that started VLC.
I. Are the front and back end developers the same people? What is the proportion of each?
The backend and the frontend are mostly separate. LibVLC has one set of contributors, and each platform's frontend (iOS, android, OSX, etc) each seem to have their own core developer(s).
J. What have been some of the major bugs/problems/issues that have arisen during development? Who is responsible for quality control and bug repair?
Feature Implementation:
There are tons of on-going projects and features that people are implementing. Each feature has its own page and wiki, with pull requests being decided by developers of the current project. The wiki page for mini projects contains dozens of small projects sorted by “short”, “normal”, and “long”. One warning that the wiki page contains is Be careful, some projects may be unrelated, or deprecated, because of fast evolving software! Ask before you attempt! This lets people get involved in the community, and to be assorted rank.
Bug Fixes:
VLC has a rather in-depth bug tracker. This bug tracker is for issues specifically with the software and bugs, not for support, where there is a seperate forum named VideoLAN forum. There are detailed instructions on how to submit bugs. A warning suggests "Keep in mind that abuse of “high” and “highest” priorities will only attract ill will".
K. How is the project's participation trending and why?
Participation seems to generally be linear. The project is active and a stroll down the git log will find many commits to various parts of the project from the core devs every week.
L. In your opinion, does the project pass "The Raptor Test?" (i.e. Would the project survive if the BDFL, or most active contributor were eaten by a Velociraptor?) Why or why not?
Definitely, the development on VLC is very active from a wide range of contributors. And there are a few "Core" developers so if any one of them died, there would be other people to take over.
M. In your opinion, would the project survive if the core team, or most active 20% of contributors, were hit by a bus? Why or why not?
Yes and no. By far the most active 20% of contributors have a large percentage of the commits and know the code the best, however VLC has been around for a long time and has a large following and community around it. It seems like the kind of project that the community would try to support and continue development on if the core dev team got wiped out.
N. Does the project have an official "on-boarding" process in place? (new contributor guides, quickstarts, communication leads who focus specifically on newbies, etc...)
The onboarding process for VLC is quite detailed and helpful. There are several links in the Developer’s Corner on their wiki for things such as Get started at coding on VLC, the source code and lists of projects. There is also a hacker’s guide as well as extensive information on the different types of documentation. They also heavily suggest you join the mailing list to become involved with the community. In short, if you want to become involved in the community, it is more than possible and even easy.
O. Does the project have Documentation available? Is it extensive? Does it include code examples?
Yes, the documentation for VLC is quite extensive. It uses DOXY generated styling, so most documentation is code generated, as opposed to a wiki.
P. If you were going to contribute to this project, but ran into trouble or hit blockers, who would you contact, and how?
The Mailing list and the IRC seem to be the places to be for VLC development. I would probably check the mailing list to see if anyone is having a similar issue and then jump into the IRC channel and ask if anyone is familiar with the project.
Q. Based on these answers, how would you describe the decision making structure/process of this group? Is it hierarchical, consensus building, ruled by a small group, barely contained chaos, or ruled by a single or pair of individuals?
VideoLAN is a massive community, and there are tons of developers and contributers. That being said, the most active 20% of contributers seem to be in charge and generally work in a community census. That being said, the term “controlled choas” would also be an accurate representation of the VLC process. These guys really believe in open source and it completely a community driven product. There are thousands of people that contribute, even though it seems the original students that designed VideoLAN in the first place still regularly contribute. Final decisions for each merge to master are usually designated by the leaders of a specific project.
R. Is this the kind of structure you would enjoy working in? Why, or why not?
I think it would be pretty interesting to work in. It’s definitely structured well and there’s a clear set of project leaders. VLC is well known and has been in development for a very long time so I imagine that the structure has to have been supporting that kind of growth.
If you're looking for our slides you can find them here.
Here we have links to:
1. The project's IRC Channel
2. Source Code repository
3. Mail list archive
4. Documentation
5. Forum
6. Project Website
A. Describe software project, its purpose and goals.
VLC is, to put it simply, a media player to end all media players. It supports nearly every video codec, audio codec, metadata/tag type, subtitle format etc. It’s not designed to organized your media, but play anything you throw at it.
B. Give brief history of the project. When was the Initial Commit? The latest commit?
VideoLAN was started in 1996 as part of a school project by students of École Centrale Paris. The original goal was for the students to watch television on their PCs. They began writing VLS(VideoLAN Server) and VLC(VideoLAN Client) to stream and run MPEG2 images. In 2001, the school’s director agreed to change it to the GPL License and developers from around the world started working on the project. VideoLAN hosts Dev Days once a year, which they call a technical “unconference”. The last meeting was September 19th-21st, 2014
C. Who approves patches? How many people?
All patches are submitted to the mailing list, which has four admins: Konstantin Pavlov, adminvideolan (an unidentifiable person), Jean-Baptiste Kempf, and Felix Paul Kühne.
D. Who has commit access, or has had patches accepted? How many total?
Rafaël Carré is in charge of the GitHub repository currently. They don't identify who else has commit access. Over 800 contributors have had patches accepted. List: https://github.com/videolan/vlc/blob/master/AUTHORS
E. Who has the highest amounts of "Unique Knowledge?" (As per your "Git-by-a-bus" report. If there is a tie, list each contributor, with links if possible)
F. What is your project's "Calloway Coefficient of Fail?"
We calculated the Callaway Coefficient of Fail for VLC and the project scored a solid 40
G. Has there been any turnover in the Core Team? (i.e. has the same top 20% of contributors stayed the same over time? If not, how has it changed?)
Many of the top 20% of contributors have only joined the project since the last few years. The initial contributor, according to GitHub, Jean-Paul Saman, is still on the project but has not contributed as much in recent years.
H. Does the project have a BDFL, or Lead Developer? (BDFL == Benevolent Dictator for Life)
Jean-Baptiste Kempf is the President of VideoLAN, the non-profit organization that started VLC.
I. Are the front and back end developers the same people? What is the proportion of each?
The backend and the frontend are mostly separate. LibVLC has one set of contributors, and each platform's frontend (iOS, android, OSX, etc) each seem to have their own core developer(s).
J. What have been some of the major bugs/problems/issues that have arisen during development? Who is responsible for quality control and bug repair?
Feature Implementation:
There are tons of on-going projects and features that people are implementing. Each feature has its own page and wiki, with pull requests being decided by developers of the current project. The wiki page for mini projects contains dozens of small projects sorted by “short”, “normal”, and “long”. One warning that the wiki page contains is Be careful, some projects may be unrelated, or deprecated, because of fast evolving software! Ask before you attempt! This lets people get involved in the community, and to be assorted rank.
Bug Fixes:
VLC has a rather in-depth bug tracker. This bug tracker is for issues specifically with the software and bugs, not for support, where there is a seperate forum named VideoLAN forum. There are detailed instructions on how to submit bugs. A warning suggests "Keep in mind that abuse of “high” and “highest” priorities will only attract ill will".
K. How is the project's participation trending and why?
Participation seems to generally be linear. The project is active and a stroll down the git log will find many commits to various parts of the project from the core devs every week.
L. In your opinion, does the project pass "The Raptor Test?" (i.e. Would the project survive if the BDFL, or most active contributor were eaten by a Velociraptor?) Why or why not?
Definitely, the development on VLC is very active from a wide range of contributors. And there are a few "Core" developers so if any one of them died, there would be other people to take over.
M. In your opinion, would the project survive if the core team, or most active 20% of contributors, were hit by a bus? Why or why not?
Yes and no. By far the most active 20% of contributors have a large percentage of the commits and know the code the best, however VLC has been around for a long time and has a large following and community around it. It seems like the kind of project that the community would try to support and continue development on if the core dev team got wiped out.
N. Does the project have an official "on-boarding" process in place? (new contributor guides, quickstarts, communication leads who focus specifically on newbies, etc...)
The onboarding process for VLC is quite detailed and helpful. There are several links in the Developer’s Corner on their wiki for things such as Get started at coding on VLC, the source code and lists of projects. There is also a hacker’s guide as well as extensive information on the different types of documentation. They also heavily suggest you join the mailing list to become involved with the community. In short, if you want to become involved in the community, it is more than possible and even easy.
O. Does the project have Documentation available? Is it extensive? Does it include code examples?
Yes, the documentation for VLC is quite extensive. It uses DOXY generated styling, so most documentation is code generated, as opposed to a wiki.
P. If you were going to contribute to this project, but ran into trouble or hit blockers, who would you contact, and how?
The Mailing list and the IRC seem to be the places to be for VLC development. I would probably check the mailing list to see if anyone is having a similar issue and then jump into the IRC channel and ask if anyone is familiar with the project.
Q. Based on these answers, how would you describe the decision making structure/process of this group? Is it hierarchical, consensus building, ruled by a small group, barely contained chaos, or ruled by a single or pair of individuals?
VideoLAN is a massive community, and there are tons of developers and contributers. That being said, the most active 20% of contributers seem to be in charge and generally work in a community census. That being said, the term “controlled choas” would also be an accurate representation of the VLC process. These guys really believe in open source and it completely a community driven product. There are thousands of people that contribute, even though it seems the original students that designed VideoLAN in the first place still regularly contribute. Final decisions for each merge to master are usually designated by the leaders of a specific project.
R. Is this the kind of structure you would enjoy working in? Why, or why not?
I think it would be pretty interesting to work in. It’s definitely structured well and there’s a clear set of project leaders. VLC is well known and has been in development for a very long time so I imagine that the structure has to have been supporting that kind of growth.
Thursday, September 25, 2014
Team Proposal Commarch Report
List your other team members below
| Name | |
|---|---|
| Susan Lunn(susan) | slunn@csh.rit.edu |
| Jennifer Stanton(AnnStan) | jas2715@rit.edu |
| Arsen Tufankjian (HoneyBunch) | amt3824@rit.edu |
| Colin O’Neill (Faokryn) |
Which project did you chose?
VLC2-liner description of the project?
VLC is a free and open source cross-platform multimedia playerand framework that plays most multimedia files as well as DVDs,
Audio CDs, VCDs, and various streaming protocols.
What will each team member's role be?
| Person | Role |
|---|---|
| AnnStan | Question 4: Parts A - G |
| susan | Question 4: Parts H - M |
| HoneyBunch | Question 4: Parts N - R + Git by a Bus |
| Faokryn | Question 5 + Question 6 |
Source code repository URL?
git clone git://git.videolan.org/vlc.gitCommarch Assessment
In progressList your upstream Mentor
In progressHow will you communicate with them?
IRC - freenode/#videolanMailing Lists - https://mailman.videolan.org/listinfo/vlc-devel
What are the easy parts?
*Running “Git by a Truck”What are the hard parts?
*Getting people to respond on IRCHow will you overcome both?
You snooze, you lose.Bugfix 1
So for my first actual bugfix in the FOSS community I wasn't sure what to do. There wasn't a whole lot of time to hunt down any new bugs in any big projects I was familiar with like CyanogenMod or Firefox (though I would have liked to) and any existing bugs that I found were WAY out of scope for the time frame. The bigger the project the more code to wade through and there was simply no way I could even get through the Firefox Gecko source code in a few days. So I settled with a cool little project I found on reddit called Cool Retro Term.
Initially I tried to tackle a bug with the Bloom not scaling properly when you edited the settings. However despite the project being in QT5 which I am familiar with, the project is written in QML which I am not well versed in. So instead I opted to do a more trivial task. The README that was on the project had some screenshots that were pretty out of date and so I took some new ones and opened a pull request. Later that day the author responded and nicely asked for some changes before my pull got accepted. I made the changes and I'm still waiting on a response, hopefully the pull will be accepted but we'll see.
The conversation and pull request can be seen here
Initially I tried to tackle a bug with the Bloom not scaling properly when you edited the settings. However despite the project being in QT5 which I am familiar with, the project is written in QML which I am not well versed in. So instead I opted to do a more trivial task. The README that was on the project had some screenshots that were pretty out of date and so I took some new ones and opened a pull request. Later that day the author responded and nicely asked for some changes before my pull got accepted. I made the changes and I'm still waiting on a response, hopefully the pull will be accepted but we'll see.
The conversation and pull request can be seen here
Wednesday, September 24, 2014
Software Freedom Day 2014
So normally I'm not a big Hackathon guy. They scare me to be totally honest. I've always been a competitive person but I've always been competitive at things that I was never very good at. Programming, something I take very seriously and something that I consider to be my "profession" becomes terrifying when put into the world of the competitive. I went to a Hackathon once before this and I stayed for a few hours, had a hard time and gave up. It was hardly a positive experience.
I went to Software Freedom day for a few reasons. One was that I needed something really exasperating to keep my mind off of personal things. Another was that I really wanted to win a Firefox Phone which I had heard would be the grand prize of the hackathon. I guess I'm kind of vein when it comes to competition.The glory and all is pretty neat, but I just don't want to buy my own cool little trophy, I want to earn it.
What did I actually do? Something kind of silly. Wanting to win the phone I decided I'd try to write an app for said phone. Of course my app idea was an old fallback. I really like Last.FM and wanted to make a scrobbler knowing well that there would be nothing like it on the Firefox OS platform. I learned exactly why that was as I struggled for well over 24 hours trying to write a simple application that would submit track info to Last.FM automatically. Turns out Firefox OS has no good way to communicate between applications so I was left with almost no real way to write this app.
At least not easily. I had a couple of ideas on how to nab some metadata from the music app. One was something that callahad (the mozilla guy at the event who's actual name I cannot remember for the life of me) stumbled across. The lockscreen of the device displayed metadata, how was it getting it? Turns out there was an event handler that it was using from an experimental IAC (inter-app-communication) API. Hacking that into the project would have been a nice solution. However thanks to the lack of documentation and not being able to get it working after a few hours I opted to try to hack in my original solution.
When I pitched the app idea to everyone my goal was to hack up the Gaia (FxOS frontend apps) Music app to write out metadata to a JSON file that I'd parse later with my own app. This hit so many problems. First one was weird, turns out that unless you rebuild Gaia, none of the Gaia apps have access to localization. This kills the app when you try to run it. After figuring that out and cloning down Gaia I ran into another issue. You can't debug Gaia apps in the FxOS Simulator which makes any sort of Gaia hacking very difficult. Especially when FxOS descides that it doesn't want to let me write anything out to the SD Card ever. I could not for the life of me get any of my code working inside of it. Callahad offered me the use of his Flame phone to try debugging the defunked muisc app. Turns out that replacing the music app files will just remove the app; I would have had to reflash Gaia to see my code running. What a headache.
By the time I got all this figured out it was all over. There was no time left and I was exhausted. The other projects were all really cool and I was certain that what I had spent my time working on was not going to stack up. Apparantly the point of a hackathon is to hack things, WHO KNEW, and I wound up with a fancy new Flame phone. Pretty neat, right?
What will I do with this neat new phone? Maybe I'll post a review of some sorts, or maybe I have some super secret plans for it.
I went to Software Freedom day for a few reasons. One was that I needed something really exasperating to keep my mind off of personal things. Another was that I really wanted to win a Firefox Phone which I had heard would be the grand prize of the hackathon. I guess I'm kind of vein when it comes to competition.The glory and all is pretty neat, but I just don't want to buy my own cool little trophy, I want to earn it.
What did I actually do? Something kind of silly. Wanting to win the phone I decided I'd try to write an app for said phone. Of course my app idea was an old fallback. I really like Last.FM and wanted to make a scrobbler knowing well that there would be nothing like it on the Firefox OS platform. I learned exactly why that was as I struggled for well over 24 hours trying to write a simple application that would submit track info to Last.FM automatically. Turns out Firefox OS has no good way to communicate between applications so I was left with almost no real way to write this app.
At least not easily. I had a couple of ideas on how to nab some metadata from the music app. One was something that callahad (the mozilla guy at the event who's actual name I cannot remember for the life of me) stumbled across. The lockscreen of the device displayed metadata, how was it getting it? Turns out there was an event handler that it was using from an experimental IAC (inter-app-communication) API. Hacking that into the project would have been a nice solution. However thanks to the lack of documentation and not being able to get it working after a few hours I opted to try to hack in my original solution.
When I pitched the app idea to everyone my goal was to hack up the Gaia (FxOS frontend apps) Music app to write out metadata to a JSON file that I'd parse later with my own app. This hit so many problems. First one was weird, turns out that unless you rebuild Gaia, none of the Gaia apps have access to localization. This kills the app when you try to run it. After figuring that out and cloning down Gaia I ran into another issue. You can't debug Gaia apps in the FxOS Simulator which makes any sort of Gaia hacking very difficult. Especially when FxOS descides that it doesn't want to let me write anything out to the SD Card ever. I could not for the life of me get any of my code working inside of it. Callahad offered me the use of his Flame phone to try debugging the defunked muisc app. Turns out that replacing the music app files will just remove the app; I would have had to reflash Gaia to see my code running. What a headache.
By the time I got all this figured out it was all over. There was no time left and I was exhausted. The other projects were all really cool and I was certain that what I had spent my time working on was not going to stack up. Apparantly the point of a hackathon is to hack things, WHO KNEW, and I wound up with a fancy new Flame phone. Pretty neat, right?
What will I do with this neat new phone? Maybe I'll post a review of some sorts, or maybe I have some super secret plans for it.
Thursday, September 11, 2014
Quiz 1: The Pillars of Open Source
What are the titles of each Pillar?
- Open Exchange
- Participation
- Rapid Prototyping
- Meritocracy
- Community
What are the titles of each General Principle?
- Make it Interesting and make it happen
- Scratch an Itch
- Minimize how often you have to reinvent the wheel
- Solve problems through parallel work processes wherever possible
- Leverage the law of large numbers
- Document what you do
- Release early and release often
- Talk a lot
What are the similarities between Weber's eight principles, and the five pillars?
The principles and the pillars share quite a bit in common. What I noticed from the get-go is that they both aim to answer a lot of questions that people may have about open source and its community. They seek to provide a starting point from people looking into open source from the outside.
What are the differences?
The main difference I see between the two is what questions they're actually answering and who those questions may be asked by. The Pillars seem to answer the question "What are the general ideologies that the open source community considers to be core." It'a s more political question than anything. The General Principles seems to be answering the question "What are some rules I should follow if I want to participate in the open source community." These read almost more like an employee handbook; they're a bit more "casual" and much more practical for a curious programmer wanting to get his/her feet wet.
Monday, September 8, 2014
What Is Open Source - Lit Review 1
Who: Steve Weber
What:What Is Open Source and How Does It Work?
When: 2005
Where: HERE!
Gist:
The text gives a nice summary of Linus Torvalds and his fathering of the Linux Operating System and goes on to give a good description on the Open Source movement and the philosophies surrounding the phenomenon. It also does a decent job of comparing Open Source development to typical commercial development.
The Good:
The Bad:
Review:
Weber provides a very in-depth introduction to Open Source as a whole that remains fairly accurate even today. It could really go more in depth with the history and the modern licensing types and could ease off a bit with the exasperating description of how corporate development differs from open source development. Despite being a somewhat difficult read it provides a host of information that anyone interested in Open Source development would need to know. 7/10 Would recommend if you like lots of words.
What:What Is Open Source and How Does It Work?
When: 2005
Where: HERE!
Gist:
The text gives a nice summary of Linus Torvalds and his fathering of the Linux Operating System and goes on to give a good description on the Open Source movement and the philosophies surrounding the phenomenon. It also does a decent job of comparing Open Source development to typical commercial development.
The Good:
- A concise and interesting history of the early works of Linus
- Good explanation of why people give away their work without compensation
- Gives a nice summary of different license types
The Bad:
- It is extremely dense and by no means easy to read; especially for something aiming to be an introduction
- The "The Software 'Problem'" drags with lots of allegory that seems to miss the point.
- While the opening history of open source was enthralling, everything else was rather a chore to read
- Who were some big players in the early open source movement? I only ever hear about Linus
- How do I actually go about licensing my software? Do I just add a license to the project?
- Where can I go to contribute to the Linux Operating System? Where is the base kernel code hosted?
Review:
Weber provides a very in-depth introduction to Open Source as a whole that remains fairly accurate even today. It could really go more in depth with the history and the modern licensing types and could ease off a bit with the exasperating description of how corporate development differs from open source development. Despite being a somewhat difficult read it provides a host of information that anyone interested in Open Source development would need to know. 7/10 Would recommend if you like lots of words.
Subscribe to:
Posts (Atom)