my favorite art still starts fights

I visited my favorite piece of public art in San José today and it still makes me so very happy. It is funny that I so recently got in a fight about this, apparently there are some people with some lingering hurt feelings about this work, even in my circle but I have to say that as an iconic work, it always makes me smile. The artist Robert Graham was treated somewhat poorly in the commissioning of the work so he let his feelings influence the final work as it was presented to San José.

The irony is that this work has had a hugely positive effect on the way that artists are treated in the public art system, and the way the community is engaged.

I have to say too that it is a joy to see kids playing on the turd, and my favorite intervention was a number of years ago when an artist attached some sculpted flies and renamed it “Poo Platter.”

It must be difficult as a person bringing art to the city to see it become a joke, but I am sincere when I look at this and say that I admire the work and the story of how it came to “rest” here. There is no sense looking for a big dog either, but the impact of the work can be seen in tons of public art around San José.

https://www.mercurynews.com/2017/08/23/san-joses-quetzalcoatl-the-story-behind-the-statue-we-love-to-mock/

Advertisements

More Processing Portraits (Spring 18)

I really love this project, Art 74 Spring 18, Processing Self Portraits:

Student Work

self portrait in code: processing

Extra Life 2017

Tune in here: http://twitch.tv/sjsugamedev

Join the Game Dev Club at SJSU for a 24 hour live stream for Extra Life!

Extra Life is a charity organization that raises money for Children’s Miracle Network hospitals and this will be the Game Dev Club’s 4 years in a row participating! We are raising money for https://give.ucsfbenioffchildrens.org/

Be sure to donate to our Extra Life campaign here: https://www.extra-life.org/index.cfm?fuseaction=donorDrive.participant&participantID=285429

You can find the list of games we’re streaming here:
https://docs.google.com/spreadsheets/d/1vY5KStPJEmUn5L7vrkDOgd3CbICqUuuedkWj7lq2x0g/edit?usp=sharing
As well as a list of donation incentives here:
https://docs.google.com/document/d/1DWaJVt3rAvFvaZYSgG-CU5oopPk9yHCYMWyPRjVDetU/edit?usp=sharing

http://twitch.tv/sjsugamedev – to watch the stream live.

Peak GIF

“Peak GIF, an event based on M. King Hubbert’s theory, is the point in time when the maximum rate of extraction of loops is reached, after which it is expected to enter terminal decline. Peak GIF theory is based on the observed rise, peak, fall, and depletion of aggregate production rate in GIF fields over time. It is often confused with GIF depletion; however, peak GIF is the point of maximum production, while depletion refers to a period of falling reserves and supply.”

CSUSA Game Dev Studio: First Milestone

We set the daily meeting schedule, with the plan to meet with artists and programmers less often:

10 am Producers
1030 am Designers
11 am Artists
11:30 Programmers

2pm All Hands meeting (every day)

It was obvious in the beginning that people didn’t understand the roles of Producer and Designer, and our guest artists in each area did an amazing job of educating and motivating. The challenge was that the producers would get stuck managing because of inexperience, we shortly switched to a series of two day sprints for M/Tu and W/Th in the last week with Friday being about show setup.

Wed, Thu, Fri, Sat of the first week focused on basic skills with JP doing Unity workshops on Getting Started, basic platformer, scenes, doors & keys, and GUI.

Guy from the group had taught Maya workshops and volunteered to help with Maya tutorials on an intro level and dealing with rigging.

Wed started the meeting cycle and introduced the teams to the arcade cabinet, also intro to unity (almost everyone came to this) and intro to Maya.

Thursday we established that the first milestone would be Saturday at 2pm, we were scheduled to be off on Sunday, so this seemed like a good time to check progress, we also determined that we would have team meetings with their scrum boards after the 2pm demo and check in. This was to focus on the production cycle and to give critique to the entire team.

Friday morning meetings went well (though there were issues, more on this later) and JP began addressing additional issues in the Unity tutorials.

Saturday came and we limited morning meetings to producers and designers to let more development happen. Many of the teams had half of their group in each meeting so it was difficult to get a whole lot done while half the team was away.

Demo’s took place at 2pm, and we expected problems. Wrong build, wrong controller, not all mechanics (we allowed them to have paper based mechanics where they had not implemented digital). Everything you can imagine in terms of technological issues happened. This was good, the lesson is “practice your presentation” don’t wait till the last minute.

We then met with each team. There was so much good going on with each presentation but critique has a tendency to reflect on what could be improved, we had to check ourselves and make sure we said that things were going well. We also had a team struggling and set aside extra time for them. Lots of extra time, we came back after dinner and were there till almost 11pm. I have never seen a meeting run by a kinder person than Mattie Brice, her patience and focus were phenomenal.

Sunday was a day off, this moment of rest was much needed.

CSUSA Game Development Studio Prototyping

Sunday – course coordinators, meeting our student host Xavier and creating a schedule for him.

Monday – Guest artists arrive and students arrive, JP did an interview with each student regarding what they wanted to do and made groups, four groups, two of 5 and two of 4. All of them seemed balanced. We introduced the students to their teams.

Tuesday – Clients came in and were assigned to the groups based on what we saw as strengths. Then we were off, there was a short period of explanation regarding the problem and then paper prototyping. The goal was to embed the central system into a board game and then have that as a base for the video game to be developed.

Lifeboat Game. This description is from memory, so it may be imperfect. I should have asked for all of the games to be published, that was a n00b mistake. Anyhow the team was tasked for showing implicit bias.

The game starts with a random selection of Age, Gender and Race for each player. This was meant to be quick and to represent those things that might be perceived and that one may have bias against. Each player is randomly assigned and then is put on a lifeboat.

The central idea of the game is that the government knows that the people are out there and is unable to save them immediately so they start to send food. However being the government or thru budget cuts they send less food each day. Each player has 3 life points to start and when they get to zero, they are dead.

Lets assume there are 5 players. On the first day the government sends 4 food and the group must decide who does not eat, then on the second day 3 food, 2 food and finally 1 food. The decisions are made thru conversation and consensus.

How do you win? Well each person is given a goal, “make sure women and children survive” or “survive with a mate” etc, the possible goals have been listed, shuffled and dealt at random to each person. Notice that there are goals that involve the death of the player.

I do not know how many rounds you play, but that is based on the number of life points, I am sure. Anyhow, the game was played, tested, and refined within the group when they were happy with the rules we had another dev team come in and play.

This is where it got interesting, the team that play-tested it ended up being really affected by it. In the decompression they wanted to know more about the other players (beyond made up role playing) they wanted them to have jobs, like captain, engineer and such. They had a visceral reaction to the arbitrary choice they had to make. This was fascinating to me, they didn’t want to make the decision based on their bias, they wanted to remove some element from it. In the end this group created a very powerful game, when I talked to one of the players they said that they did not enjoy the game and did not like the decision process at all, they were very much affected by it and were starting to get emotional.

This was the first game to elicit tears during summer arts, well to make someone misty. I cannot help but think that the team succeeded in achieving their goal, and am somewhat encouraged that the players didn’t think the obvious information was enough. The team that came up with this game ended up scrapping the prototype.

The other teams did well but it became obvious that the systems were not always integrating, that the core purpose for doing the prototype (which was to aid in development) was not fully understood. In the prototyping cycle, I find myself unable to require the use of the prototype, but maybe there is a need for a prototype. in retrospect this should have been the guidance… if you abandon this prototype, you must come up with another to satisfy the game requirements (and test it to guarantee user experience is what you claim it to be).

Takeaway lesson: It is generally better to go over the purpose and method of a task regardless of how straightforward it seems. Help connect the dots even if you have experts in the audience to help remind everyone why we are doing the thing.

All of our teams produced paper games, the team that had the hardest time with it also ended up having some internal difficulties that came up again later. Prototyping surfaced a lot of information about communication within the teams, at least one team built and was able to use the prototype to inform their game.