Despite having no homework, tests, or commitments outside of class, I've found it difficult to make time to write this semester. The type of thinking I do most days leaves me drained, and whatever energy I have left is typically zapped by my evening commute home.
At any rate, today was such a good day that I can't help but write a bit. I'm working on a project at the Virginia Ball Center, which has been a very rewarding project. I've had the chance to work with some quirky, brilliant people. As a group, we've been doing game design and internal play testing for the better part of two months. Game design uses a part of my brain that I find very taxing, but today was a bit different.
As our project moves away from game design and into software design and development, I get the chance to actually write software. I'm not resentful for things taking as long as they have; at any point, I could have said,"I don't feel like prototyping any more, I'll just write some code." But I feel that I have a good idea as to the creative direction that the game is going in. It wouldn't be fair to drop someone else into this role, I have too much momentum to do anything other than hashing out game mechanics,IMHO.
With most of the game designing done, I was able to focus some attention today on a programming task. I jumped into things via pair programming. I navigated, while a team member steered. We employed the builder pattern for the section of code we were working on, which I had not had the chance to work with yet. Today was also one of the first chances I've had to make use of some of the concepts within Clean Code, by Robert Martin. The Computer Science students within the team are reading through this book together, and we've all found it very informative.
Once our code was refactored and we determined that no code smells permeated the air, it was lunch time. After some discussions around the dining room table and our respective meals, the Computer Science students involved with the project came together and put in some really solid collaborative work regarding use cases—something none of us were proficient with yet.
Overall, the project is beginning to really come into focus. The game is taking the shape of a game, and it's hard not to be excited! Throw some gorgeous leap-year day weather into the mix and it's easy to see why today was so great! I'm looking forward to the lessons I'll learn and the tools I'll pick up in the next two months.
Showing posts with label Programming. Show all posts
Showing posts with label Programming. Show all posts
Wednesday, February 29, 2012
Tuesday, January 31, 2012
Global Game Jam and the Missing of the Point
This past weekend a few of us Ball State folk journeyed to Columbus, Ohio to the campus of The Ohio State University. The point of our trek was three-fold: to meet up with an old student, for our mentor of the group to network with a well-known individual within the gaming industry, and to take part in the Global Game Jam.
The Global Game Jam, if you've never heard of it, is a 48 hour event in which teams build a working game, based upon a provided theme. The game may be digital or analog.
The theme this year was Ouroboros. It was a vague enough of a theme that one could spin an idea (pun-bearable!) in many directions. Good choice IGDA!
I wanted to work with people that I didn't know, since, to me, the point of going was to socialize; I could just as easily make a game by myself from the comfort of my own home. Ideas spawned from the group based on the theme, and I gravitated toward a specific idea, which led me to work with people I had traveled with from Muncie. "Oh well," I thought.
However, something occurred near the end of the first night that I felt odd about. People from OSU started mentioning things like, "so and so is going to show up in a bit, and he's awesome at 3D animations." Similar phrases were mentioned 5 or 6 times. This idea popped up a few times throughout the next 24 hours.
This kind of irked me. If you feel this way, in my humble opinion, then you've missed the point of the Jam. The point was to make a game. Not necessarily a good looking, or mechanically "tight" game. Just a simple game. If you feel comfortable enough to enroll in a Jam, then chances are you don't need a lot of help to create a very simple game. And there's nothing wrong with making a somewhat ordinary game. The joy is in the creating, not the creation.
As far as my group's submission, here it is: Heads Are Tails. There is a readme and plenty enough instruction to get the gist of the game on that site, so I won't analyze it in this post (and honestly, it's very, very simple; an analysis wouldn't make sense).
Our group used the skills and tools available to us, and I'm definitely proud of what we were able to accomplish. If we were to sit down again this weekend and hammer out another game, the quality would definitely improve, but our game is an artifact that represents the sum of our talents at that point in time.
Jamming was a great experience and I look forward to participating again next year, hopefully.
 |
| Game Jam 2012 theme |
The theme this year was Ouroboros. It was a vague enough of a theme that one could spin an idea (pun-bearable!) in many directions. Good choice IGDA!
I wanted to work with people that I didn't know, since, to me, the point of going was to socialize; I could just as easily make a game by myself from the comfort of my own home. Ideas spawned from the group based on the theme, and I gravitated toward a specific idea, which led me to work with people I had traveled with from Muncie. "Oh well," I thought.
However, something occurred near the end of the first night that I felt odd about. People from OSU started mentioning things like, "so and so is going to show up in a bit, and he's awesome at 3D animations." Similar phrases were mentioned 5 or 6 times. This idea popped up a few times throughout the next 24 hours.
This kind of irked me. If you feel this way, in my humble opinion, then you've missed the point of the Jam. The point was to make a game. Not necessarily a good looking, or mechanically "tight" game. Just a simple game. If you feel comfortable enough to enroll in a Jam, then chances are you don't need a lot of help to create a very simple game. And there's nothing wrong with making a somewhat ordinary game. The joy is in the creating, not the creation.
As far as my group's submission, here it is: Heads Are Tails. There is a readme and plenty enough instruction to get the gist of the game on that site, so I won't analyze it in this post (and honestly, it's very, very simple; an analysis wouldn't make sense).Our group used the skills and tools available to us, and I'm definitely proud of what we were able to accomplish. If we were to sit down again this weekend and hammer out another game, the quality would definitely improve, but our game is an artifact that represents the sum of our talents at that point in time.
 |
| Our artist sketched us as we were between expletives |
Jamming was a great experience and I look forward to participating again next year, hopefully.
Monday, January 9, 2012
Have friends, will graduate
With a busy semester in my rear view mirror, I'd like to quickly point out something that has been on my mind for a bit.
I was asked a few weeks back to speak in front of a few prospective students and their parents regarding my involvement with Immersive Learning projects at Ball State. I prepared nothing, thinking I'd be speaking in front of maybe 100 people (which of course turned into upwards of 600 people!). One thing I managed to talk about, despite my nerves, was the friendships which I have gleaned from these projects.
I tend to keep small circles of friends; I'd rather they mean a great deal and have fewer of them. The friends I've made within my program have been a great blessing to me. They've been motivators, instigators of growth, and sources of stress release. A silly Youtube video after eight straight hours of work can do wonders.
If I could talk to 2006 Josh, one thing I would tell him would be that everyone feels more or less like you do. It's scary being in an entry level class, thinking that everyone knows how to program at the onset of college. This is obviously and absolutely false. I wish I was able to get over that mental barrier but some lessons take time. Getting close to a few classmates showed me that; not everyone knows what they're doing all of the time. And that's OK!
Making friends absolutely had a huge effect on my college career, and I have the few Immersive Learning projects to thank for that. Not only do they pit students against challenging problems, but they might just coax someone out of their shell, which can make all the difference.
I was asked a few weeks back to speak in front of a few prospective students and their parents regarding my involvement with Immersive Learning projects at Ball State. I prepared nothing, thinking I'd be speaking in front of maybe 100 people (which of course turned into upwards of 600 people!). One thing I managed to talk about, despite my nerves, was the friendships which I have gleaned from these projects.
I tend to keep small circles of friends; I'd rather they mean a great deal and have fewer of them. The friends I've made within my program have been a great blessing to me. They've been motivators, instigators of growth, and sources of stress release. A silly Youtube video after eight straight hours of work can do wonders.
If I could talk to 2006 Josh, one thing I would tell him would be that everyone feels more or less like you do. It's scary being in an entry level class, thinking that everyone knows how to program at the onset of college. This is obviously and absolutely false. I wish I was able to get over that mental barrier but some lessons take time. Getting close to a few classmates showed me that; not everyone knows what they're doing all of the time. And that's OK!
Making friends absolutely had a huge effect on my college career, and I have the few Immersive Learning projects to thank for that. Not only do they pit students against challenging problems, but they might just coax someone out of their shell, which can make all the difference.
Thursday, November 10, 2011
Taking a Page from the Programming Competitions
Having done a few programming competitions, I know firsthand how it's important when developing software solutions that the developer utilizes a sound approach. A lot of times a brute force approach will suffice, but issues arise when the software is put through the torture test of a large set of data.
In a university setting, Computer Science students are asked to come up with solutions for fairly trivial problems, at least in my experience. Coming up with the first 50 prime numbers isn't that challenging. Coming up with the first 500 or 5,000 might be more difficult. The first 50 primes might take seconds, if that. But try your code with an order of magnitude larger of a value and you might sit. With as powerful as even the cheapest machines are these days, sitting for more than 10 seconds, depending on your computation, might suggest that your approach is poorly designed or executed.
In my program, many of the projects are one-off assignments where the goal is to do X objective. Students have generally been punished, grade-wise, for uncommented code, but that has been the extent of the requirements in most cases. A brute force approach will work most times, but the code isn't well designed.
A possible solution to this is to treat the assignments more like those problems assigned at programming competitions: use a large, varied set of data when computations are being performed, and require a reasonable amount of time to finish the computation. Build a decent approach and your computation is done lickity split, but attempt to do things in a brute force manner and you just might sit and wait for seconds, minutes, or hours.
There are few things more satisfying in this discipline than coming up with a great solution for a problem that has given you fits. I've found a good resource in the Project Euler questions. Working on problems that require a good approach gets you thinking about how to keep your algorithms lean, and it'll help you know the limitations of the language you're working in (i.e. limitations with using integers vs. floats vs. longs, rounding errors, etc.)
In a university setting, Computer Science students are asked to come up with solutions for fairly trivial problems, at least in my experience. Coming up with the first 50 prime numbers isn't that challenging. Coming up with the first 500 or 5,000 might be more difficult. The first 50 primes might take seconds, if that. But try your code with an order of magnitude larger of a value and you might sit. With as powerful as even the cheapest machines are these days, sitting for more than 10 seconds, depending on your computation, might suggest that your approach is poorly designed or executed.
In my program, many of the projects are one-off assignments where the goal is to do X objective. Students have generally been punished, grade-wise, for uncommented code, but that has been the extent of the requirements in most cases. A brute force approach will work most times, but the code isn't well designed.
A possible solution to this is to treat the assignments more like those problems assigned at programming competitions: use a large, varied set of data when computations are being performed, and require a reasonable amount of time to finish the computation. Build a decent approach and your computation is done lickity split, but attempt to do things in a brute force manner and you just might sit and wait for seconds, minutes, or hours.
There are few things more satisfying in this discipline than coming up with a great solution for a problem that has given you fits. I've found a good resource in the Project Euler questions. Working on problems that require a good approach gets you thinking about how to keep your algorithms lean, and it'll help you know the limitations of the language you're working in (i.e. limitations with using integers vs. floats vs. longs, rounding errors, etc.)
Thursday, September 1, 2011
An Update On Things
It's been over a month since I last blogged, which is longer than I meant. Needless to say I've been busy.
The biggest of my tasks involved our(my wife and I) move from Muncie to Fishers. Meaning I will have to commute every day to class for the next 9 months. Quite a bummer, but we decided it was easier for her (being the sole bread-winner for the time being) to live closer to her work.
I also started back in with classes this past week. I'm excited for a lot of things about school this semester. This will be the last batch of classroom classes that I'll be taking, as well as the last on-campus classes I'll be taking. In the spring, as I've blogged about, I'll be taking part in a Virginia Ball Center project about the Underground Railroad. It'll take place off-campus, so this is sort of the beginning of the end.
My classes won't be too challenging, I don't think. I'm finishing up a couple requirements: a statistics class, a course on Theory of Computation, a 3D Graphics class, and finally an independent study where I'll be doing some Kinect development.
I'm also planning on attending CCSC programming competition and potentially presenting on something.
I'm enjoying the 2 hours of commuting every day as well as anyone can. I'm looking into some books on tape, since radio gets repetitive quickly. Also, my automobile's A/C went out yesterday, so lets pray for cool weather(!).
My wife and I are really enjoying the area we moved to. The apartment complex is quite a bit nicer than where we lived in Muncie. They also have a pool, a (small) workout facility, and an indoor (carpeted, whaa?) half-court basketball court. My better half has had a bit of time off until she starts working, so she's been enjoying some R&R while I'm away in Muncie.
This past weekend we checked out the local library and we were pleased. They have a lot of books (surprise!), so we were both able to check out something that interested us. I stumbled upon the technical books, so I picked up 97 Things Every Programmer Should Know. It's a decently short book (< 250 pgs), and each "thing" is only 2 pages long. My instincts say that lists of important concepts like this aren't usually objective, so you're taking a risk that the author knows what they're talking about. In this case, the "things" are written by a slew of industry experts. I recognized a few names, so I thought I'd give it a whirl. It's proven to be a good book to pick up for 20 minutes and set down.
So far, I've known just about everything I've read. This is comforting. Sometimes I don't quite know the technical terms the author(s) use, but I know the concepts once they explain them. The fact that I know the majority of what I'm reading is a testament to the education I've received, which I've realized that (like a lot of things in life) it's really what you put into it. If you go to class and that's it, I don't think it'll completely prepare you for the work that awaits you. I've been fortunate to bump into some great people and situations, and I've learned a lot from these experiences.
We'll see how my classes go. I'll definitely blog about the programming competition, as well as the Kinect development if it gets interesting (which I think and hope it will).
The biggest of my tasks involved our(my wife and I) move from Muncie to Fishers. Meaning I will have to commute every day to class for the next 9 months. Quite a bummer, but we decided it was easier for her (being the sole bread-winner for the time being) to live closer to her work.
I also started back in with classes this past week. I'm excited for a lot of things about school this semester. This will be the last batch of classroom classes that I'll be taking, as well as the last on-campus classes I'll be taking. In the spring, as I've blogged about, I'll be taking part in a Virginia Ball Center project about the Underground Railroad. It'll take place off-campus, so this is sort of the beginning of the end.
My classes won't be too challenging, I don't think. I'm finishing up a couple requirements: a statistics class, a course on Theory of Computation, a 3D Graphics class, and finally an independent study where I'll be doing some Kinect development.
I'm also planning on attending CCSC programming competition and potentially presenting on something.
I'm enjoying the 2 hours of commuting every day as well as anyone can. I'm looking into some books on tape, since radio gets repetitive quickly. Also, my automobile's A/C went out yesterday, so lets pray for cool weather(!).
My wife and I are really enjoying the area we moved to. The apartment complex is quite a bit nicer than where we lived in Muncie. They also have a pool, a (small) workout facility, and an indoor (carpeted, whaa?) half-court basketball court. My better half has had a bit of time off until she starts working, so she's been enjoying some R&R while I'm away in Muncie.
This past weekend we checked out the local library and we were pleased. They have a lot of books (surprise!), so we were both able to check out something that interested us. I stumbled upon the technical books, so I picked up 97 Things Every Programmer Should Know. It's a decently short book (< 250 pgs), and each "thing" is only 2 pages long. My instincts say that lists of important concepts like this aren't usually objective, so you're taking a risk that the author knows what they're talking about. In this case, the "things" are written by a slew of industry experts. I recognized a few names, so I thought I'd give it a whirl. It's proven to be a good book to pick up for 20 minutes and set down.
So far, I've known just about everything I've read. This is comforting. Sometimes I don't quite know the technical terms the author(s) use, but I know the concepts once they explain them. The fact that I know the majority of what I'm reading is a testament to the education I've received, which I've realized that (like a lot of things in life) it's really what you put into it. If you go to class and that's it, I don't think it'll completely prepare you for the work that awaits you. I've been fortunate to bump into some great people and situations, and I've learned a lot from these experiences.
We'll see how my classes go. I'll definitely blog about the programming competition, as well as the Kinect development if it gets interesting (which I think and hope it will).
Subscribe to:
Comments (Atom)