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 game development. Show all posts
Showing posts with label game development. 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.
Wednesday, July 27, 2011
Archaeology Simulation Assessment
The end of this past week saw the Digital Archaeology Project reach it's scheduled ending date. The team worked for 5 weeks on developing a digital, educational experience that was appropriate for a 4th grade level of student. This post will focus on the positives and negatives of the project.
Background On the Project
The team on this project consisted of eight students, four CS students and four Anthropology/History students, as well as three faculty advisors. The focus of the project was to create an experience that accurately depicted the archaeology process. The player would discover an artifact through digging, categorize the artifact, explore the house for more artifacts, research their findings in the library, all the while opening up interpretations. Their findings and research allowed them to make claims about the people who inhabited the land.
Our goals were pretty lofty considering that we had zero starting out. Knowing this, our advisors realized that we wouldn't be able to give the game the polish it would need. Therefore, our team of eight students would be in charge of the game design and initial development of the software. We wouldn't put the polishing touches on it, but we would have the game working completely by the end of our project. Then we would hand our product off to another on-campus organization to polish it up and prettify it.
Results
At the end of our 5 week period, we have a game. It's very, very raw, but it is a game. The data is there, the game flow is there. It's just ugly. It's all programmer and placeholder art, which is notoriously hideous, but it did it's job.
We didn't have to change our goals to meet our production rate, which is good. However, our goals were very, very aggressive - perhaps too aggressive. We weren't in a place where we could playtest a prototype with actual 4th graders, so we're carrying quite a bit of risk still. I say 'still' because the game can still be changed, once what's there is beautified. There are plans to playtest it and tweak what needs to be tweaked.
In the vein of SCRUM, I'll lay out areas that were successful and those that needed more work.
Positives
Conclusions
After everything is said and done, the project was a success. We set out to create something educational while still being accurate and we did that. Things weren't perfect, but I feel that we (the four CS students and two of the advisors who have worked together before) are perfecting our process.
I'm glad to have taken part in the project and I would encourage others to look for similar Immersive Learning opportunities. While these projects are great learning opportunities, one problem with Immersive Learning is that not every major supports it as well as they could. I know that art students in particular have trouble finding room in their schedules to accommodate it. If I were on a tighter schedule I may not have had time for this project.
I'll use this experience, and the Morgan's Raid experience, to make the most of this Spring, where I'll be working on a project at the Virginia Ball Center. I'm really excited about this opportunity, and I'm sure I'll blog about it in the coming months. I'm not entirely done with the Archaeology Project, as I'll likely be doing some additional development on it in the next few weeks, but I'm proud of what we were able to accomplish.
Background On the Project
The team on this project consisted of eight students, four CS students and four Anthropology/History students, as well as three faculty advisors. The focus of the project was to create an experience that accurately depicted the archaeology process. The player would discover an artifact through digging, categorize the artifact, explore the house for more artifacts, research their findings in the library, all the while opening up interpretations. Their findings and research allowed them to make claims about the people who inhabited the land.
Our goals were pretty lofty considering that we had zero starting out. Knowing this, our advisors realized that we wouldn't be able to give the game the polish it would need. Therefore, our team of eight students would be in charge of the game design and initial development of the software. We wouldn't put the polishing touches on it, but we would have the game working completely by the end of our project. Then we would hand our product off to another on-campus organization to polish it up and prettify it.
Results
At the end of our 5 week period, we have a game. It's very, very raw, but it is a game. The data is there, the game flow is there. It's just ugly. It's all programmer and placeholder art, which is notoriously hideous, but it did it's job.
We didn't have to change our goals to meet our production rate, which is good. However, our goals were very, very aggressive - perhaps too aggressive. We weren't in a place where we could playtest a prototype with actual 4th graders, so we're carrying quite a bit of risk still. I say 'still' because the game can still be changed, once what's there is beautified. There are plans to playtest it and tweak what needs to be tweaked.
In the vein of SCRUM, I'll lay out areas that were successful and those that needed more work.
Positives
- Diverse team
- we had a very diverse team, but we were able to find a group identity and work well together.
- SCRUM
- we used what I would call SCRUM lite, but the parts of it that we did use worked well. The group took to it quickly.
- New technology
- the tech team (the CS students) picked up C# and Unity3D quickly. It was fun to work with new software.
- Built off of past success
- Speaking from a tech team perspective, the Morgan's Raid experience was helpful in this project.
- Empowered team
- the faculty advisors did a good job of directing us initially, but by the end, the students were making the decisions, even the big ones
Negatives
- Pressure of lofty of goals
- while we were successful, had our goals been smaller we could've polished the game mechanics more
- Feelings of being unfulfilled
- handing off a project to someone else to finish isn't enjoyable. You get protective of a project and to see it go before it's done is a little saddening, even if it's necessary.
- Empowered team
- having the students making the big decisions led to moments where the decision took longer than it might've, had an advisor just dictated what to do.
- Short deadlines
- having such a short timeframe for a big project led to some software debt. At the time, it made more sense to keep implementing new features instead of refactoring. Also, our Product Owners didn't dictate that they wanted code refactored, so I'm not sure who should've spoken up.
Conclusions
After everything is said and done, the project was a success. We set out to create something educational while still being accurate and we did that. Things weren't perfect, but I feel that we (the four CS students and two of the advisors who have worked together before) are perfecting our process.
I'm glad to have taken part in the project and I would encourage others to look for similar Immersive Learning opportunities. While these projects are great learning opportunities, one problem with Immersive Learning is that not every major supports it as well as they could. I know that art students in particular have trouble finding room in their schedules to accommodate it. If I were on a tighter schedule I may not have had time for this project.
I'll use this experience, and the Morgan's Raid experience, to make the most of this Spring, where I'll be working on a project at the Virginia Ball Center. I'm really excited about this opportunity, and I'm sure I'll blog about it in the coming months. I'm not entirely done with the Archaeology Project, as I'll likely be doing some additional development on it in the next few weeks, but I'm proud of what we were able to accomplish.
Friday, June 24, 2011
Digital Archaeology Project & JavaFX: First Impressions
For the Digital Archaeology Project I am working on, the Computer Science students in the group were given the weekend task of tinkering with JavaFX. So far, things are going well!
JavaFX was described to me as a language that allows us to do some interesting animation and visual effects, all while allowing us to build off of our knowledge with Java. It seems pretty robust, but I've only looked at a few code examples. Getting it going with Eclipse was fairly simple. I followed this tutorial Oracle JavaFX Tutorial and was able to work along side it very easily.
I have some plans outside of staring at a computer monitor tonight, or else I would continue on with these tutorials, but that is where I plan to get back into it tomorrow.
I haven't mentioned it in this space, but I am working with a few other students and professors on developing a digital archaeology simulation (a game) for 4th graders. I wrote a quick summary of our work so far, which can be found here. I'm not sure how to use this space in conjunction with a class-wide, shared blog. I'd like to keep working in this realm, as it's easier to wrap all of my thoughts up onto one page. I could also post to both spaces simultaneously.
I like the progress that was made today. I feel for the non-Computer Science students with the prototyping that we've done this week. They've done a great job so far, but the process can be frustrating initially. Those of us who were around for Morgan's Raid last fall were subjected to our fair share of prototyping, and, as Dr. Gestwicki would and does say, you do it so you can throw ideas out. It really saves you time later. Looking back, I wish we had done a bit more prototyping in Morgan's Raid at times, but with this project I think the Anthropology students are getting a good experience. One of them mentioned in a reflective post that they didn't think they would be doing so much design - that they enjoyed getting to take part in it. I'm glad they will have the opportunity to give a lot of feedback. CS people tend to be min/maxers, power users, so we might be more interested in the numbers side of things. A fresh perspective could really be huge for keeping the game fun on a surface level (I made an archaeology joke!).
JavaFX was described to me as a language that allows us to do some interesting animation and visual effects, all while allowing us to build off of our knowledge with Java. It seems pretty robust, but I've only looked at a few code examples. Getting it going with Eclipse was fairly simple. I followed this tutorial Oracle JavaFX Tutorial and was able to work along side it very easily.
I have some plans outside of staring at a computer monitor tonight, or else I would continue on with these tutorials, but that is where I plan to get back into it tomorrow.
I haven't mentioned it in this space, but I am working with a few other students and professors on developing a digital archaeology simulation (a game) for 4th graders. I wrote a quick summary of our work so far, which can be found here. I'm not sure how to use this space in conjunction with a class-wide, shared blog. I'd like to keep working in this realm, as it's easier to wrap all of my thoughts up onto one page. I could also post to both spaces simultaneously.
I like the progress that was made today. I feel for the non-Computer Science students with the prototyping that we've done this week. They've done a great job so far, but the process can be frustrating initially. Those of us who were around for Morgan's Raid last fall were subjected to our fair share of prototyping, and, as Dr. Gestwicki would and does say, you do it so you can throw ideas out. It really saves you time later. Looking back, I wish we had done a bit more prototyping in Morgan's Raid at times, but with this project I think the Anthropology students are getting a good experience. One of them mentioned in a reflective post that they didn't think they would be doing so much design - that they enjoyed getting to take part in it. I'm glad they will have the opportunity to give a lot of feedback. CS people tend to be min/maxers, power users, so we might be more interested in the numbers side of things. A fresh perspective could really be huge for keeping the game fun on a surface level (I made an archaeology joke!).
Subscribe to:
Posts (Atom)