A few things,
First of all, I've launched the Patreon I talked about before, centered around the weekly animations
My Patreon Page
I decided how I'll deal with voting within Patreon, and I've also added a couple stretch goals for pixel art tutorials. I have no idea if this whole thing will work out or not, but I guess we'll see -__-
Also, since last week's poll was sketchy as hell, I'm just going to do Asuka this week, and do Marie next week. I've come up with a few ways of dealing with multiple votes and illegitimate voting spikes from now on, so it shouldn't happen again. That said, since I'm now officially doing a Patreon, I won't be canceling voting again from here on out.
Voting on the next character will start next Saturday, and the polls will be open next Tuesday.
I'm also thinking of making it so whatever gets second place on the previous poll carries over to the next poll, but I'm not sure yet.
Now that Patreon and voting is out of the way,
Someone asked me about game development through email, so I figure I may as well make a post about it here. I keep saying I'll do an in-depth tutorial eventually, but that won't be until Noaika is done so I may as well do something simple for now.
How to Start a game...?
So, here's the question. How do you start a game? What should you do early on in development?
There are a lot of ways to develop a game, and not every method will work for everyone. However, here's my method. This is more or less targeted towards those who have some skills, but have either never worked on a game before, or haven't gotten far. I'll also assume that you're working alone, since working with a team is a bit different, especially if you're a team on equal terms.
Early planning, visualize
The first step, though it may sound obvious, is to think about what you want to make,
So, imagine a game. What do you visualize in your head? For many people, what they visualize is the "ideal" moment, be it knights dueling in the moonlight, or a chibi farmer pulling up a goofy tomato with a satisfying *plop*.
What you're probably imagining isn't what you want to make, so much as it's what you would want to "play". These initial ideas tend to be combinations of elements from other things's that you've experienced and enjoyed. For example, perhaps you've played Rune Factory and Monster Girl Quest, and so you imagine a game with factors from the two. A character gathering items in a forest when suddenly a catgirl pops out, and you fight it off with a watering can,
However, it's important to keep in mind that the "ideal" that you imagine is intangible. It's a series of vague ideas that form a general feeling of "that would be cool". There are no "solid" mechanics behind it yet. You may imagine a character jumping, but you don't know how high, or how fast. You don't see the numbers yet. The hard part of game design is reaching the "ideal" you imagined, but in a functional, and practical way.
Regardless, make note of the factors you're imagining. Let's call it idea "MK-I"
The next three steps can happen in any order, but they all follow the same pattern of simplifying your initial idea.
Simplify, initial design.
Now, it's time to take your idea and make it more practical. Off the top of my head, let's say that this is my idea MK-1,
- Girl has a vacuum that sucks up enemies
- Sucked up enemies spit out spirits that manifest as animals, which follow the player around and attack enemies, making them vulnerable to sucking.
- When a certain number of animals is obtained, girl can combine with them, turning her into monster girl of that type. (combining with cats = cat girl)
- Alternate forms have different H animations and abilities.
- Equipable clothing that changes appearance/stats.
- Can buy different vacuums with different stats. Certain enemies need certain vacuums and certain enemies need to be attacked by certain animals.
- Towns in between levels with side-quests and H-scenes.
- Can learn spells that change animal behavior. (increase attack, increase lunge range, increase health)
- Certain number of animal spirits can combine into an animal girl themselves (stronger unit), and H with enemies.
- Corruption system
The first thing you need to do is determine what the core mechanic of your game is. What defines it? Whatever it is, this is the mechanic that you should focus on while simplifying your ideas. In the case of this game, the core mechanics are the first ones that I thought of/wrote down,
"girl has a vacuum that sucks up enemies, and they turn into animals that attack other enemies"
Beyond that, everything else is secondary, and you should be thinking about any elements that support the core mechanics first and foremost. An easy way to do this is imagine that you're making the first in long series of titles, and consider what
needs to be in the first game, and what would be in a sequel that expands on it.
For example, the idea that certain enemies are weak to certain animals is closely tied into the core gameplay mechanic, so it would probably stick around. On the other hand, equip-able clothing is a generic element, so it isn't really be a priority. It's up to you decide what's the most important, and what's better left for a "sequel", even if that never happens.
So, let's say you're making a simple game, and so you simplify it and end up with this.
- Player sucks up enemies, and they turn into animals that follow you and attack other enemies.
-You gain commands throughout the game (attack, defend, form a platform, etc)
- Saving a certain number of animals will cause them to combine into a complete monster girl, who has one H-scene with the player (no H with enemies).
This is idea MK-II. It's simpler, but it's also a bit more realistic for a first attempt at a game, and focuses on the core mechanic, leaving it open to grow later.
Your skills
Next, reflect on your skills,
If you're working alone, then at the very least you need to be able to program in some fashion, as well as graphics. So how far do your skills go?
Recall MK-II; and consider what do you know you can do, what can you figure out as you go, and what seems impossible. Chances are you're going to need to bring your "ideal" down to your skill level a little bit. What you imagined may have had high res graphics, but you're more comfortable with low-res. Or it may have had complex AI, but you're only capable of simple movement patterns. You're going to need to adjust your idea based on what you're actually capable of.
For example, I imagine the animals moving around interdependently but overall as a group, and doing things like forming platforms. I don't know if I could program that, so I'd simplify it to basic commands and movement in a line.
Point being; if there's something you can't do, then turn it into something you
can do that will accomplishes the same thing, if even a little.
This is idea MK-III. It's less amazing, but at least you have the skills to make it,
First outline of mechanics
Now, this is where it gets a little harder. Using MK-II, you need to decide on some specifics when it comes to how the game will work.
For example, in my.....example, the player can suck up enemies with a vacuum. Okay, great, but how does she move? How do enemies move? How fast? How does the vacuum actually work? animals attack enemies? How? Every decision needs to have a purpose behind it. So, make a list with your thoughts about your design
Movement
-Player speed is 1
-Average enemy speed is 0.80-ish (can be outrun, but not easily)
-Player speed while vacuuming is 0.5 (slower than enemies)
-Enemies slow down when being attacked by animals. The more animals, the slower they are. (Can use animals to escape easier, or to make attacking easier)
-Enemy height is 1, some enemies are 2. Player can jump 1.7 (can jump over some enemies)
- Player jump is fast, with very little air time (can't rely too much on jumping to avoid enemies)
- ?? double jumping using animals? Or monster girls??
Fighting
-Animals form a line behind the player. When you press the attack button, the first animal in line leaps forward at the enemy with a little air time, speed of 1.3-ish. When animals are recalled, the attacking animal goes to the back of the line ??in order of health??
-Animals in line recover health
-Animals attach to various points on the enemy, creating little hit sparks to show attacking.
-Enemies shoot projectiles/do melee attacks while being attacked by animals. (player has to dodge these attacks while vacuuming)
-Animals are damaged by each enemy attack, but keep fighting. If their HP reaches 0, they die.
-??Way to re-organize animal order??
Multiple enemies
-Player must split animals between enemies to slow them down.
-??How to recall animals on different enemies??
-??enemies form a line????can't jump over more than one??
Vacuuming
-??animals don't make enemies easier to vacuum, they just make it safer??
-??each animal makes enemies easier to vacuum? 1.2 each? ??depending on max animal number??
-??enemies have health counter that counts down????show health as things floating around enemy??
ETC...
As you can see, even in this example I've run into questions about how the game would work. Certain ideas can contradict each other, or change the flow of the game completely. It's at this stage that you're going to have to do a lot of thinking. It may even start to feel like the more you think about it, the less it lives up to the "ideal" you imagined. This isn't because the idea is bad, or because you're bad at something, it's just that the initial idea was so vague and without detail that it's difficult to find you're way there step by step. But you
can get there, though it may take more consideration than you originally thought.
First concept art, sprites, tests, basic control
Anyhow, by this point while you may not have specifics, you should at least have a fairly decent idea of what you're going to do. It's now that you can start working towards a proof of concept. It may help you solve some of the problems you've run into, if you have.
For me, I prefer to do testing with some player sprites, so I generally do those first. I design the character as a sprite, but you may want to do some concept art. Animate the player's basic movements, and anything related to core mechanics. You can be rough, though having the right number of frames makes it easier to work with.
Next recall your basic outline, and start programming the player's movements and applying animations. After you've done the basic physics, create any actions that are related to core mechanics. (in this case, sucking with the vacuum, throwing animals, and recalling animals)
Mess around with timing and speed until it "feels" right. Or until it just feels fun.
From there, create either a target to test your attacks/ mechanics on, or a very basic enemy. It's here that you'll either go forward with your plans, or begin to see that things aren't going to be as simple as you thought. If you're working with a special mechanic, you may end up going between your proof of concept and adjusting the outline a lot, until you find a balance that makes sense. (For example, I might find that animals should be thrown in an arc, instead of straight forward)
Even if you're making a basic action game, you may rethink some of your plans once you've "felt" it in action, even in a simple form. You may decide, for example, that a low jump height you planned on using doesn't feel right, that that enemy projectiles are a better fit for the game than melee attacks.
Continue adjusting your outline, and hopefully you'll come to a conclusion that makes sense, AND feels right.
Logistics, and what's practical?
From there, you need to start thinking about the scope of the game. What resources do you have? How much can you work, and how fast? What are you're goals for this game?
Let's say you imagine a game with 20 enemies, but what does that mean? What makes an enemy?
Enemy graphics
- Idle animation
- Move animation
- Jump animation
- Flinch animation
- Attack 1 animation
- Attack 2 animation
- Death animation
- H-animation (stage 1, stage 2, stage 3)
- H-animation position 2 ( stage 1, stage 2, stage 3)
- Effects
- Masks
Programming
- AI (follow, pace, jump, special actions)
- Attacking
- Attacking
- Sounds
- Animation
- H-animations
- Effects
- Collisions
CG
+sound if you're doing it
Let's assume you can do all of this, but how long does it take you? 5 hours? 5 days? A week?
Depending on how fast you work during the proof of concept, and how much time you have to work with, you may want to simplify a bit. Remove hit animations, limit the H-animation count per enemy to 1, use parents/templates/common behavior for programming, limit the number of frames, limit the resolution of sprites, limit the colors, etc.
In other words, if you want to make a game within a certain amount of time, then figure out what's practical for you in that time. Figure that out and and then adjust your expectations accordingly. Then adjust your expectations again, because nothing ever goes perfectly.
My general rule of thumb for a simple $5 platformer is,
3 levels
3-4 H-enemies per level
1-3 traps/hazards per level
3 bosses
Some form of items or powerups.
Outline of content
Now, let's say you have an outline of the game mechanics that works, you've done a short proof of concept for the core mechanics (player, enemy), and you know the amount of content you want to make. Now what?
Now, it's time to outline all the content (enemies, items, etc). While you may want to work towards a demo, you still need to plan out the rest of the game before then so that you can see the overall progression of the game and make sure it all works together.
You can do it one of two ways; You can start buy listing everything you want to be in the game, and then organize them into levels, or you can just plan them out level by level.
Write the outline in a way that helps you brainstorm, including each enemy, and how they attack (you can do concept art for this if it will help). Here's an example of a level outline, (just imagine there's one for each level)
Level Outline
Level_1---------------------------------------------------------------
Areas
-Grass fields
-Pirate ship
Items:
-Quick-VAC
-Health upgrade
Enemies
- Boar soldier ( short distance thrust with spear)
- Plant monster (spit spores into air from above, tentacle melee from ground)
- Harpy (Must weigh down with animals during arc swoop, attacks with wind projectile on ground)
- Wolf Pirate (shoots gun in 2 patterns, swings sword in verticle arc)
Traps
- Rope trap (catches animals)
- Swinging log (knocks animals/player away)
- Cannon (Shoots cannonballs in various patterns)
Boss: Wolf Pirate captain ( this would have it's own outline)
--------------------------------------------------------------------------------------------------------------
Here's the other method I mentioned, you can write out all the content you want in the game
before deciding where they will be in the game. Though they may not be as thematic. (I've only written descriptions for some of these, since it's hypothetical)
Content list
Areas:
-Field
-Pirate Ship
-City
-Castle
-Sky-land
-Sky-temple
Weapons
-Quick Vac (quicker movement while sucking)
-Strong Vac (slow movement, stronger)
-Sniper Vac (Long range, weaker)
-Shotgun-Vac (large cone for dodging, sensible )
Items
-Health upgrade x 3
Powerups
-Health
- Power up
Enemies
- Boar soldier ( short distance thrust with spear)
- Plant monster (spit spores into air from above, tentacle melee from ground)
- Harpy (Must weigh down with animals during arc swoop, attacks with wind projectile on ground)
- Wolf Pirate (shoots gun in 2 patterns, swings sword in verticle arc)
- Cat Thief (etc)
- Golem
- Fox mage
- Hand monster
- Angel
- Cerberus
- Priest
- Demon
- Minotaur
Traps
- Rope trap (catches animals)
- Swinging log (knocks animals away)
- Cannon (Shoots cannonballs in various patterns)
- Pots falling from windows
- Tentacle from sewer
- spikes
- Spinning blade
- Net
- black hole
-------------------------------------------------------------------------------
After you've done one or both of those things, you'll need to plan out the specifics of each level in more detail. This includes how many rooms there are, and where you'll see certain content within the level, and in what order. (In my case, I assume that after an enemy appears once, it can appear in any room after that)
Try to space your content out so that the player is always encountering something new in each room as much as possible. (However don't use the same pattern all the time, otherwise it may become predictable.)
Each block represents a room, parts where a new tileset is introduced are also listed.
Level specific outline
Level 1
-----------
Grass field
Boar
-----------
-----------
Rope Trap
-----------
SAVE POINT
-----------
Plant Monster
-----------
-----------
Swinging log
Health upgrade
-----------
SAVE POINT
-----------
Harpy
Quick-VAC
-----------
SAVE POINT
-----------
Pirate ship
Cannon
Wolf pirate
-----------
SAVE POINT
-----------
Boss
-----------
Creating the content, demo
After you have everything planned out, it's time to create all the content of the first level, and work towards a demo.
You may want to start with the player moveset, and items, since if you change your mind about how they work it will effect how levels and enemies need to be designed.
After the player is set in stone (for now), begin creating all the enemies, and traps. After you've created what you need for the first room or two, you can begin designing the first room.
Designing the first room
Start simple, and assume your players are idiots. You understand your mechanics, but your players won't when they play for the first time. Give them room to breath and learn the controls before confronting them with an enemy. Then focusing on teaching them the game mechanics in whatever way you can without telling them (visual cues, layout).
You may need to explain some controls if you have a complicated button layout. I think it's fine to tell the player how to use an item upon acquiring it, so it can work to give the player their weapon in the first screen.
- Keep things somewhat flat, and easy to navigate, with a few simple jumps.
- Give the player a lot of room to deal with the first enemy, so they can establish how enemies behave.
After the player is done warming up, you can slowly approach the normal level of challenge a little.
Second room +
When new content os introduced, such as an enemy or trap; make the player confront it by itself first so that you know that they understand it. From then on, you can use it in conjunction with other established content in different combinations. If you're having a hard time, try doing some sketches of different setups.
Beyond that, think about your core mechanics, and how they can be effected by the layout of the level. What effect does a narrow space have on the player's moveset? What about a series of quick jumps? How does it effect the enemy?
Every enemy's placement should have some reasoning behind it. "This enemy is on the other side of a gap because it shoots at the player, forcing the them to time their jumps", or "this enemy is over this edge, because the player will have to jump down, attack, and then jump back up to not get hit".
-Avoid repetitive layouts. If there are two long horizontal levels, then consider something vertical.
-Avoid excessive tiny platforms.
-Don't make everything too flat.
-Don't have too much wasted space, but also don't fill every corner with danger. Let the player breath every once and a while.
- Not everything has to be extremely difficult. Let the player blow off some steam here and there.
-Pay attention to your camera. What can it see? Shift the camera up if there's nothing to see below ground. Move it around to your advantage, and not to the player's detriment.
- Avoid jumps that you can barely make.
-Utilize different kinds of enemy spawning. If the player only encounters enemies where you place them, they will be encountering everything from the front.
In a well balanced game, the rooms would be challenging as hell, but the player should still succeed most of the time. If they do, it means you've taught them what they needed to know (Or they learned on their own, rather).
Reworking mechanics, and onward
After you've designed a few rooms and tested them out, you should have an even better idea of what you need to change, if anything. Maybe the enemies need to follow the player better, or through testing you notice glitches/mistakes you've made. From there, you just repeat the process until you're done.
That said, this is more or less the most time consuming part of development, because it may be a while before everything "feels" right; before you're confident enough in what's there to move forward. In some cases, you're simply weary of testing of what's there, and what's boring to you would be enough for others. In other cases, a few simple changes can make all the difference, or re-kindle your enthusiasm.
You may also spend a long time trying to fix a mechanic or room, only to realize that it just doesn't work, and that the time you invested would have been better spent creating content for the game that would have worked better.
This is generally why development is so fast in the beginning, and yet so slow mid-development. It's just something you'll have to work your way through, if it happens.
Oh, and once you're done? Well, get ready for bug-fixing. You've probably still got a couple weeks ahead of you once you realize that people are getting stuck in walls and exploding.
Closing tips
That's about all for now, but here are some closing tips.
-Start small, start simple. And do it a couple times. You can make something complicated when failure is something you can afford. (And if you fail once, don't be stubborn, and just do something simple again before trying again.... *sigh*)
-Try making a game in like a week, even if it's just something terrible. Finishing a game teaches you a lot, and will make you more comfortable with larger projects.
- Get other people to test your game, and then balance it again. In my case, the initial difficulty settings ended up being the hard mode. My roommate couldn't get past the first room in Eroico. (It wasn't THAT hard!)
- If you finish a game, don't price it too high. Compare it to other games on DLsite for reference, and find a good balance. A higher price doesn't always mean more sales.
