Astroangles is a game about learning to ‘guess’ angles just based on sight, this is very useful when approximating various calculations.
1) c 2) e 3) b 4) d 5.1) c 5.2) a 5.3) d 5.4) b 6) NC, ND 7) SA 8.1) The soundtrack of Castle Crashers the game. 8.2) Cards Against Humanity the card game 9.1) b 9.2) c 9.3) a 9.4) f 9.5) d 9.6) e
This last weekend (plus some) I went to Boston to attend PAX East. It’s a convention for gaming companies to show off their newest games as well as quite a few indie companies as well. There was plenty of vendors selling tons of cool stuff from peripherals to collectable cards & board games. There was also a variety of talks throughout the 4 days that the convention runs. I went to quite a few of these including some talking about designing games and getting into working on games while being an intern, etc. Although it wasn’t the main topic of these meetings open source software and licensing came up fairly frequently. I mostly learned more about some licenses and what comes with taking advantage of open source software that’s out there. I had a great time overall and learned a lot from the talks. This was, I believe my 5th year going and I plan to continue.
Most of the answers to the questions were gotten through simply looking at the documentation of the project as Krita is fairly well documented overall. For questions that were somewhat opinion based we quickly discussed them and usually agreed on what answers we would put.
This week I read the 4th grade section of the Mathematics Learning Standards for New York, for 2017. http://www.nysed.gov/common/nysed/files/programs/curriculum-instruction/nys-next-generation-mathematics-p-12-standards.pdf
IRC = Internet Relay Chat FOSS = Free & Open Source Software OLPC = One Laptop Per Child PR = Pull Request GNU = GNU’s Not Unix
My group for commarch:
This week was the career fair at RIT so I spend a good amount of my time preparing for that. When I was applying to dozens of companies online and looking over a lot of the requirements I realized that a good majority of employers wanted their employees to have experience with React.js. React.js is a open source library that is used to make designing user interfaces easier and more streamlined. I have had some experience with React.js in the past in my UI class although I decided to take a bit of a closer look at it and pretty much just went through a bunch of “hello world” and other basic style tutorials for React.js to give myself at least some experience with React.js.
For my bugfix I went with a very simple change to the modding API for the game Terraria. I simply fixed some typos that existed in the current build although the API is somewhat outdated. I decided to go with this more simple bugfix because I was having some issues finding a repo that I could actually contribute something too and didn’t require 30+ hours of reading through code in order to understand how to perform a simple bugfix. This, along with my lack of knowledge of python or anything other than simple recreational applications kind of restricted the number of things I could even consider to bugfix. As to why I chose this specific one, I did it because I personally really enjoy Terraria and had some personal experience with the types of modding APIs that Prism says it is a successor of, namely tAPI although, this was a long time ago. Anyway here is the link to the pull request that I submitted https://github.com/TerrariaPrismTeam/Prism/pull/27 As this project has been somewhat discontinued due to the lack of any updates to the base game essentially eliminating the need to update this as well I couldn’t find anyone to contact to talk about the API, and considering how minimal my changes were I thought it wasn’t much of an issue.
I’m going to talk about the first few sections of “Roads & Bridges” by Nadia Eghbal. I enjoyed most of the points that Eghbal brings up in these sections. After reading this I definitely appreciate open source software a little more than I have in the past, simply because it’s something that most people just don’t actively think about very often, similar to a point that Eghbal actually brings up. I agree with the xplaination of how difficult it is to maintain open software even when it is such a key tool for many different reasons, the main problem being the maintaining of the code. Although you can simply recruit volunteers to help maintain a code base, you tend to not be able to keep up with the demand. This is because the awareness of open source software is usually pretty low, and when it increases, the needs to maintain it increase as well, essentially canceling out the new influx of volunteers from the raised awareness. I also like that it was mentioned how much open source contributes to making coding available to so many more people. Many people may struggle to for example, make a game simply because they can’t aford certain frameworks that would save them months or years of work otherwise. With open source frameworks that provide a lot of functionality make it actually somewhat viable for people to just make a game for “fun” in their freetime, rather than having to construct an entire business and be forced to do it full time. The only problem I had was that I felt a lot of points were repeated a little too much for my taste at the very least, and I found myself reading the beginning of sections closely and then gradually skimming more and more as sections went on.
I haven’t been exploring too much foss recently in lieu of looking a lot more into Dungeons and Dragons. Because of this I’ve been somewhat exploring the idea of some open source software being developed to help with the various aspects in the game, especially tools for Dungeon Masters to make their job a bit easier. To begin this search I looked for some existing programs that helped with a few of these aspects that already existed and were open source. The only one I really came across that aligned with some of the ideas that I had was Mipui. Mipui is an open source dungeon maker for Dungeons and Dragons that seems at least somewhat useful. It has a variety of functions but is somewhat limited in what shapes you can make on it, although it does align nicely for the 5x5 battle grid that D&D uses. In another vein I was also considering some programs to generate encounters, etc. and handle other small things like that. This shouldn’t be too difficult to do because it simply involves making a table of possible loot and then randomizing what is pulled from it. This is probably why I couldn’t find too many specific results when I looked for things of this nature; They ususally ended up just being small embeded apps with no real documentation. Anyways, I’m now looking into possibly making something like this that could possibly be an open source version of some of the existing apps in the google play store that help with things like tracking game stats.
I recently read Simon Tatham’s small article “How to Report Bugs Effectively” (https://www.chiark.greenend.org.uk/~sgtatham/bugs.html) In this article Tatham explains how everyone should go about submitting bug reports to any form of programmer. I feel that he made quite a few good points that I will definitely be paying closer attention to for any future bug reports I make. The main thing that I found me thinking I might have failed to do in the past was describing exactly what actions I took to get to a certain state of the program; More specifically, rather than saying “I selected option X” you should instead specify if you simply clicked on the option in the menu or used a shortcut to select that option. Two other things that I personally have tried to stick to in the past that he also mentions are, giving the programmer some way to recreate the bug themselves and giving them a step by step guide to hopefully recreate the state that you had along with, actually being helpful while explaining the bug rather than simply saying “It doesn’t work.” and instead giving a detailed explanation as to what the bug actually is and what could be the possible causes. There are a few things that I feel might still be important but, less so than the others. For example, I do feel like system specifications like screen size as Tatham talked about in the article. I feel like these details should only really be given to the programmer in relative situations like the UI for a game overlapping or something similar, or if the programmer specifically asks for that information. Otherwise, this information is probably useless and just makes it more difficult to look back through the bug report when looking for specifications when what you need is grouped with another 5-6 specs that you don’t necessarily need. The other things I didn’t necessarily care for in the article were the two sections labeled “I think the tachyon modulation must be wrongly polarised” and “That’s funny, it did it a moment ago.” While Tatham does bring up some things that can be annoying in bug fixing I feel like he contradicts himself in one and the other is unneeded in a way. (Besides the one part that I mentioned earlier in this post.) In the “..tachyon modulation..” section he talks about I guess ‘prescribing’ a solution to the bug in the report which to me seems to go against what he said previously where he encouraged suggesting what could be causing the problem. And with the intermittent bugs section I feel like he simply just states that ‘sometimes bugs happen and sometimes they don’t’ but in a very longwinded way. The exception here being that he points out it may be due to a discrepancy in the user and programmer’s setups, although I feel that that point could be made in another section of the article. Overall, it’s a helpful guide to the basics of bug reporting but most of it seems like common sense to me and makes me wonder why he thought that a large piece of writing like this was necessary?
Not 100% sure if I did everything correctly here but it should do. Overall most of this stuff was a little confusing to me at first because I’ve had pretty little experience with anything that we used during this exercise besides github, and even my experience with that is minimal and pretty much boils down to forking, cloning, and commiting to repos.