Venturing into board games
May 8, 2013 by Shawn · Leave a Comment
Two weekends ago, I went to the Different Games Conference in New York. It was an excellent conference, and I was luckily enough to have people play Rainbow Bacon. Of course, I was to caught up in doing things to remember to take pictures of anything there.
One of the events I attended was a board game workshop. Now, I’ve played board games in the past, but not enough to gain a better understanding of standard board game mechanics that lifelong board game designers simply know from years of experience. Regardless of my lack of knowledge, the plan was to learn something and potentially make something that I didn’t hate.
The process of the board game, for me, was filled with trial and error. A lot of trial and error. In the time we were given to work on games, I was able to throw away a large number of concepts that just didn’t work, or just seemed good in my mind, but terrible once put into production. And it was awesome.
I’ve been mostly developing digital games for the last couple of years, save a couple of card games, one of which I’m actually still developing at this moment. With digital games, it took much longer to implement an idea, even after the bare minimum was documented for the initial prototype phase. Combined with the fact that game development is not my full time gig, much time is spent simply working on something that may not even become more than the prototype. That’s not to say that it’s a major, or even a minor problem. Of course, it’d be nice if each idea was guaranteed to function properly and interface correctly with the world.
Also, prototypes are pretty fun.
Anyway, the board game designs gave me more confidence after each failure. A sense of, “Hey, I failed, but it only took me 10 minutes to fail. I can fail 10 more times and be okay!”. This is different from my original design process for digital games, and will definitely shape the way I work on all games in the future. This isn’t say that I’m afraid to fail when creating a digital game. I’ve failed before, and I’ll do it again. The difference is that the cost of failing was less when rapidly prototyping a analog game. Before long, I was able to create a pair of concepts that were mostly solid. One of the games still requires play testing, while the other needs for me to work on the new rules.
How will this affect me in the future? First, I’ll probably make more board games overall. There may be some games that just won’t work with a computer screen, or be better expressed as a board game. Instead of trying to force every idea I have into something that requires a controller, a mouse, and/or a keyboard, it might be better to allow a project to thrive in the environment that allows it to thrive best.
Next, and more importantly in terms of my actual development, more of my prototyping phases will begin with a more detail paper and pen design, or other physical objects, such as dice, chips, cards or more. I’ve read about this before, from a number of places. Developing a paper prototype is great for the beginning phases of any sort of game design, if applicable. Working with paper prototypes allow you to better refine a game project before you write lines of code. Having more of an idea with what you want from the starting phase will allow for a potential faster realization of what you’re trying to accomplish. Now, I do not want to undermine the importance of improvisation and randomness when trying to create game. I’ve done a number of things that I like when just experimenting. But having my ideas translate over to the screen faster feels nice.
And then, there’s the fact that I want to make games, and be a well-rounded game designer. Right now, I feel that if you want be become an okay game designer, you should make a lot of games. If you want to be a great designer, you should make a lot of different games. Board games, physical games, simple dice games, digital games, etc. Even expand genres within one subset of games. You may be good at making puzzle games, and want to only make that type of game, but you may learn something new and useful if you tried making an FPS or a platformer. To be better than great, you need to do more than game design. That means read few books, or do things away from the screen. Basically increase the number of pools that you’re able to pull from. But that’s a different area of discussion.
As for now, the plan is to create more paper prototypes before I sit down in front of the computer. This should, hopefully, lead to better digital game designs, and the creation of more board games.
Experiments with music
April 25, 2013 by Shawn · Leave a Comment
I’ve been working on a new project which has been full of a number of experiments. From musical experiments, to hardware, to controls, and even how players will interact with each other. My biggest fear with this current project is whether or not I’m trying to branch out too much in regards to too many unexplored areas in a single project. Now, these are things that many people have tried, or may have attempted, in the past, both successfully and unsuccessfully. Whether or not I’ll emulate the path of success has yet to be determined, but I hoping for the former.
I’ve been trying to compose and create music for quite some time now, before game development, so the musical experiments may be the area that I am currently the most comfortable with. What I’m trying to do can actually be compared a bit to a previous project, Tone Def: Revenge of the Square Bots (sidenote: I think that game is actually going to be a free game with volumes added at later dates…..). TDROTS required a bunch of music shifting and blending. Music had to fade in and out, while sounding good. What was easy about this, however, was all I needed to do was create individual song which could basically be stripped for parts as I put them in the game. The song would be composed, then I would import the bass track, the harmony tracks, and the melody tracks separately. When you would start playing, you would know that there was something missing, thus, leading to a more rewarding feeling when you eventually progress far enough in a level to where the entire song is playing. Normally, this meant that you were doing well in the game, so in addition to receiving the explicit rewards of a job well done, you were rewarded with a full musical piece which enforced the success of destroying your enemies. On the flip-side, when you did not perform as well, the songs felt rather empty and lonely, begging to have a harmony or melody to accompany it.
Now, with the new project, I’m starting out in a slightly similar position. You still have an effect on the music that plays in the game. However, the music is not a secondary indicator or whether or not a player is doing a good job or whether they’re failing. Rather, the music corresponds to a certain option that the player has picked.
To explain in more detail, there are two players in the game, and they each have the same set of options. For now, let’s call them, Red, Green, and Blue. When a player chooses Red, then they will hear track 1; green plays 2 and blue plays track 3. Players can cycle between these options as often as they would like, and the tracks would follow them as they cycled the colors used in this example. They could even both choose Red, and both have track 1 play at the same time.
The experimental part, for me, comes from trying to create a song that will sound like a complete musical experience as long as it always has two tracks playing at the same time. This means that any combination of two tracks will need to complete the auditory experience. The individual tracks need to be compelling enough as to where it can be played with the accompanying drum track (which is played throughout an entire song, regardless of options chosen) and stand on it’s own. However, if also needs to be compatible with a different track, for example, if player one currently has Red, and player two currently has Green.
I’ve also placed a few restrictions on myself in order to try and keep this from getting out of hand. I have a tendency of making things overly complicated, and the same goes for songs. It may start with adding a bell or two, and end up with multiple synths paralleling what the strings just played, except, this time, in time to the new drums that came in halfway, as opposed to the original set of drums. Instead, what I’m planning on doing is always have a drum track that plays consistently throughout a level, have a bass track as a musical option, and have a melody/harmony mix, either composed of one or two instruments. In the song I’m working on now, I have the drums and bass, while the melody and harmony are handled by the same instrument.
In addition to the tracks complimenting each other, they need to be shuffled in and out rather quickly, akin to a DJ mixing up an individual track. Quite often, a DJ will take out the bass of a song, or the vocal melody, which simplifies a track, while still keeping it interesting. Or they may mix in the harmony of a different song to the one that is currently playing. What I need to do with this project is balance them both carefully. Furthermore, it needs to be determined whether or not this musical shifting is actually something that fits in the overall game, or just sticks out like a sore thumb, detracting from the entire experience. I will say that during some moments, such as when both players choose the same colors, the track playing does get amplified, since there are two audio sources playing the same track. It seems to create the feeling of, “Hey, there’s something a bit more direct that we need to take care of”, and it actually does reflect the current state of the game if players find themselves forced to pick the same option.
But that’s it for now. I do hope to continue this musical experiment, and really do hope that it is successful. Of course, only time, and play testers, will tell. Over the next week or two, I may put up some samples of music that I’m working on for this project.
How to develop a game solo
April 10, 2013 by Shawn · Leave a Comment
So, currently, I am an independent game developer. At the moment, I handling all of the aspects individually; art, code, music, etc. And it’s fun. I definitely enjoy it, even though I haven’t been doing such for too long. Over the days of development, I’ve learned a thing or two about how to develop a game on my own, and I’ll continue to learn everyday. Here are a few things I’ve picked up.
One of the most important things I’ve learned on how to develop a game solo is:
Don’t.
Don’t do it.
Now, that’s a pretty odd thing to say, especially coming from a person who is currently doing things on his own, and enjoying it thoroughly. But I don’t do it alone. It’s important to find a community, even if it’s just one or two other people. Fortunately, I’m lucky enough to live in Philadelphia, where there’s an ever growing group of people creating games every day. We even have weekly dev nights dedicated to such, and there are new people who attend each and every week.
A community is great for a number of reasons, in terms of growth for your game and independent works. Honest feedback can be found among any of your peers, as long as you’re looking for it. Developing a game for too long on your own can create all types of vision issues. Elements of your game may seem terrible or nonredeemable , but if it’s looked at by a different set of eyes, then maybe you can gain feedback on how to fix the element to make it something game worthy. It may not even be a major detail that needs to be fixed. On the contrary, you may have something in your game that you feel is the most amazing feature that has even been implemented. A fresh set of eyes and hands can inform you that what you have is actually the complete opposite, and quite possibly something which requires heavy fixing. Of course, positive and negative feedback should be taken with a grain of salt, as opinions and preferences vary. Regardless of level of agreement, feedback will open eyes to a new set of ideas, potentially something you wouldn’t have been able to think of in solitude.
A community can also be a fountain knowledge. Whether you’re just starting out, or you’re a seasoned veteran, there are going to be people around you that know something that you do not. While the internet is great for learning and gathering information, a community of people may be able to provide better assistance, as opposed to a forum post from CoolGamerDev12212. Not to say that forum post of useless or unhelpful. I have had a number of questions answered by looking at things on forums. However,a lot can be lost in translation over the internet, which can be easily be explained in person. Not to mention the rate and speed of a response is commonly higher.
Now, if you’re unfortunate enough to be in a low game dev population, then try to stay connected via the internet, via Skype, IRC, etc.
But enough about communication. It’s important, but there are still things that you’ll need to manage on your own. If you’re working by yourself, be sure to plan your project accordingly. This goes beyond a design document. I’m referring to planning development days, and if you can to some degree, weeks. Don’t set up a simple To-Do list, rather, set up a list of things you want to do, when you want to have them done by, and organize them based on sense of urgency. Put some of the more important task at the top of the list, or in the urgent pile. Put the less important things at the bottom of the list. Then, take the task that aren’t necessary, but more along the lines of ‘fun for me to implement’ in another list, and don’t touch them yet.
What I like to do, which is something I stole from groups of others, is work in two week iterations. I set up the two weeks to accomplish a reasonable amount of task or issues, leaving room for potential inevitable bugs that are discovered during my development. If I manage to accomplish those task within the scheduled time, then I dip into my list of ‘fun for me to implement’ task list. I will admit, from time to time, I go into that list before I should, and more often then not, when I do that, I miss a deadline that I wanted to reach. This could be due to a number of things, and the amount of time I spend on each task.
Speaking of amount of time, find a way to track your time. If you know how much time you spend doing certain things, you’re more likely to manage your time more efficiently. If you find yourself spending 2 1/2 hours on something that you estimated to be a 20 minute task, then maybe you should step back and re-evaluate what you’re doing. It’s also great to measure your growth. Maybe the first time you worked on a new system, it took 3 hours. Then, the next time you implemented a similar system, 2.15 hours. If anything, it will (hopefully) provide a sense of motivation, along with a way to measure some of the progress you’ve made in development. Finally, the next time you work on a similar system, you can estimate how long it will take you, and plan accordingly. I’m pretty serious about my time management, and maybe others aren’t. Some people may be more relaxed, and others may need more structure. That’s a balance that you’ll be able to find on your own.
There are a bunch of others things I could mention, such as not locking yourself up indoors for days straight to work on your projects. Yeah, it’s a common stereotype that computer type people are introverts, but if you spend all of your time just working on your game by yourself, and don’t spend any time experiencing anything that the world has to offer – in real life, not behind a screen – then the your game will only go so far. Actually, this applies to life as well. Go out, and do something non-game related, maybe something physically active.
But that’s it for now. I definitely try to practice what I preach, and I’ll admit, it’s easier said than done. But when it is done, the benefits will be visible and have a positive impact on games and life.
More March Work
March 20, 2013 by Shawn · Leave a Comment
It’s been quite some time since an update.
PAX East is this weekend, and GDC is next week. I cannot make it to GDC, but I am attending PAX East. While I’m not part of any official booth, I do plan to try and get people to play Rainbow Bacon while I’m there. And maybe a new project which I’m currently trying to name. Hopefully, I can think of a better one than what I have now. In the meantime, here’s a temporary interface for Rainbow Bacon:
A pair of Rainbow Bacon videos
February 22, 2013 by Shawn · Leave a Comment
I’ve been lazy with updating.
But not with working on things! Here’s proof!
2012 Recap
January 10, 2013 by Shawn · Leave a Comment
Whoops. Looks like I didn’t have an update in December at all.
To be completely honest the end of the year could have ended better, development wise. Things started to slow down for a number of reasons, the main issue being that my main laptop started to die. As of today, the files are completely backed up on to an external HD, so when I finally get my new machine back, which I recently turned into a brick because my brain said”I know what I’m doing”, work will resume. Hopefully, I’ll be able to meet the newest deadline. More on that later.
Recapping 2012, I’ve made progress with making games, and actually learning how to make games. Of course, the only way to slowly increase the brackets of what you know is to practice, and to continually work on things. A couple of new projects were created, ones that will be turned into full-fledged games.
One of those projects I want to finish
There are a few things that received a lot of work in 2012. The first one being Tone Def: Revenge of the SquareBots. Most of the year had time devoted to this project. Thinking back, I feel as if I haven’t made as much progress as I would have like to. Still, I consider myself a ‘newbie’ game dev, and I haven’t figured out the best pipeline in regards how to get things done. This needs to change, and time needs to be managed more efficiently. While I do use Redmine to track how much time is spent on a task, I don’t take advantage of the boxes which allow me to choose an estimated time. The best use for this box, at least, for me, is to plot out how much time I want to spend on game elements. Of course, bugs and related issues will get all the time they need, until they’re are eventually squashed. Currently, I feel as if my work flow has gotten much better, and it’s easier to define goals and realized what is necessary for a game to feel like a game.
That’s mostly due to the end of the year work on Wiggity Wings. This started as a practice project, where I wanted to provide guidelines for a game based off a dream. Long story short, the only things I could remember from the dream were wings, bungee jumping, and wigs.
Not seen in this photo: bungee jumping, bird poop, lightning, giant brains….
Now, the goal was to have Wiggity Wings out by December. The next goal was by the beginning of January followed by late January. Now, with all the computer issues I’ve been having lately, the new goal is February. The first goal was missed, mostly due to feature creep. I wanted development time to be short, but there were a few thing that needed to be included. I initially intended to work for two weeks on specific ‘larger’ elements of the game. That fell through.
The second deadline was missed, partially because of feature creep, then because of hardware issues. The third deadline missed was all due to hardware. Still, the development time for this is going to be much shorter than Tone Def. The goal I have after Wiggity Wings is finished is to have two projects in an active development cycle. One will have a short development period, the other, a larger one. This should be beneficial to how I work, and the amount of time currently available on a daily basis. The longer project allows me to fulfill the desire to create something complex, something that needs a lot of crafting and fine tuning. The shorter project will allow me to be impulsive, a little strange, and allow me to practice different programming techniques, which in turn, will help me with the larger projects. Already, some elements have been taken from Tone Def, put into Wiggity Wings, made better, and have been or will be injected right back into Tone Def, making that game (hopefully) better. Right now, the next long and short projects are lined up. The next short project will overlap with Tone Def, after Wiggity Wings is finished, then once Tone Def is finished, the new long project will then take its place. This goes for all aspects of each project, including art, scripting, and music.
Ah, the music. In case I didn’t mention it (I did other places, but I’ll do it again), Wiggity Wings is going to have what I hope to be a fun soundtrack available for download via Bandcamp. The game will be free, but the soundtrack will be either $3 or $4. Before the hardware issues, I sat down, and made a number of updates to the soundtrack. Now, all of the musically completed songs have been balanced, hopefully for the better. I’ve heard a couple of good things about the soundtrack at MAGFest.
Ah, MAGFest! There’s a lot I want to say about that, but it needs it’s own post.
So, that’s it for now.