Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    5
  • comment
    1
  • views
    2803

About this blog

The conjoined devblogs of Gabe Priske and William Holly

Entries in this blog

 

Early Art: Finding Efficient Style

[font=arial]Week 3[/font]
Gabe's Game
On an indie team, being efficient with your time is important. As a solo developer, it's imperative. Traditionally, when adventuring into the early artist process for video games, you'll have piles of concept art, mood sketches, character concepts, often even prop art concepts. You'll find an art team deliberating over details in a way an individual just can't. So how am I possibly going to make an attractive game solo? By being strategically artistic. I'm going to build a character. My game is still in its infancy, so character art isn't the most important task on my list. However, this is my review process. By finding a design I like early on, I can see it in action and consider its weaknesses throughout development. Without an art department to critique my work, I need this sort of self-analysis along with community feedback. I want to work with a character that's lovable and memorable. Also, maybe a robot. My first step is to clearly define what I need to communicate visually. I know that I want the player's feet to feel powerful to suggest that jumping off of things is how you deal damage. I also don't want to include text in my game, so I'd like to be able to emote a lot through the character. Generally, really expressive characters require a lot of animation, so I needed to figure out a way around that for this solo game. I came up with this little fella while imagining a character with a holographic iMessage-ish head: So with this design, I can make the head a separate object. I can then animate facial expressions and communicate through imagery projected on the face, all while looping animations for the body. Quick and efficient expression, one goal met. However, the legs look weak and I want the art for this game to be a bit more involved than the above style, so I sketched a bigger version: Closer to what I want, but the legs still aren't grabbing enough attention. I decided to take this design into 3DS Max. Having done 3D art far longer than game design or drawing, I feel more comfortable tweaking a block out quickly in 3D space. I ended up squashing down the body and making it bulkier to better fit within collision boundaries I like. I've clearly amped up the legs, but because I've also intensified his shoulders and hands, they aren't carrying the weight I want them to. The above is a rectangular silhouette, if I want the base to feel like the heaviest point, perhaps a triangle would work better. The triangular shapes wonderfully depict the composition I was aiming for! This design feels way more powerful and deliberate. I'm still able to emote efficiently, the feet are obviously the most powerful part of the body, and I can fit the character within my preferred collision boundaries. Ultimately, removing unnecessary detail and refocusing on the visual information I need to communicate was the solution. I decide to head back to 3D. I'm thinking I want to do 3D flat lit characters rendered into sprites with 2D handpainted environments. My logic is really just that I have plenty of experience with both of those things. I would never recommend exclusively sticking to what you know, but learning to program is enough educational exploration for one game. Ended up throwing in more detail than I had anticipated, but I'm pretty satisfied with how they're looking. I don't want to get too attached to any part of the character this soon, so I've kept them very modular. Preparing for inevitable changes to your art and style is imperative this early on. Gameplay takes priority over visuals, so I don't want to limit myself with something that's difficult to tamper with. All in all I'm off to a good start! The world for my game is now brimming with color in my imagination. I can see an iconic personality for my character and ways to make design points clearer than they could be without him. Best of all, the time commitment to this early character draft was pretty small. Now with a clear vision for my experience, I can really start work on building a world. There is a lot of work to do, so I'd better get movin... William's Comment: I've been waiting to see an art blog post from you this whole time because, while you're quite adept at game design and finding fun in prototyping, art is an area where I frequently find a loss for words when observing your process. Even with super-fast time-saving techniques and a full preparation to change up the design in the future, what you've created has classic design, a world of opportunities for emotion and dynamic action, and a robot look more fun than Keiji Inafune has been capable of since Megaman X. The holographic speech-bubble head especially gives an outstanding contrast which is mirrored in the color design: a soft, cute, baby-blue head with rounded corners, curious bright eyes, and clearly delicate in its holographic artifacting emanates from a a red-and-grey metal, boxy, agile-yet-powerful mechanical hard body. Its body is powerful and hardened, but the personality is curious and delicate. All I've got in my game is a goofy looking skeleton. If I had to give any advice moving forward, it would be to be wary of how you convey perspective in a truly 2D game. In fact, even in 3D platformers the following could be an issue: perspective shots can lead to imprecise platforming. While your character seems to be rendered orthographically, he seems (at least in some images) to be rendered with a non-orthographic world in mind. That is to say, that the character's feet won't be even on the ground. Since your game's prototype shows an emphasis on precise jumping that controls evasion, attacking, navigation, and everything, allowing for absolute visual precision through an orthographic view would be optimal. For the people reading who may not know what I'm talking about: Orthographic projection forces a perspective in which objects are displayed without perspective, usually as having very clear border edges and straight lines. That's part of why games with lots of precision platforming like Super Meat Boy or New Super Mario Bros (both pictured below), or even Sonic The Hedgehog or Megaman keep an orthographic perspective for the most part. When there's a bit of leeway to what can be considered a the collision line of a surface, scenarios with perspective look nice most of the time, but are better suited for games that rely less on platforming and maybe more on combat or collecting items. It's a style typically best for less movement-intensive games like Kirby or Commander Keen (both pictured below). Anyway, I'm merely commenting off of what was likely a test render, but I still hope it's something you keep in mind as you continue your design (confirmed that you were already planning to go ortho after a short conversation in Skype, whoops). If it was something you were already considering, then I hope that at least the readers got to learn something interesting!
Got questions, opinions or cool early game art to show off? Put all of that into the comments! Want more immediate posts from us? You can follow Gabe on Twitter here and follow William on Twitter here.

WJHollyART

WJHollyART

 

Coding a Foundation for Comfort

Week 2
[font='Helvetica Neue']William's Game[/font]
[font='Helvetica Neue'][font='Helvetica Neue'](Post by William Holly - Read More at www.duelingdevblogs.com)[/font][/font]
[font='Helvetica Neue'][font='Helvetica Neue']This week, I began tackling the programming for my game. Hammering out a prototype, as Gabe had started doing a week ahead of me.[/font][/font] [font='Helvetica Neue'][font='Helvetica Neue']A little known fact about programming is that it's actually really easy as long as you can follow logic, understand order of operations, can work within a structured environment, and (most importantly) can use Google to see how other people approach it. To the surprise of those who have never programmed before, code is just a lot of mostly interchangeable instructions written in a very specific language.[/font][/font] [font='Helvetica Neue'][font='Helvetica Neue'][/font][/font]
[font='Helvetica Neue'][font='Helvetica Neue']I'm actually mostly self-taught as a professional programmer. I've programmed since I was 11 years old and it wasn't until I turned 19 that I started my first programming class. Now, having completed quite a few programming classes, there's really only one thing that I learned from them that I hadn't already taught myself: a clean coding environment is what separates professionals from amateurs.[/font][/font] [font='Helvetica Neue'][font='Helvetica Neue']Clean coding is a pretty big deal when you get into professional stuff. People have to be able to read what you code if you're working in a team, and if you're not working in a team you at least want for your code to be clean enough that you can come back to it later and understand it at a glance in case you ever need to implement a patch.[/font][/font] [font='Helvetica Neue'][font='Helvetica Neue']If you have a really good attention span, you can probably pack tons of internal translation for what your code means in your head for a time, but after a while you're going to look back at it and it's going to look like a word search from Hell.[/font][/font]

[font='Helvetica Neue'][font='Helvetica Neue'][/font][/font]
[font='Helvetica Neue'][font='Helvetica Neue']Like this, but hundreds of lines long[/font][/font]
[font='Helvetica Neue'][font='Helvetica Neue']You want to write your code as if you have zero attention span and it's always easy to read the previous couple lines and know where you are. That's why my code in my game looks something like this:[/font][/font]

[font='Helvetica Neue'][font='Helvetica Neue'][/font][/font] [font='Helvetica Neue'][font='Helvetica Neue']That's just a chunk of my programming and it's already way, way simpler than what it needs to be because I effectively break down every programming task into individual working parts, and the script that runs these individual parts is usually so cleanly set up that it reads like a glossary of what each individual sub, function, and macro is useful for.[/font][/font]
[font='Helvetica Neue'][font='Helvetica Neue']That's what clean code should be. It should be natural to follow to its works parts. Now, since I'm still working very hard on the prototype and have little to show this week, I wanted to go over organizing the working parts a bit. It's going to be pretty technical, but unless you're already a seasoned programmer you can't say that you didn't learn anything![/font][/font] [font='Helvetica Neue'][font='Helvetica Neue']So, in my movement code I have a part that looks like this:[/font][/font] [font='Helvetica Neue'][font='Helvetica Neue'][/font][/font]
[font='Helvetica Neue'][font='Helvetica Neue']Remember what I said about good code looking like a table of contents? Now, you can see, in order, the scripts that do each part:[/font][/font] [font='Helvetica Neue'][font='Helvetica Neue']1. Check to see if the user has inputted keys that will affect the player's movement[/font][/font] [font='Helvetica Neue'][font='Helvetica Neue']2. Take the input and communicate it into variables that will determine the player's movement[/font][/font] [font='Helvetica Neue'][font='Helvetica Neue']3. Take those variables that determine the player's motion and actually move the player[/font][/font] [font='Helvetica Neue'][font='Helvetica Neue']4. Adjust the player's depth to ensure that they are properly drawn over objects according to their new location[/font][/font] [font='Helvetica Neue'][font='Helvetica Neue']If you want to update the game to include a new type of controller, you know where to make that change:[/font][/font] [font='Helvetica Neue'][font='Helvetica Neue'][/font][/font]
[font='Helvetica Neue'][font='Helvetica Neue']These broken apart pieces of the code are called "subroutines" ("subs" for short) and the most commonly cited benefit to using subs is that you can cut down redundant coding: instead of repeating yourself, you can just make a sub and execute it multiple times. While that's definitely one use I get out of subs, I tend to get my most value out of using them as organizational tools. It's so easy to get lost in programming, being able to give a name to a specific operation is incredibly handy.[/font][/font] [font='Helvetica Neue'][font='Helvetica Neue']But there's more tricks you can do once you get into something called a "function":[/font][/font] [font='Helvetica Neue'][font='Helvetica Neue'][/font][/font]
[font='Helvetica Neue'][font='Helvetica Neue']That's all of player movement. Pretty nifty, right? 11 lines of code, 3 of which are comments, 1 of which is the function's definition, and 3 of which are totally empty. How is it done so simply?[/font][/font] [font='Helvetica Neue'][font='Helvetica Neue']Well, the majority of the work done for the player's actual movement is in those "player_movement_indvfunc()" functions. Admittedly, I gave this function a bit of an ugly name, but I know what it means at a glance so it works for the necessary purpose.[/font][/font] [font='Helvetica Neue'][font='Helvetica Neue']Within those functions is the following:[/font][/font] [font='Helvetica Neue'][font='Helvetica Neue'][/font][/font]
[font='Helvetica Neue'][font='Helvetica Neue']That 81 line monstrosity (giggling to myself a bit because I know that's not as large as scripts can get) takes the player's movement variables and uses them to push the player through the room, slide along slanted walls, and feed back information about whether or not the player has come to an obstruction.[/font][/font] [font='Helvetica Neue'][font='Helvetica Neue']That's the difference between a subroutine and a function. A sub just executes a cute chunk of code, but a function executes a cute chunk of code and returns a value. You can set variables to be equal to a function, you can compare functions, and you can use functions in an algorithm. In this case, the function is one gigantic subroutine that moves the player along and then returns a value that will determine if the player cancels their momentum.[/font][/font] [font='Helvetica Neue'][font='Helvetica Neue'][/font][/font]
[font='Helvetica Neue'][font='Helvetica Neue']That "if" is taking the function and determining if it will return a "1" or a "0" (or "true" or "false") and setting the variable of "hs" to 0 if the function is "1". This makes the function not only useful in completing an action, but useful in helping the code that calls it to make a decision about whether or not the player needs to cancel their momentum.[/font][/font] [font='Helvetica Neue'][font='Helvetica Neue']So, if you were able to follow all of that, that's how I organize my code. Not only that, but I essentially just gave you my top-down movement engine for the player. Some parts are missing, but if you can follow the logic they shouldn't be too hard to fill in if you're making your own project. It'll look something like this:[/font][/font]
[font='Helvetica Neue'][font='Helvetica Neue'][/font][/font]
[font='Helvetica Neue'][font='Helvetica Neue']Enthralling enough gameplay footage that I made this entire blog post about programming technique.[/font][/font]
[font='Helvetica Neue'][font='Helvetica Neue']I hope you learned something valuable reading this, because lord knows this wasn't much of an entertainment value post.[/font][/font]
[indent=1][font='Helvetica Neue'][font='Helvetica Neue']Gabes Comment:[/font][/font]
[font='Helvetica Neue'][font='Helvetica Neue'][/font][/font]
[font='Helvetica Neue'][font='Helvetica Neue']Meanwhile on my project...[/font][/font]
[font='Helvetica Neue'][font='Helvetica Neue']We would love to hear what sort of posts our readers are most interested in. Maybe you thought this was too technical, maybe you were craving move details. Let us know![/font][/font] [font='Helvetica Neue'][font='Helvetica Neue']Want more immediate posts from us? You can follow Gabe on Twitter here and follow William on Twitter here.[/font][/font]

WJHollyART

WJHollyART

 

Games and Growing Pains

Week 2

Gabe's Game
(Post by Gabriel Priske - Read More at www.duelingdevblogs.com) Much like the process of reproduction, in game design there are a few fundamental pieces that you put together to get things started. From there, the thing grows on its own. You're mostly left to deal with growing pains, college loans and, if you're lucky, a top-selling spot on Steam! Like raising a kid, from the fundamental pieces you put together, a game grows into its own personality. Also like raising a kid, forcing a game to be something it's not makes it turn out shitty.

Over the years, this has been among the hardest design concepts for me to grasp. I often will get so excited about a story concept or gameplay mechanic that I blind myself to the bigger picture. I love donuts and I love lobster. Putting them in a blender together is less than desirable. So, how does all of this apply to my project?

When I first thought of the concept of a wall jump attack, it was within the context of a Super Meat Boy meets Shadow of the Colossus sort of thing. I was imagining that you would wall jump up huge enemies to get to their weak points. I needed to start smaller though, so I came up with the idea of jumping off rockets quickly after prototyping basic movement with moving platforms.


Missile deflection prototype Well, that's pretty fun. Maybe this game is really about deflecting projectiles. Maybe it's some sort of platforming bullet hell! This phase is my first glimpse into what my infant's passions might be. As if they as picked up a ball and threw it, pride pulled me to my feet as I proclaimed "My child is a quarterback". But how do they die? The parental analogy breaks down here. We need the player to die sometimes. If they're deflecting rockets with their feet, what could possibly harm them? Maybe getting smashed between two solid objects? Okay, if the purpose of the game is to avoid getting smashed, what are other ways to nuance that challenge?


Mario Thwomp
Not getting smashed is a thing in all sorts of platforming games. Of course we have the classic Mario Thwomp, but maybe something more interesting, like an enemy that hops. In most games, an enemy that hops into the air would be threatening while in air and prey while on the ground. Interestingly, wall jump combat changes that up.

Enemy Combat Prototype If I make these baddies invincible while on the ground, and always a threat vertically, they become an enemy unique to my game and the way that it's played. Everything is young. I know that wall jumping to attack threats is what makes my game fun, so everything I'm adding should be with that core gameplay mechanic in mind. However, I barely know what my game is right now, so I shouldn't be buying a football uniform for my child yet, they could still turn out to be a dancer. In these early stages, focus on the cornerstones, build a sturdy foundation. With just a few hours of work a day, I've got all sorts of design potential here! They grow up so fast.



Combat Prototype
[indent=1]William's Comment: When you mention, "However, I barely know what my game is right now, so I shouldn't be buying a football uniform for my child yet, they could still turn out to be a dancer," that doesn't totally resonate with me as a designer. While there could be some moments of emergent ideas that could shake up the forumula from your original plan, I think it's important to keep in mind that your game is something that you're designing from beginning to end, and you should always have the end result in mind when you're building a foundation. [indent=1]While a franchise can develop a personality past your original influence and design, your game can not. Even the passions that it appears to adopt on its own are your own influence, your own design, your own passions. [indent=1]You're not growing a child. You're growing a topiary.

And sometimes a topiary grows to be a child. Please try to keep up. [indent=1]You've expressed that you have difficulty keeping a game under reigns in a way that keeps it down the path that its own personality wants, but a game doesn't have personality until you give it some and there's never a moment where you can't shape the game to become something different. With a child, there's a point where the kid is an individual that takes over who they're going to be. With a shaped shrub, all that you're doing is trimming the right places and guiding growth to become the art that you know that you want it to be, and I think that's much closer to what game design is. [indent=1]And that's the thing about the design so far: you've got your foundation down, the seeds planted, but it's growing wild right now, but a wild shrub is amorphous and doesn't have a personality. As the shrub expands into an impressive bush (ladies) it's going to be up to you to trim what needs to be trimmed and guide the growth to create the art that is ultimately reflective of your own personality, tastes, and goals. It's you who decides if you'll trim the parts that make it a pyramid, or if you'll trim different parts to make it a sphere, or trim different parts to turn it into a sexy topiary lady.
Did things just get weird in here or is it just me? [indent=1]I think that what I'm seeing as our fundamental difference in design so far is that you're putting forward that a game finds itself in the prototyping stage while I'm saying that a prototype has no personality until you start forcing it to be the cohesive game you want it to be. This actually harps back to our discussions on prototyping vs concept art, where you seem to support finding out how a game works through organic experimentation and I prefer to plan things out and adjust along the way. This distinction is really interesting to me because, even though we've developed games together for going on a decade, I'm only just starting to see the differences in our distinct approaches from a new perspective. Let us know what you think, who do you agree with? How do build the foundations for your game?
Want more immediate posts from us? You can follow Gabe on Twitter here and follow William on Twitter here.

WJHollyART

WJHollyART

 

Drawing a Game From Nothing: Concept Art

Week 1
William's Game
(Post by William Holly - Read More at www.duelingdevblogs.com)
When making a game, there's highs and lows. For people who like a challenge, that might be bug fixing. For people who like world-building, that may be in crafting Easter eggs or cutscenes. For people who like money, it's when the game ships. But for people who just like to create, it's in the design process; and nothing says design process quite like concept art.
Pictured: pure, unadulterated creativity Concept art is funny to me, because it's usually the first step in any project I start, but it's also probably the most expendable as well. Most typically, if you have an idea for a game totally cemented in your brain and it's already good to go and you don't have to convey these design ideas to other people working on the game then concept art is actually kind of redundant. But what concept art does it does well: concept art is a grinding wheel for the hatchet of your imagination. You always have to understand that you don't have eyes inside of your brain, so spilling your ideas out onto paper and then taking them back in with your actual eyes might result in you realizing that this idea only worked in my head oh my god what was I thinking this is stupid. And it's important that you catch that before you start developing a game rather than halfway through when it's too late to make changes without spending months redoing what you've already worked on. That is a right pain in the ass. So I like to get right into the basics of the game's rules and design right away with concept art, and that's what I did for this project! Figuring the game out
Okay, so I drew the movement style I want to go with: kind of a Binding of Isaac style twin-stick shooter setup. I usually like to make my games either platformers or arcadey, and since Gabe is making a platformer I decided to go with the arcadier approach by going twin-stick. Robotron 2084 is, after all, one of my favorite arcade games and Binding of Isaac is what I would consider a perfection of that kind of gameplay. But now I really need to get a grasp of what kinds of gameplay nuances I'm going to include. Do I want for the player to fire projectiles like a madman, charge up shots, use ammo, etc. etc. etc. Well, I kind of need to know what kind of game I'm making. I drew a skeleton as a fun point of reference guy, but what if I follow that idea?

Skeleton is turning blob monster there into a bag of bones for a disguise! So now I've somewhat forgone the arcade-style idea of a simple twin-stick shooter and am now focusing more on an Escape from Castle Wolfenstein feel (the original Muse Software game, not the id FPS game). Escape from Castle Wolfenstein is a bit rougher around the edges than Binding of Isaac, but I consider that a good thing: Wolfenstein has lots of flawed-but-fun concepts that I can improve upon, whereas trying to compete with Binding of Isaac would be a futile uphill battle.

If this is going to be a stealth game, combat is going to have to be very deliberate. Why on Earth would you choose to be stealth if you can just rain bullet Hell on your foes? So the standard attack will require the player to stop, making them vulnerable, charge for a second, then unleash an instant bolt which will immediately hit what is in front of them; having the attack lag on a moving projectile would be way too annoying to handle. By allowing the player to get an instant shot off after waiting a second, this will encourage players to sneak to a location where they can charge and shoot an unsuspecting enemy. An additional second of recoil will add to the frantic nature of trying to get in and out of a situation where you might have a lot of enemies around. But what if the player hops into a disguise? Can't they just walk through the level with impunity then?

The disguise is impermanent, but in case a player ends up with a rotten disguise in the middle of a room full of enemies the busted up disguise can act to absorb one hit so you have a head start in getting the Hell out of Dodge. I've considered making it so the player can't grip weapons when they're in disguise as well, which would create interesting trade-off for meta game where the player can choose to go non-lethal while in a rotten disguise so they can tank an extra hit. So all of this would be all fine and dandy if the game only has one or two types of enemies. But I want to include a lot of variety, and part of that will be enemies that don't go down in a single shot. You could risk taking pot shots at them with the pistol, but maybe I can also have a temporary weapon that allows the player to tank through certain portions of the game- to break up the stealth tension with occasional bouts of raw POWER!

And that's where the machine gun comes in. The machine gun would do everything that a machine gun should do: blow away enemies with ease. But the machine gun would also need to be used very tactically: instead of picking up ammo for a machine gun, you just have to pick up a new machine gun. They don't come with tons of ammo and you can't exceed the amount you start with. It's also not exactly an instrument of stealth, though you have a machine gun so who gives a crap about stealth?

And there you have it. No, really, that's just about all that you really need for the gameplay portion of the concept art when you're first starting out. I just decided a bunch of the gameplay with invitations for meta that I can improvise on as I make levels and design enemies. Style in Concept Well that was all of the technical aspects of the game that I want to have laid out before I begin developing. What about a visual style? That should be more interesting right? Absolutely! If drawing the same thing over and over again in different ways is interesting to you, you freak.

I'm fairly certain that any tattoo artist would probably agree with me that trying to make a skull interesting and have unique character is asking to fight a losing battle. Skulls have been done to death. They have the benefit of having distinct characteristics that immediately give away that they're a skull, but the concept is so tired that it's just so difficult to make something with its own charisma. I still can't wrap my head around how Toby Fox managed to create two different iconic skull faces in Undertale. After a while, however, I started to get a feel for what direction I wanted to take the art in.

Once you get into that mode of refining a concept, eventually you land on something you'll be more than comfortable working with.

With a skull much larger than the rest of the skeleton, he's got a cutesy look to him which is only enhanced by turning his nose-hole into a heart. But with the bones as thick and bulky as they are, he doesn't look totally frail either. It almost comes across like a carapace rather than an endoskeleton, and I'm totally cool with that. I also tried to concept some blob monsters, but those need a lot more work before I'll be happy with them.

I think the blob monster with the big eye might be the one I'm the happiest so far. The thought of the monsters having big ol' eyes for faces which get replaced by a skull face when used as a disguise just tickles me. All work and no play Finally, I'd like to leave you with this helpful tip that is pretty important to remember about concept drawing: even when you make your concept art as doodly as I do, it's still art, and artists can have moments of breakdown or block. If that happens, you just have to draw through it. It doesn't matter what you draw, but you've got to draw something.

No matter what it is, just draw until you start to feel inspiration again.

Even if it doesn't make a lick of sense.

[indent=1]Gabriel's Comment: William and I once made a little something called Four Play. It was a four-way breakout game. You controlled all of the paddles at once by moving the mouse. We both thought the idea sounded like an entertaining little project, all the way up until it was playable. When we could actually play the experience, we found that there was no intuitive way to control the paddles and aiming was a chore. Like touching the stove, or bowling, the idea was functionally less fun than anticipated.
[indent=1]For the first time, in Dueling Devblog history. I respectfully disagree with William's method.
[indent=1]
[indent=1]What if the body snatch mechanic, in practice, doesn't feel fun? The time spent on the body snatch mechanic artwork becomes less valuable.
[indent=1]All of that said, all of this has value. Shaping theme and style takes time and all of the above work contributes to that. Further, William's personal projects consistently feature tight and engaging gameplay. I've always felt like he has a better grip on what's practically fun while coming up with ideas. So history would suggest, his skill in design allows him to make just about anything fun with enough tweaking. I can't wait to jump into some blob dudes! Fun is a hard thing to pin down. It's elusive and as William so eloquently put ~ "...you don't have eyes inside of your brain, so spilling your ideas out onto paper and then taking them back in with your actual eyes might result in ... this is stupid." Prototyping is game design doodling, it's a method of discovering what is functionally fun.
[indent=1]Let us know what you think, who do you agree with? How do you get started on your games?
Want more immediate posts from us? You can follow Gabe on Twitter here and follow William on Twitter here.

WJHollyART

WJHollyART

 

Prototyping

Week 1
Gabe's Game
(Post by Gabriel Priske - Read More at www.duelingdevblogs.com)
Really pure ideas are hard to come by. Ideas that don't feel forced or gimmicky, but like an intuitive way to experience gaming. For example, I love how in Mario, you fight Goombas and Hammer Bros using the same skills you have developed for platforming: movement is combat. By the time you've really sunk your teeth into the game, your fingers are pumped full of muscle memory because, aside from the occasional flower, you have been doing nothing but running and jumping the whole time. I'd like to make a game that explores methods of movement as combat. A game where, instead of getting hulking armor, you're developing a skill. Rep after rep you perfect your muscle memory, culminating in epic battles that really feel epic because you've become an actual badass. Don't like mastery in games? Well, you quitters can go back to your "outside" and "relationships". My first idea was to make a platformer where holding down an action key enabled you to defy gravity and move faster for a short period of time, as well as damage enemies.
I do think this could make a decent prototype with more polish put into it. The issue that I came to was that making the dash happen instantly after clicking the action key felt too jerky to control strategically, but giving the effect a taper or lowering it entirely felt lackluster. Ultimately, it's not intuitive enough. It doesn't feel like that pure, Mario, natural way to experience gaming. When attempting to find a more elegant method of combative movement, I came up with this:
Wall jump to attack. Its god damn Mario 2.0! Wall jumping requires muscle memory and deliberate timing from the player, but skilled players can dance through the air like ninja-lemurs. So, what if that momentum became defensive and combative? The giant boss monster launches three missiles at you, you jump off one, sending it crashing into another. That jump brings you face to face with the final missile, you wall jump off its nose casting it into the heart of your nemesis! For the next week I'll mostly be polishing this movement engine. Its going to be really important that movement is completely intuitive. The player needs an unusual amount of control while in the air to be able to hit fast moving projectiles, which poses an interesting challenge when attempting to make normal platforming feel fluid. Feedback is welcomed with open arms, let's make a game together!
[indent=1]William's Comment: I definitely dig the idea of marrying movement to combat in this way, though when you originally pitched the concept to me I had no idea what you were going for. Seeing the example up there of the player sending a projectile into the boss's face REALLY changed the way I was picturing it beforehand.
[indent=1]What I'm most excited for, however, is not the combat that you have set up. The best parts of Mario games were never besting enemies, they were traversing levels with strategically placed hazards. I think the most interesting thing as you move forward will be seeing how you develop gameplay to move from a player rockin' through a level, and seamlessly defeating enemies as part of the same motion without much change in pace.
[indent=1]Hmmm, combining movement, level navigation, and combat... that reminds me of something...

Hell yeah! Want more immediate posts from us? You can follow Gabe on Twitter here and follow William on Twitter here.

WJHollyART

WJHollyART

Sign in to follow this  
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!