Design Stuff with GitHub

One of the goals of Python Math is to have a project that's at least to some degree centered around design.  It's debatable how well we're going to pull that off (it's a very quick project, and we're working on a small team), but I wanted to take just a paragraph or two to talk about what something like that would theoretically mean.

You could do drive by commits of assets or levels
We'd accomplish something like this by having really clear documentation of what the goals are for each level /asset and by putting that document into an easily accessible place.  We're hoping to simulate this sometime either this upcoming week or next week by getting assets from some external people who aren't connected with the project.

Actual design could be contributed to by committee
This is where everything starts getting hugely hugely complicated.  What we need for this is a clear, pre-decided "ethos" for the game.  Something we can use to tell if something is 'fun' or not, and what 'fun' means anyway.  Design docs will help, but there's something even more evasive that I want to capture, and I don't really know what that is yet.

Basically, we're trying to find a way to get around the semi-law that the more cooks you add, the worse everything goes in the kitchen.  Having a small team adds unity to a project - it's something people have gotten around with code, but we don't have good mechanisms for doing anything similar with design yet.

Any suggestions?

Hey, have you heard about this spyral thing?

https://github.com/platipy/spyral

There is this thing called Spyral.  It is a library built on top of the Pygame library built on top of the Python language, and it is designed to help you build

There are many things that I like about Spyral, and some things I don't like.

It's source is convenient to read and easy to figure out.
I like that the entire Spyral library is basically just in one folder, and you can pretty much open it up and crawl through it.  It is way easier to mess around with Spyral's source than it is to dig into something like monogame.

Yes, I know that Monogame is more complicated than Spyral, and is doing more things, but I don't care and you need to stop talking now.

It has extensive documentation...

The creators of Spyral have an awesome wiki, and it's super helpful -

http://platipy.readthedocs.org/en/latest/

but it's not enough.

Getting set up with Spyral isn't too bad, and learning to use it is fine.  But installing/compiling/running python on the exo is weird and confusing.  Depending on what tutorial you read, the directions seem to vary.  It's bizarre to me that a device so centered on being an open platform would be so obtuse and weird to develop for.

Maybe that's just my inexperience with python showing through though - maybe a number of these things will be clearer for me as I get more familiar with the platform and language.  It's a distinct possibility.

In any case, with Spyral, we'll have our engine up and running (in some form) fairly quickly, and the team and I will get some help getting it on the exo pretty soon as well.  I'll keep the blog updated as this all happens.

WideEyes and some Future Plans

I wrote a while back about WideEyes, a generalized AI that attempts to play Gameboy Color games with mildly interesting results.  I'm looking to expand the AI in the future and possibly tie it into some Twitch integration.

Some stuff I want to add/try:

• Culling Data: A big problem with the first iteration of WideEyes is that it gets flooded with irrelevant data.  I plan to solve this using a number of different algorithms to mark certain sections of data as important or unimportant.  This will save on processing time, allowing me to implement more processor intensive tasks later, and help WideEyes not to be confused by irrelevant data later.
• Basic Causality: I plan to allow WideEyes to understand and use cause and effect relationships to learn more about the game worlds he finds himself in.  This will be implemented using a modified N-tree, along with some accompanying data structures to model what a "cause/effect" actually is and how it can be observed.
• Bayesian Probability: I plan to model WideEyes model of causality after a simplified version of Bayes Theorem.  This will allow WideEyes to talk about a sequence of events as being somewhat likely, or very likely, or not likely at all, rather than just in absolute certainties.  WideEyes will be able to weigh the likelihood of different reactions occurring and choose his actions more intelligently.

Team Proposal: Python Math

Team Members: 

Brian Escriche
Danny Shumway
(3rd?)

What we chose:

We decided to do our own project
Python Math: Adder's garden adventure

Description:

A puzzle game designed to teach early math concepts about addition, subtraction, and order of operation.  Players try to get their length (total) to equal a set number by going back and forth through addition and subtraction gates.

Roles:

Danny: Documentation, Engine work (core)
Brian: Design, Engine work

URL: 

https://github.com/danShumway/python_math

Upstream Mentor: 

deCause, Mansam
We'll communicate through class, email, and outside meetings.

Easy parts:

hopefully our engine will be easy to build - that's one of our focuses of the project at least.

Hard parts:

documenting design
get another team member (we may already have one found)
outside contributions

Our plan:

We're going to knock out the engine quickly, and get to focusing on the design as soon as possible.  This is a proof of concept for us that we can build a well-documented design for a game, that could be picked up by other people or contributed to by other people.  We may post the project around places to help with this.

Common Core Standards and a FOSS game: Massachusetts 1.0A

One of the most exciting points of  my Humanitarian FOSS class is getting to make educational games using the Common Core standards.  Our class is working on the math curriculum, 4th grade or younger, and I'll be working with Liam Middlebrook and Brian Escriche.

For this assignment my team and I are looking at section 1.0A - this section deals with introductory math for 1st graders.

Both Massachusetts and New York have almost identical math criteria for this section, which is nice.

• Represent and solve problems involving addition and subtraction
• Understand and apply properties of operations and the relationship between addition and subtraction
• Add and subtract within 20
• Work with addition and subtraction equations

Massachusetts adds one additional requirement as a sub-point to addition and subtraction equations:

• Write and solve number sentences from problem situations that express relationships involving addition and subtraction within 20. 

Our game won't be addressing number sentences.  We'll mostly be focusing on the second and third points, understanding the properties of addition and subtraction and how they relate to each other, and performing subtraction and addition within constraints of 0 to 20.

Open Frameworks for Game Distribution

Lately I've been thinking a lot about indie markets. This has been brought about by conversations I've had at college. I'm starting to notice that at RIT a lot of people own and buy games but don't play them; and when they do play them, they don't finish them, or they rush through them.

There are problems with this approach. It encourages players to speed through games and not really think about them.  Because gamers are buying games based less on actual interest, and more on a fear of missing out on the game or the sale, it elevates the importance of single markets to developers.  Getting your game out there, with press, on Steam on a sale, is in some ways more important than the full game experience.  Have a clever twist, get good reviews on the four or five biggest review sites, etc...

It's a somewhat messed up way for the market to work.

Now, everything I just said is an overstatement.  You can get and find a larger variety of games right now than you could ever get - ever.  And if you're an indie - this is one of the best times, ever, in history, to be an indie.  The tools you have, and the people who are willing to look at your games, and the way people interact with your studio and the freedoms you have to publish, and public perception of indies - this is the best that we have ever had before in the history of gaming.

I don't want to discount any of that, and it's important to keep that stuff in the back of your mind.  But there are some problems and difficulties, and maybe if we could get past those, we could be *even better* than we are right now.

One of those difficulties is that as gaming audiences have grown, our distribution markets haven't grown as much.  The big thing people are using still is Steam - Steam pretty much allowed for the modern indie movement in the first place, and it's still the big place you want to see your game if you're an indie.  But if you have 800 people looking at Steam, there's a set number of games you can put on the homepage.  And if you get 20,000 people looking at Steam, that number doesn't go up or down.  As the market widens, exposure doesn't become less important, and the space to advertise doesn't rise at the same rate.

There are ways we can handle this.  Markets have a tendency to consolidate unless there are forces keeping them fragmented - but games are by nature pretty fragmented, and we ought to be able to feed off of that to fragment our markets as well - which could potentially be beneficial to both new developers and gamers.

It's something I'm still thinking about, but it's something I think can be helped by making more Open distribution methods for games. Steam is making some progress in this area, but stores like Humble Bundle have done better in the past, and better servers/distribution methods running on Open Source software could potentially do better.  It is something I'm still thinking about though, so at some undisclosed point I'll write more, maybe on the other blog.