Software Engineering

For my Software Engineering course we are spending the whole semester developing educational software as small groups. Each group was given the choice between math or spelling oriented software for 1st to 2nd graders. Our group chose math, since it is inherently easier to deal with numbers than words in programs. The course calls for 3 releases, or waypoints at which we demonstrate our software and, since they are in place of what would typically be exams, our software is supposed to meet criteria we determined for ourselves at the beginning of the semester. Thus far there has been one release, and two of the three groups had very visually limited programs, instead focusing on the backend. My group, however, was the complete opposite. This was not a mistake, either. If you know me well enough (or have read enough of my blog), you'll know that I am very critical when it comes to design, and this project is no exception. Initially I was hesitant to work in a group, as I've never handled group dynamic as well as I should, and indeed at the start of the semester it seemed as though the influence of the group was resulting in nothing short of chaos. However, when it came down to assigning the tasks, I ended up with about 90% or more of the work. While that meant a lot of chairtime, it also meant that I got to design the foundation of the project without any interference, so I decided to take it as a positive thing.

Until the demonstrations for the first release came, I honestly hadn't even considered the difference between focusing on back and front end, but in retrospect I think that's because all the back end in the world isn't going to make a first grader want to play your game! Minutes prior to our group's presentation, I jotted down a few ideas about my design objectives. What I came up with was that calling what we were making a game failed to represent the magnitude of our undertaking; what we were doing (in theory) was taking part in the earliest exposure and formation of the foundation of childrens' experience with mathematics. Framed in this way it is easy to see that our software being designed as best as possible is critical. What we want to do is create substantive, positive, memorable experiences involving math, in such a way that in the future these children might not run in fear from math (as many of us do now) but instead view it as an exciting and fun thing. Thus my aim in constructing the front end was to craft sensational experiences... I got a few laughs when I said that, but my guess is because people misunderstood: by sensational, I mean of the senses. Given that we are limited to merely 2 of 5 senses, it is extremely important to emphasize those senses, yet being mindful so that the experience doesn't get so chaotic that it is overwhelming and stressful as this would subvert our purpose.

I was part of one of the very first generations to have computers available in elementary school; Jordan and I were remeniscing the other day about playing those green screen computers with the floppy disks that were actually floppy in elementary school. Thus, my design objectives drew heavily on my own vivid memories of using computers to play games in school. For instance, the music in SimCity 2000, first experienced at school simply had a profound effect on my entire life. I still remember receiving SimCity from my grandparents as a Christmas gift some time shortly thereafter; obviously it was cause for substantial excitement given the detail that I can remember this event despite it having happened more than half-my-life ago. Accordingly I made certain to pick suitable music (light ambient) and sound effects... and ours was the only group to have any sound at all. Can you imagine, completely ignoring half of the senses you're given to captivate first graders?? Anyway, there's no good way to put our game online yet (there might be nearer the end of the project), so here are some screenshots:

 

 

Not only did I handle designing the game mechanic, choosing the music, and actually programming the game, but I also did all the art. With the exception of the menu screen image (from wikicommons) and a few standard fonts, I drew everything, even the animated monkey. I probably don't have a future in professional graphic design, sure, but I'm quite proud of what I've done--particularly given that I did essentially everything.

The reason I'm bringing up my homework is that release 2 is coming up quickly, we basically only get 2 weeks to put it together, and I set the bar high enough for the first release that I've got a lot of work to do! Fortunately the work was divided up a bit better this time, so I'm mostly in charge of the graphics. Nonetheless it's 3:45 AM and I'd been drawing for about 12 hours straight so it was time for a break. Yes, I'm really wishing my chair was here... and now you can see where all my complaining about design and chairs came from; you try sitting in the same thoughtlessly designed chair for 12 hours and see if you don't get a little grumpy! I think that waiting for this chair has probably been the most painful anticipation I've experienced, literally and figuratively.

Moving on, I wanted to mention that I've been spending so much time in GIMP (the GNU Image Manipulation Program, GNU stands for GNU's Not Unix), that I've actually been getting much better images out of it. I've learned a few basic techniques from some well written GIMP tutorials that have made a huge difference. While I haven't used anything from it for my own purposes, the results in this tutorial on drawing your very own planet starting with just a blank canvas are stunning, especially since the process isn't very complicated. I've also learned how to use a few of the tools better and found some other less than obvious features that have helped me get some results I'm very happy with:

  

 

 

There's always room for improvement, but I'm excited to see how it all comes together!