#this just doesn’t make sense from a gamedev perspective | Explore Tumblr posts and blogs

hypertensiongamedev · 7 years ago

Note

You are a source of inspiration..Any recommendations if someone wanted to make a game of their own? (I.e what programs to use, things to look out for, etc)

I’ll get the expected answers out first. Here’s the programs I use (and the plugins I use for each of those):

Blender, which I use for modeling, rigging, and animating

Rigify plugin for rig creation (this comes bundled with Blender, you just have to enable it)

RetopoFlow for retopologizing high-poly to low-poly (has a free version in Github, the paid version just entitles you to technical support)

Substance Painter for texturing (this sometimes goes on sale on Steam, so watch out for it every time Steam goes on a discount sale)

Photoshop CC for creating GUI art, and image manipulation needs ($10 per month sounds fair for all the things it could do for me)

Unity for the game engine

StrangeIoC, an open-source code framework (I explain what it is exactly here)

TextMesh Pro for the GUI labels (free)

ShaderForge for making my own shaders (used to be paid, but it’s now free)

InControl, for user customization of controls (has an old, free version in github)

Unity’s Post-processing Stack for visual effects (free)

A custom AI plugin that I made, called INTLord

A custom game editing tool I made that I simply call Attack Editor (for now)

Visual Studio Community Edition (the free version) for the IDE

Resharper plugin for VS is immensely helpful for me (this is pretty expensive, but worth it for me as I use C# heavily)

Git for backup and version control

I use Git Extensions as the front-end GUI

Dropbox and Google Drive for backing up other things like raw art assets

Portable Kanban for keeping a todo list (I can recommend HacknPlan for an online alternative)

But I think the number one thing to look out for here is that, while it seems I’m able to do this game with ease, I can assure you that it is not smooth sailing all the time. I’m only sharing the end result of my work each time I post. All the mistakes and errors I encounter, I tend to discard and not share, but only because I think no one cares to really read about them. My point here is that even when I tell you what programs I use, just using those won’t guarantee you success.

If you’re having a hard time making a game, that doesn’t mean you’re not cut out for this, because I have a hard time too. It’s an inescapable part of something as complex as game development. I think what really makes a person not cut out for this, is when they give up easily when encountering difficult problems, like an overwhelmingly confusing bug, or getting a crash and finding out your work got corrupted. The proper response here is to approach problems methodically instead, and take steps so you tend to not encounter those things again in the future.

Don’t expect to get things perfectly the first time, but do take time and effort to improve each time you blunder.

There’s one pattern I see a lot with beginners who never get far: they love to complain. Don’t end up like that. If after all your best effort and research, things still don’t work, then I can finally concede that you have the right to complain.

These beginners would blame the engine, the programming language, or the art tool if something goes haywire, when, majority of the time, the mistake was their misunderstanding what the tool was for, and a way to solve it was in the user manual. So make sure you’ve done your homework before going on a rant.

Second thing: Practice a lot. They build your skill set. If you have no idea where to start, I suggest just making a simple game like tic-tac-toe in the game engine of your choice. The point here isn’t to build something amazing, it’s to get your feet wet with the tools you’re using. You’ll be doing it more to learn how to get graphics drawn on the screen, how to detect and react to user-input, how to code gameplay logic, etc.

The fact that you’re making a simple tic-tac-toe game helps ease the difficulty curve of trying out a new game engine. Then work out how to put a main menu on it, a highscore that gets saved to a text file, etc.

Then try out making a tetris game, then a side-scrolling platformer, etc. The more familiar you get with your tools, the easier it is to create more and more complex things.

There’s a theory out there that the amount of vocabulary you have with your spoken language influences what you tend to say (or even think!). I think it’s the same with you and your gamedev tools. You might have never gotten around to doing some crazy idea you had, simply because, lacking knowledge in your tools, you didn’t think it was possible.

I do game jam games to try out learning something new.

One thing you need to realize is, if you’re not having fun doing the nitty-gritty details of these steps in game-making, maybe you should reconsider your choice of wanting to make games, because this is how it is all of the time. Or probably at least consider specializing in one aspect instead, and get help with the rest.

The third thing to look out for is having no direction. What really helped me out with making this game is having a clear goal of what I want: a 3d action game about the last days of a terminally-ill henshin hero, taking place in a modern day city.

When you have no clear goal, you have no idea if what you’re currently doing is beneficial or detrimental to your game. You would have no yardstick to measure progress.

It’s fine to experiment without having decided yet what the game will look like, or what genre you’re going for, but I think even among experiments, the good ones are those that have at least some general direction of what they’re trying to test or prove.

This is the earliest photo I could find of my work on the game, dated 2014, Dec. 31. On my pen tablet display there is my early concept for Desparo.

There’s a lot of things to consider when deciding to make a game. I myself was thinking whether I make this game a turn-based, or a real-time action RPG. I was also wondering if I should do it in 2d or 3d, if I go with anime or realistic art style, etc.

I knew I needed to finalize my decisions if I ever hope to progress. I think the proper way to have done it would have been to make a turn-based RPG prototype alongside an action RPG prototype, and then compare the two. But in the end I just went ahead with the real-time action game, simply because I wanted to try out something new.

Sometimes, you start out making a game prototype with just boxes, and deciding it has potential, flesh it out further by attaching a theme/story/premise behind it. I think that’s also a viable approach. It just so happened Ghost Knight Victis started the other way around, with the story first before the gameplay.

And how do you get that spark of an idea of what your game should be? My game’s premise was a culmination of several ideas that have been brewing in my mind for a long time (years). After going through something pretty significant in my life and one lonely December, with two bottles of Tequila and playing through Transistor, all the incongruent ideas started making sense and fit together.

I’m not saying people need to go beat themselves up just to get something “cool”. In fact, if you have a content and happy life, consider yourself lucky if you couldn’t find inspiration to create something really artistic. Because those things tend to come from some deeply-buried, strong feeling, like anger or resentment. Then again, dealing with such thoughts are a normal challenge of growing up, living in a community, or even something as mundane as struggling with where to get a stable income. You just need to change your perspective on where inspiration comes from.

Fourth is to pace yourself properly. Match your expectations with what you can do at the moment. Aim too far out of your comfort zone, and you’ll likely fail, get discouraged, and stop trying. The trick is to aim only a little bit outside your comfort zone. You still compel yourself to improve, but at the same time, it’s a manageable amount of work for you.

Scrum and Kanban are the usual things to learn about here. I personally use Kanban a lot. The idea is simple:

As a task gets further along to completion, the more it moves to the right. But, you have one restriction: only up to 3 tasks at a time can be in the “Doing” column.

This means if you are already devoted to working on 3 tasks in the “Doing” column, and you want to work on something new, you have to finish at least one of those 3 first. This makes you concentrate on getting things done. It stops you from diluting your focus, trying to work on too many things at a time.

You could also decide to move a task from “Doing” back to the “Ready” column. But I normally do it only when either I realize something else is of more importance and I need to stop what I was doing, or perhaps I’m stumped and really can’t progress on that task, in which case I give up and swap it for a different task instead.

Scrum has a lot of techniques, but one thing I take from it is the idea of sprints. You do your work in a per 2-week period, called a sprint. On the start of each sprint, you decide what you will get done, and commit to finishing those tasks within 2 weeks. After those 2 weeks, you again pick which tasks to do for the next 2 weeks, and so on. This is also a method to help you focus on getting things done, because you only concentrate on a few tasks at a time, but it also forces you to take a look at the bigger picture and re-prioritize after every 2 weeks.

In my case, I don’t have 2 weeks. My sprint is only 2 days: every weekend. So I make sure each task I write in a card is achievable within 2 days. If I think a task can’t be finished in 2 days, I divide it into several subtasks.

For example, “obtaining items from chests” might be too complex, so I could divide that to these subtasks:

being able to define chests as a list of the items inside it, and being able to save that data to file

being able to place chests in the map, each chest being: a 3d model of the chest, and the data file saying what items are inside it

create the GUI art for viewing items inside a chest

put the GUI art in-game and adding code to allow it to react to user-input

implement the code for transferring items from a chest to the player’s inventory and vice-versa

Fifth is to concentrate on having a working, playable work-in-progress.

The thing to aim for here is that at the end of each sprint, whatever progress you make should be something that works in-game. It’s fine if you don’t get that all the time, but I think aiming for it helps pull everything towards that direction.

I think this video of Bayonetta’s prototype says a lot:

youtube

For reference, here’s how the final product looks like:

youtube

You can see from that prototype video that you can already start working on the gameplay even if you don’t have the art finalized yet (because the art can take a long time to get done).

I think that’s the wiser method of doing things, you get a playable work-in-progress without being stalled by the fact that the art is incomplete. It’s even better because it’s easier to adjust animations while they’re still rough: it’s less motions to re-arrange and tweak whenever you need to adjust it.

It’s also not good to base your judgement of how correct an animation is from just looking at it in Blender/Maya/etc. alone, because you aren’t seeing it being used in-game. For all you know, the sword attack you’ve been polishing for so many days doesn’t really work because the arc of the sword swing doesn’t really reach the intended target! Or maybe you didn’t realize that the swing is making the sword pass through the ground mesh unintentionally!

Or maybe there’s certain situations where your animation really just needs to be tweaked (when fighting inside narrow hallways, or when you are standing on a flight of stairs & attacking a target below you, etc.). It’s really better to test it out in-game as soon as you’ve established the key frames of your animation.

Frankly, this is something that I should learn to do myself!

And what about for the story? I think this is a neat trick in designing a prototype for your game’s story:

youtube

(the video’s about half an hour long, but it’s worth it)

The basic gist is that you design a “board game” out of your game’s story. And I think that’s the proper way to do things. There’s really more to it than what I just said, so I encourage you all to watch that video.

Sixth is to handle feedback as objectively as you can. As a solo developer, you will tend to see your game as your “baby”, something that in your eyes is a flawless creation.

Maybe you expect players to always do something, but turns out it never crosses their minds at all. That might be a symptom that you need to fix your game’s design.

Be clear with what you are asking feedback for. Just posting screenshots, and a vague “this is my game, suggestions and feedback are welcome!” will not help, because people will tend to give you suggestions that are not in line with the goal you have set in mind for the game, and you end up sounding defensive trying to explain things.

Explain your intent with what you’re specifically showing, and ask for feedback if people think your work achieved that intent or not. But start with a 2 to 3 sentence blurb that describes the premise of your game, to set the tone. Here’s a good tutorial for that.

Take the time to appreciate when people praise you, but don’t let it get to your head.You shouldn’t keep yourself in a circle full of yes-men, you will just not improve there. On the other hand, don’t think that just because you’re being the target of verbal abuse that you are finally getting the so-called brutally honest feedback.

You really have to ignore the emotional parts of what people post, good or bad. Read between the lines of what’s being said, to find the truly useful feedback you want for improvement (if there is even any in their posts).

But don’t just follow every suggestion that comes along your way. Sift through it and think about why someone said what they said.

In my first playable demo, many were complaining that the player should be allowed to move more responsively, to be able to cancel attacks into movement. But that went against my intention of giving it a Dark Souls type of combat (instead of a Dynasty Warriors style of combat).

I realized, people were having that problem because I placed far too many enemies in the level. No one suggested that I lessen the amount of enemies, but that was really my mistake with that one.

So there really was a problem, but their suggestion was not the best way to fix it.

Another example: When Magicka was still being developed, some beta testers complained that friendly fire ruins the experience, and kept suggesting to remove it, or at least have the option to disable it. But the developers doubled down on their decision to have friendly-fire, because friends hitting each other was part of the humor that they wanted to achieve, so they decided to leave it there, and they were right.

I’ll end all of this by saying, this is only my way of doing things. It’s perfectly reasonable if you discover a different way that works for you!

I always keep a bottle of Tequila handy under my desk.

#tips #gamedev #indiedev

115 notes · View notes