welcome aboard.
in progress: SWARMAGEDDON
dr. bobby english
-> design & development
snickersnacks
-> design & ux/ui
condard
-> business dev & music
scott vigil
-> art & animation
keith
-> lead dev
dan awesome
-> production & sfx
@BoulderDefends Twitter
SIX was a success, thanks to everyone who came out and played the pre-alpha demo. We are in the process of masticating all your delicious user feedback morsels and will be back with more updates shortly!
Brand new logo for our upcoming game Swarmageddon hot off the press!
The Boulder Defends crew will be premiering a demo of Swarmageddon at SIX on Sept. 1st (that's Labor Day) so if you're in Seattle for PAX, be sure to come by SIX on that Monday and check the game out!
We'll also be hanging out at PAX Prime on Sat and Sun, come find us! Look for the giant bug cosplay no cosplay this year, just your average humans handing out flyers.
Not much to report yet, just wanted to show everyone a hilarious bug in this build: mini-versions of the boss forming an uncontrollable conga line across the map right in the middle of the game.
This is my first time working closely with a team on a gaming project. In the past I've either been doing it solo (and contracting out for the work I couldn't do), or working remotely with someone else. And let me tell you, being able to sit in the same room as your team is really the best plan.
I'm a developer, and like many skilled professions, developers seem to get hyper-focused on the specific project or feature they're working on. This is awesome the majority of the time: I can grow the entire design tree of a game we're working on in my head, knowing what branches I need to change, and what I need to retest when implementing a feature. I can see various ways to implement a feature and the performance hits or usability problems accompanying them. However, in the midst of all this technical botany voodoo, I sometimes forget about this little thing called fun.
Swarm is our current project: a sort-of tower offense, bugs vs humans game for PC/Mac/Linux. As I was implementing bug units dying from human turret damage, I had a lot going on in my head. My plan was that on death, a bug unit would do a couple things: remove its script to release the associated memory and CPU power, remove the collider to prevent taking further tower aggro, and have the corpse of the unit fade from the screen over time. When I got the death animation from our artist Scott Vigil, I dropped that in and then added the "destroy" code so it would be mostly functional, for stable build purposes. And I ended up with this:
Deep in Developer Mode, my first thought was, Hrm, I need to check the Dead flag on the bug and switch targets on the turret. But as I showed the in-progress feature to the team, the immediate response was laughter -- "That guy really wants to make sure that bug is dead!"
So, as bugs become features, we ended up leaving it in the game.
Our team on this project is taking a lot of inspiration from Starship Troopers, so this tower behavior fits right into the feel we wanted our game to have. There will have to be a bit of tweaking around how long they keep trying to murder corpses. (Brevity is the soul of wit, after all.) But this is a bit of flavor in the behavior of the game that none of us would have necessarily thought of -- and would have disappeared had I not been working in the same room as my team.
As a developer, I can always do more to keep fun and the end-user experience in mind. We only have one perspective to give, and it has been my experience that some of the best features are entirely unintentional. All game devs would do well to remember to keep our eyes open as we develop our games and look for serendipitous opportunities to let the game's personality evolve naturally through the development process.
This last weekend was the conclusion of a month and a half of running full steam ahead without looking back, until now. All for the chance to compile a playable demo for a submission to the PAX Indie Megabooth. And running full speed as a whole team has the tendency to look different for each person involved. Here's a peek under the hood at how Boulder Defends works together.
Snacks got laid off from her job 6 weeks ago and has been building and learning and building and tinkering with the elements almost every day. Dr. Bobby English has been applying his coding and problem solving on the off hours of his free time putting together the grand scheme with Snacks. Keith, who hates fun, has been building a lot of the framework and prototyping the new features we've been implementing in long binges. Scott, who handed us the "finished" artwork for the game has had his hands full with drawing, normal mapping, and getting neck deep into animations with all the extra stuff we had in mind on top of what was initially thought as complete. These four have really put everything into these past weeks and have built some incredible stuff.
But like I said, full steam ahead as a team has all sorts of other elements to it. Dan Awesome, long time friend of the team, saw our need for a new SFX guy and jumped right in after moving 3 days prior back to Seattle from Wyoming. He pulled the sound effects together in a matter of 4 or 5 days. Renfrow and I composed the concept for the music, and went with original arrangement on a random Saturday. As deadline was pressing in I found myself downloading Audacity to cut loops for the game (it's always a matter of time before I download audacity onto a computer). Meanwhile, I'm also having conversations with the team about needs and ideas as we begin to piece together the ramifications of turning our rag-tag group into a company and getting the silent nod from the state that we are indeed in business.
I share all this because these observations have been a learning moment for me as a non-coding/part time music/fill-in-the-blanks type individual with a drive to do big things on a team of ambitious people. I have a very full schedule. and for the past year as I've been working with Bobby English and Snacks I've been in the limbo of asking the question, "Where do I fit here?" I want to feel like I've done my fair share, but this isn't kitchen duty after a family meal, it's making games. I've learned first-hand that undefined roles with skills for filling in can be helpful. Rob and Snacks 3 weeks ago addressed this existential concern of mine by asking where I thought I fit into the scheme of things. My outward skill set is music, brainstorming, and making seemingly small things complicated in brainstorming sessions, but my greatest asset to the team is finding the right people for the jobs at hand. In other words: networking, building relationships, asking questions about the future, and figuring out how to fulfill the answers those questions raise. It's an important role and it's always shifting.
This last weekend I gained more experience in game design than in the last 6 months of software testing combined. As we were reaching the deadline for the Indie MEGABOOTH submission, I believed I wasn't going to be able to be of much help with anything since the work at this point was pretty technical, but knew I could be helping with testing. Going into this weekend, I was still seeing the work that needed to be done in terms of hours put in rather than the process and people involved. This is unhealthy carry-over from working at game studios off and on for the past decade that treat time sheets like the words of truth themselves. I learned so much this past weekend because I began to see gaps in the operations that needed filling. The closer a deadline comes, the easier it is to see the gaps. The farther off the deadline is, the pieces that are missing are harder to identify because they are still coming together. Worthwhile experience applied is knowing where those gaps form earlier and earlier ahead of time, not just years worked in a position. I chimed in all weekend with various questions asking about elements of the game and our plan for the submission. It turned out there was more to be done than simply testing to fill time and have my hands busy.
The real learning was in the last day. Particularly the last hour and a half. It was the identification of operational needs that were overlooked or put off. I began to see where I have been missing in the weeks and days leading up to the deadline. Most of my conversations with the team have been confirming that gaps have already been filled. Here's a sample of what most of my conversations looked like. In most cases, whatever I was asking about was already taken care of:
condard is there anything other than the build and the 3 minute video we need to have together for submission? Or is it all queued up
snacks we’ll triage and see what we have time for
condard good, I’d hate to be stuck on something like the bio
snacks i’m finishing that stuff right now in the submission
And then it happened. I asked a question an hour and a half before submission that made alarm bells go off in my head and my heart begin to race when the answer came back.
condard cool. how long does it take to compile a build into an .exe?
snacks no idea
condard I’m going to do it now. I’ll let you know what I find
I know it looks calm in text, but I was freaking out. This was my fault. Not the team's. Everyone has been going hard for days, I've been putting in a little time here or there still figuring out what operations manager meant for this team in the midst of it. I wasn't asking enough questions. If the corporate monkey game tester in me was in the driver seat when I heard "no idea," a list of criticism and things we need to do better would have come out of me. But, this was operations manager time. Does the team have everything they need? In big huge letters across my brain: NO IDEA. Yes, I do not fit the bill for coding, or working the way this team does, but this issue is totally my jam: Support the team.
A nightmare began to form in my brain of the build not building or taking 2 hours, or critical pieces being missing. Keith or Rob may look at that and say "nah, we knew it was going to be fine." But from my vantage point, this would be where disaster strikes. I did what needed to happen to test if a build worked, rather than ask Snacks, Bobby English or Keith to stop what they were doing. Fortunately, the build built in 2 minutes and ran like a dream. It ran better than when it was ran in the Unity Editor. I also realized there was a whole tool for testing that hadn't been considered complete with developer tools like logs. And at once, I saw where I fit. I saw a hole in the team that I could fill. My day may come where I am up until the wee hours of the morning and everything is relying on me. But until then, my job is support those upon whom it does rely so that their efforts don't fall flat on their face.
It's not all rosy, though: around midnight I get on the phone with Snacks and I see too late, an issue that should have also been on my radar -- the video capture software we were set up to use hadn't been tested and it could only record a couple seconds at a time. Snacks and Keith had it covered with a dramatic drive to Keith's brother's house to use his recording software. But it reinforced again where I belonged and where I had been missing.
And truth be told, if I wanted to get away with doing as little as possible, operations is a great place to feign ignorance and get other people to do work and just take credit for the decisions that were awesome. Despite my shortcomings I saw in my role, I haven't heard any criticism. I think it's what programmers call a silent failure. That's not why I'm here, though. From my vantage point as I write this, the job of Operations Manager is a role that succeeds and fails silently. The errors are often seen in the ramifications or in the operations themselves. We don't learn from silent or unacknowledged mistakes and it helps to know when something was a success for a reason other than dumb luck. So pardon this long post, but I think the set up is necessary for me so I can put shorter posts about failures and successes.
All in all, we got the submission finished, despite the rough end, thanks to the hard work and smarts of a great team. My view was opened up. Being operations manager isn't just taking care of the stuff like the business license and seeking out information for building a game studio. Sometimes that's questions or statements. Other times it's figuring out the seemingly insignificant details like whether the video capture software we have is going to work when we need it. But more importantly, it's serving those who are putting the talent into the project in ways they likely are not going to ask for. It's sharing the vision and goals of the team while using the outside perspective of a person not in trenches of coding and merge conflicts to support those that are with selfless decision making.
Almost all of the art assets in Swarm were originally done by Scott in Zbrush as native 3D, but Swarm itself is 2D top-down. We wanted to tackle lighting the evironment in a realistic way to match the realism of the bug units, the turrets, etc. Here's a peek at a shader art test we did earlier this week...
All of the above is thanks to the black magic of normal maps and a lot of shader tweaking.
There are some snapping issues on the lights attached to the flamethrower, you can see it mostly on the buildings just on the extreme edges of where the lighting is cast. The overt shininess of everything is due mostly to how close the lights on the flamethrower are sitting on the turret object.
And the lighting within the environment itself will change over time: we'll simulate light cast by the various planets, moons and sun in the planetary system Swarm takes place in, depending on whether it's morning, high noon, sunset, or night time. Lights cast by enemy human outposts, towns and cities will also help shape the light-scape.
Once basic gameplay mechanics have been established -- what the player can and can't control -- we give the player 1) a view of the active gameplay area, and 2) a means of interacting with it.
Swarm's basic mechanics are as follows:
Compose custom waves of different unit types
Direct units down branching pathways
Capture new nests that provide access to production of new units
Spend "Rage" to buy upgrades for various game components (e.g. bug units, bug nests, timers(!), etc)
Unleash a big nasty raid-boss bug from time to time
Pretty simple, no?
Tower defense as a genre itself is a derivative of classic RTS, and tower offense is the natural inversion, so now would be the time to take a good look at my favorite RTS HUD for inspiration:
Starcraft 2 does a pretty good job of conveying a lot of information in as little time as possible, suiting the pace and complexity of gameplay. The simplicity of the Diablo 3 HUD was particularly inspiring, and prompted me to take a hard look at opacity of elements on the screen that overlap active gameplay:
And we can also take a look at some other popular PC games for fun:
League goes against the grain and puts the mini-map in the bottom right-hand corner. If anyone recalls, the League of Legends early beta had HP/SP bars more centrally located and very prominent, but ended up sacrificing them in favor of bringing spells front and center. Arguably, and speaking from experience, League players tend to get their health/spellpower info from the bars directly above their character's head, since that's where they're already looking most of the time.
DotA2 has the more prominent character portrait and health bars, and keeps team portraits along the top. The mini-map is lower contrast than the League map. Chat isn't always visible by default. (Are you taking notes?)
While we're at it, let's also look at Anomaly 2, arguably the most popular tower offense game:
A lot of intentionality was put into the previous HUD designs, whereas Anomaly 2's HUD seems like an afterthought: some of the icons are confusing as to what they represent (e.g. the wifi-looking icon), and so then a lot of text is being used almost everywhere on the screen to convey game information that could have been better visually represented.
While the overall alignment of geometric forms draw the eye to the left, the button elements themselves are floating in space instead of portraying depth, despite their angles of questionable perspective. And where's the lighting in the HUD coming from? The drop shadows and shading on all the buttons can't seem to agree.
Anomaly 2 minified the graphic elements themselves in favor of keeping more action visible on the screen, and rightly so to feature the impressive gameplay graphics.
Here are some of the above HUDs as thumbnails of their most important elements to better draw a distinction about how much screen real estate the various elements are taking up and what they're doing for us:
All of these different thumbnails have a similar feel to them, and a lot of that feeling is driven by where your eyes naturally look for specific kinds of information. You might already know where to find the mini-map, or your player stats, or where the chat console might be even though you can't tell which black box is what exactly.
Player expectations should influence design: the RTS and ARPG genres (among others) have established rules about where certain elements are anchored. Now, whether these HUD compositions are working for them or against them is dependent on a lot of different things -- I can tell you right now the lateral DotA 2 HUD doesn't make sense for core gameplay oriented on a diagonal playing field -- but the point is that placing elements in intuitive places matters.
Your players are bringing with them their own expectations about how games are played, and where it makes sense to find information: the mini-map is "always" in the bottom corner. Deviating from these expectations means have to teach players how your HUD works on top of how your game works, so it might actually add to the learning curve and difficulty of your game simply by being counter-intuitive to their expectations.
Now that we've done our research, taken lots of notes, and made that list above of what core game functionality the HUD needs to provide the player with, let's sketch out a draft of Swarm's HUD. For the first iteration, some important things to note:
It doesn't need to look pretty yet. Let's get the composition and placement of the HUD working for us first, and our artistic flavor can come in after functionality is locked down.
If it ain't broke, don't fix it. Following and setting user interface expectations should be with the intent of never deviating them needlessly, e.g. the now-standard operating system UI button you click to close a dialog box should always be found in the upper right-hand corner and always look like an X (unless you're Apple).
Keep it simple. Buttons, buttons everywhere is a great and immediate answer for controlling all the things, but we don't need them until we need them. There's an important distinction between what needs and doesn't need to be visible at all times. We're here to see some action, so let's keep the HUD as unintrusive and uncluttered as possible.
Show, don't tell. A picture can tell a better story and with more flavor than pixelated text. Having the player read a word to access basic game information forces them to seek out contextual information to support the semantics of the word, instead of providing the player with a visual cue they can recognize and understand immediately and completely.
Here's the first mockup I made:
Swarm lets you control wave composition, but for the sake of using colors and ratios to visually represent information, I've almost completely removed numbers from the HUD and given the player silhouette icons of every type of unit available. If you were pursuing a more minmax-friendly game catering to players who love mathcrafting and build theory, we would want a space to display detailed unit information (e.g. Starcraft), but Swarm is targeting a more casual video game player, so it's not necessary here. We want you to focus on the awesome (and eventually beautiful) action happening on the screen.
Of course there are some immediate problems I can see with this iteration:
Adding/subtracting units incrementally from your wave composition isn't visually represented. In our build right now, left click adds and right click subtracts, but there's no way of knowing that visually from the UI.
Clicking on a path intersection to direct units down different forks in the road requires a leap of logic -- same problem here, the path intersections don't even look don't look clickable, so visually we wouldn't assume clicking there does anything.
Some of the bug unit silhouette buttons aren't actually all that easy to distinguish from one another.
No visible "release the kraken" button implemented for the boss bug unit -- only relevant in mid-to-late gameplay, but we'll definitely need one somewhere.
(There's also a fundamental design mistake or two I intentionally left in here to see if anyone catches them -- comment below if you think you know what they are.)
This first draft is definitely not perfect, but it's already doing a lot of good things for us that facilitate overall gameplay. We can easily compose the next wave of units, there's a bar for upgrades to the side, we know how much time is left before the next wave is released, and so on. All good things!
I will be playtesting with the HUD design in situ as we continue adding features, do some user testing with friends, and then dial in the UI later when I know better what a player's needs really are: information we want to see but can't, buttons we want to be able to click on, and what necessitates temporary HUD elements such as in-game dialog events.
I have been programming a long time now, but am admittedly lacking in at least one key area: math. I just never learned much past algebra. I was "present" for a few levels of classes above that but nothing really sunk in. Due to this, I'm often forced to find more complex ways around problems I could easily solve otherwise. This is one of those problems.
One of the projects we're currently working on is a tower defense style game, but in our case, the computer is the one placing the towers. The biggest challenge here is instructing the computer how to place towers intelligently. An important factor in intelligent placement (among many) is assessing the point at which the highest amount of path area is covered within the given tower's attack range.
Manually rating each position for every level sounds like tedious hell, not to mention making user testing much more obnoxious. The first way to do it programmatically that comes to mind would be to test each position to see how much of the path is within the range of the tower. Our project's path system is node-based, e.g. Node1 connects to Node2 via a straight line, and the path increases in complexity as units follow the path: Node2 may then connect to Node3 as well as Node4.
As a programmer, this should set off the recursive alarm in your brain. I personally removed the battery from that alarm many years ago, but recently a boss of mine convinced me to put it back in, and lo and behold, recursion actually simplifies a lot of game design problems.
So, first we need to get the distance between our node and all the nodes that are linked to that node. Then we need to get the distance between each of those linked nodes and each of their own linked nodes... recursively! I split this into two functions:
So we're addressing each line segment between two nodes individually. This presents 4 possible scenarios to handle. (Reversing A and B technically give 5 scenarios.)
1. NodeA and NodeB are both outside the tower's range and their line segment does not intersect our circle:
2. NodeA and NodeB are both outside the tower's range and their line segment does intersect our circle:
3. NodeA and NodeB are both inside the tower's range:
4. NodeA is outside the tower's range and NodeB is inside the tower's range.
I know that mathematically there is a way to find the point(s) where the line segment intersects the circle given all the data that I have, but I didn't know what method to use here. After an hour or so googling around and trying a stack overflow solution I gave up on doing it correctly. Instead, I decided to use Unity's built in physics to do the job for me.
I create a gameobject at the position I'm going to test and add a CircleCollider2D to it, then check to see if NodeA is inside the collider. If it is, then I use that as the starting point to measure from. If not, then I raycast from NodeA to NodeB and use the first collision's point. I do the same in reverse for NodeB to NodeA to get the ending point. I take a Vector2.Distance between the two, and that gives me the length of the line segment between NodeA and NodeB which is inside the circle -- even if both nodes are themselves inside the circle. If both are outside and there is no hit on the raycast, then I disregard.
Prior to actually programming this out, I assumed it was going to take a ridiculous amount of processing power to do all these raycasts. I figured that these calculations weren't going to change during gameplay, so I could just run them once and store them for the whole game. Turns out though that on my MacBook (admittedly an i7 cpu) it doesn't even cause a frame of lag. I made it a coroutine and a frame every row of processing just to be safe.
This ended up being a surprisingly usable solution. It would also work for 3d where I assume the maths would be more.. mathy (see: less accessible to more people). In programming there's always lots of ways to do things. The best plan is to be honest with yourself about your strengths as well as your weaknesses and write something readable.
SkyManta and the World of Tomorrow (Ludum Dare post-mortem)
Ludum Dare #29 Entry: SkyManta
Released for: Browser | Windows | Oculus Rift
Idea
For some reason Zite and I were listening to Anamanaguchi's Endless Fantasy on the way back to downtown and that song always makes me feel like I'm flying really fast, so I suggested a runner. It was one of the first ideas we both had, but Zite was trying to overthink it as usual, and while there were other terrible very bad ideas1, this runner game was the one that stuck. I have no idea where the manta ray thing came from, but it seems like a logical leap. They look like they could fly pretty fast, right?
Zite didn't want to make a 2D side-scroller -- "If I see another pixel art 2D side-scrolling platformer I will murder the world" -- so we talked through the first iteration: a reverse runner in a fixed lane moving toward the horizon, constantly speeding up as you dodge or shoot at bad things and use the water as drag for slowing yourself down (suitable for the "Beneath the Surface" theme).
Process
My personal goals were for this to be both a learning process and a test of whether Zite and I could reasonably work together. The two of us settled on a first iteration and got to work. Virtually everything game-related I've done has been in 2D, so this necessitated me learning how to model, rig and animate in Blender right off the bat as fast as possible.
Zite stayed up all of Friday to build out the first working prototype while I slept a blissful two hours. I spent most of the first 24 hrs editing the manta ray model heavily and then learning how to rig from scratch. We reconvened after the prototype was done to talk about what was working and what wasn't in terms of the camera view, where and how the laser was firing -- leave all that graphics stuff for later because it doesn't matter if the game doesn't fundamentally work.
Sleep deprivation began to set in and design decisions came down to whether it passed the "does it sound like a good idea?" test. I made a list of all the features we talked about, culled the nice-to-haves from the core functionality, and prioritized: character attacks, enemies, the Octopod boss, and whether it would port nicely to the Oculus Rift. When time's a limiting factor, two separate lists of "must haves" and "doesn't significantly impact core gameplay" make a great mini-map of priorities.
We playtested throughout the game jam, made sure you could both win and lose and talked through what both a lose case and a win case look like for the player. Bug fixes, last-minute tweaking and things breaking prevented us from working on other more important things (which were brought up over and over again by submission reviewers after we submitted).
What worked?
Iterate, iterate, iterate. We talked through design features in a ruthlessly objective fashion. Sometimes it's hard to let a bad idea go, but Zite and I are socialized enough we can be up-front about bad ideas without it sounding like we're hating on your whole life. Goal of working together well met!
The graphics turned out surprisingly nice, thanks to freebies on the Unity Asset Store and elsewhere. Zite found a pretty decent ocean prefab and sunset skybox, I found the manta skin texture and the Octopod boss guy came pre-made (wow).
The pre-made assets saved a ton of time in the face of me needing to learn an entirely new program from scratch. I grabbed the models and altered one of them heavily, learned how to rig, animated keyframes, and imported everything into Unity. I ended up watching around 30 different tutorial videos and reading countless articles. Blender's hotkeys and UI are something out of a design nightmare from 1998, but I was in "go big or go home" mode. Goal to learn something definitely accomplished.
The logo was super fun to design, A++ would make again.
What didn't work?
Halfway through, we realized we didn't have a story for why any of this was happening. Who are you, little Sky Manta, and where did you come from? Sleep deprivation didn't exactly come to the rescue on this one either -- keep it silly, or make it serious? In the figurative 11th hour, we decided it was more important to nail one instead of do both poorly. Which one we chose to accomplish is left as an exercise to the reader.
Sleep : good work :: caffeine : this game.
I easily wasted two hours at one point trying to figure out why textures weren't showing up on the models I imported until I realized I was missing that whole UV wrap step, apparently that's pretty important!
Probably don't use game jams to learn how to do basic, major things like 3D modeling or rigging. Unless you're ok with your project coming out like ours, which in that case shine on you crazy diamond.
Really wanted to make gifs of gameplay to show people but that never happened. :[
User feedback
The aiming was pretty universally annoying, so we tweaked the player character positioning and the angle of fire to dead center of the screen. The "pew pew" sound effect also got annoying fast, and we really should have replaced it before we submitted, but oh well.
I'm glad people are finding it as fun to play as we intended!
Thank god this post is almost over
Zite: I'm done. I am done now. If someone told me that they were going to set the whole world on fire unless I fixed another bug in this game, everyone would be dead.
We ended up porting it to the Rift because Zite has one. It felt really cool to be inside of the world we had just created, the ocean looks awesome and somehow it just feels more natural to navigate the game world we made in the Rift as opposed to on PC, so if you have a Rift you should definitely try it out.
I'll definitely be doing a game jam again in the future -- it's been a great way to force myself to work and make games in ways I usually don't. Yay learning! \o/
[1] "So... you're a puppy that's being drowned, because... there are too many puppies. And you have to use the QWOP keys to struggle with your little puppy arms so you can get up to the surface and breathe."
After you've settled on a compelling idea for your game, one of the first things I like to do is slap together a functional prototype because of one make-or-break feature: mechanics. A game "feeling right" is influenced by the graphics, soundscape, timing of everything, and how the player uses the controls to interact within the game world (among other things).
The first three take time and a lot of iterations to nail, and you might not even know what you need to dial in until you get the feel of player interaction down -- lots of misguided asset creation for a game that will never exist. So, for me, being able to feel my way through the design of a game by interacting with the mechanics is like giving myself a compass that will point me toward good design decisions.
The prototype of SkyManta that Zite put together in the first 10 hours of Ludum Dare was a huge first step in the direction of being able to make informed design decisions based off our own user feedback: do the controls feel right? Does the visual feedback of motion and movement make sense compared against the velocity of various game objects? You make a great playability tester for your own games -- if you're making a video game, it probably means you've also played a lot of them!
Once the world begins to come together, you can go hog wild with the graphics, tweak animations, and flesh out the environment with all the little odds and ends that will give your game a unique personality:
Me: "So what are we making?"
Zite: "Dunno. Ideas?"
*minute of silence*
Me: "So, you're a manta ray, right, and you're like flying in the air above the ocean. Because you're a... a sky manta ray. And you can shoot lasers out of your eyes or something."
Zite: "...What?"
The above isn't usually how I iterate. I like to chew on the ideas that pop into my head, turn them over in my mind. But game jams don't exactly allow for being thorough, so how can you quickly settle on an idea? How do you even know if it's worth pursuing?
Figure out what your game idea is derivative of. You were inspired by something: a scene in a game you recently played, your favorite movie, a conversation you had. Go back to where your idea came from and see if additional details jump out at you -- mining what you already know for more ideas will help you elaborate on your concept.
Find your game's limitations. What does the main character do: jump, shoot, fly, swim? Is there lava everywhere? Thinking about the construction of the world your game takes place in and what kind of limitations could exist helps you find tension, and tension's where the interesting stuff happens. Tension can be found anywhere: cliffs you can't climb (without the right shoes), a crumbling bridge (with a massive sword on the other side), the atmosphere is toxic (if you're human).
Ask why. Put yourself in your character's shoes and start asking yourself why anything happens at all. Why am I going on this quest? Why does this city need to be saved? Why should I steal that dude's eyepatch?
Some more things you can do to kickstart the game idea juices flowing:
Accidental conversations are a great creative catalyst. Talk to people about your ideas -- if you're worried about someone stealing your game jam idea (are you kidding me) maybe you should be doing something else with your precious free time!
Draw it out. Even if you can't draw well, get a visualization of what an enemy engagement looks like. Where is everyone standing? What weapons do you have? Drawing out whole scenes helps answer questions you didn't even know you had.
Don't hold back during brainstorming with others. Get all the shitty ideas out. Who knows what ideas you might spark in your game jam partners? Zite and I riff ideas off each other constantly and elaborate on them, even the terrible ones.
theartofmadeline
dededos
andulkaphoto
izzy806
gummygunk