It all started April 9th with the Demo Disc Game Jam, put on by the Dallas Society of Play (DSOP). That was my first time getting to work with a team to create a game. Usually game jams only last one weekend, which doesn’t really work when you work in retail.
This one, though, lasted for a month. I was thrilled to actually be able to participate for once. We ended up with a pretty good group of programmers, artists, a sound designer, and a writer (me). I knew some of the people from other meetups, but a few of the faces were new. It didn’t take us long to settle on not only an idea but an art style.
And we were off. We affectionately dubbed the game Woofenstein (since we borrowed some inspiration from Wolfenstein) and it was a 3D, low poly barroom brawler.
Not going to lie, half of the things that were included in the game started off as jokes. Some of them worked surprisingly well, especially some of the dog puns.
There were so…many…dog puns. It was ruff.
Along the way, though, I learned a few lessons.
Different skills are needed at different stages.
As a writer, I didn’t have much to contribute during the game jam. We didn’t have time to integrate a story or any sort of dialogue. I felt pretty useless at times, but I tried to make up for it by being supportive whenever I could.
I was also nominated as the project lead, which was awesome. My team was even more awesome, though, and practically led themselves. I couldn’t help but feel like I was nothing more than moral support. Imposter syndrome kicked in pretty hard.
Everyone was incredibly proud of how the game turned out, though, and most of our team ended up deciding to keep going. Now that we are no longer merely creating a demo during a short time period, I find myself with more to contribute. We are adding in a story. There are more moving parts now. We are starting to talk marketing and showing off at conventions.
Even though I did not have much to contribute in the beginning, since I stuck around and did what I could I find myself in a position to contribute even more. I am glad that I chose to stay along for the ride.
Because the ride just got a lot longer, and now I have something to bring to the table.
Be prepared for things to go wrong.
Things will go wrong. Technology will refuse to cooperate. There will be lapses in communication. Things will not be finished on time. That is just a fact of life. And you need to be prepared for it.
That is why you always need someone keeping an eye on everything. We almost didn’t have the game completely finished by the end of the jam (thankfully the end event was pushed back due to bad weather). We bumped into issues where people would be working on the same file and it would not save correctly.
Heck, my laptop died in the middle of the demo and we had to switch to someone else’s because I was a genius and forgot my charger.
The key thing is to stay flexible. Have plans in place for when things go wrong. Have people outside of the project who have more experience than you do that you can go to about any issues you may have.
And above all, communicate with people. If you make a mistake, own up to it. People may be frustrated with you at first, but it is better to deal with it now than later.
Note: there were no major hiccups, just a few small issues so far. Most of this is just general life advice.
Don’t bite off more than you can chew (especially if you are still on the last bite).
Feature creep is a real thing. One of the organizers at DSOP, Storm, stayed in communication with all of the teams to help keep an eye on things and make sure feature creep did not happen.
For those of you who don’t know, feature creep is when you keep adding cool little bells and whistles onto your project instead of focusing on the core fundamentals of said project. It is a slippery slope that is very easy to slide down, but it can tank your project.
By adding on so many new things to tackle you can easily find yourself completely overwhelmed with everything you have to do, especially if you are trying to do it in a very short time period.
Also, if you are not comfortable taking over a certain aspect of the project, don’t. Do not overcommit yourself. If there is someone else more qualified to handle something, let them handle it and offer to assist them. There is no shame in admitting that someone else is better than you at something. No one is the best at everything.
Don’t be afraid to share the load. Don’t be afraid to ask for help. That is what your team is for.
Things will change and that’s okay.
If I am remembering correctly, the original idea that was pitched was to play as a dog in a helicopter fighting another dog in a helicopter. So, dog fighting (the term for when two helicopters/planes engage in aerial combat) dogs. Then our lead programmer mentioned wanting to do something that felt like the older Wolfenstein. Then another game was referenced. A few other ideas were pitched as well.
The game we demoed was very simple. There were four players with identical (and very stylish) designs. You ran around beating up the other players, occasionally picking up health and weapons. We actually had a lot of fun designing the weapons.
When we decided to keep going with the game, things changed. We have been talking about updating and stylizing the art. We obviously renamed it, because if we published it under Woofenstein things would not end well for us.
We have started talking adding more levels, including some that were mentioned at the beginning of the demo development. I think we have even settled on a basic story for the game. There is still a lot of work to be done and I have no doubt there will be a lot of changes between now and then.
That just comes with growth.
Whatever happens, though, I will always be thankful for this experience. I have learned more about programming, development, and working on a dev team than I ever could have outside of this. I am very excited to see where this road leads.