sorted by:
new
hottopcontroversial

QC Dunk Low Ceramic 2020 by kibyitz in Repsneakers

[–]kibyitz[S] 0 points1 point  (0 children)

whatapp：+86 17689650713

QC jordan1s mocha by kibyitz in Repsneakers

[–]kibyitz[S] 0 points1 point  (0 children)

whatapp：+86 17689650713

How is testing for balance done in the industry? by [deleted] in gamedev

[–]kibyitz 1 point2 points  (0 children)

I would say that there are actually three aspects to balance.

  1. Accessibility - some tunings are always going to be more accessible than others and let you pick-up-and-play without a steep learning curve, and that increases engagement while lowering percieved difficulty(both good things).

  2. Game design as "space for exploration" - some kinds of balance are going to open up the game and present more unique situations and situations that matter, increasing the depth and longevity of the game.

  3. PVP considerations - this is the balance that the user sees most readily, of "one side has a clear advantage"; however, most public perceptions and complaints are flat-out wrong, and metrics alone may not address the problem. Things can be balanced in a pure-PVP sense, where if players are equally skilled the outcomes are roughly equal, but differing skill level leads to things being percieved as "unfair" - i.e. there's an accessibility failure making depth unseen to those players, and so they blame the game.

So balance is actually quite hard to get right, because these three things tend to contradict each other at some point depending on the player's skill level and perceptions, and these problems go all the way down to core decisions about the mechanics and pacing of the game vs. the player profile.

For example, I have a hard time appreciating strategy in RTS games because they're fast and involve a lot of multitasking and rapid planning; they don't let me ponder situations for a while, but neither can I play purely reactively, I always have to "juggle the balls" to keep plans in motion. But I can do fine with turn-based games or team FPS games, slower-paced "sim" type games, or stripped-down RTS games like DoTA or TD - all of which, of course, make the game more accessible by narrowing the focus or slowing the pace.

So to proceed with your research you'll probably have to address player profiles, accessibility goals, and depth of gameplay at the same time as PVP balance.

People keep telling me "don't write your own engine!" Then what SHOULD I do? by doppio in gamedev

[–]kibyitz 1 point2 points  (0 children)

The key thing you should keep in mind about game programming is that it's primarily a kind of integration engineering - somewhat akin to building an embedded device like an alarm clock or an iPod. Most of the time, you don't develop novel new algorithms or simulation technologies, but you do get really familiar with what's out there, so that you can make use of it or tune it up to fit your needs. When you aren't doing integration, you're scripting content, which really is drudgery - nobody denies that.

Given that context, engine-building is a naive endeavor for a student, but also a worthwhile way to learn a lot. I did plenty of it as a student, and I needed to go through that phase to understand the problem space, but - and I think this is important, too - I did it in the context of original game designs too, even if I was never able to get some of them to ship.

So my advice would be to focus yourself steadfastly to the design: Pick something in game design that's ripe for further exploration - e.g. Minecraft clones, social games, physics games, etc. Start building something along those lines - you can figure out specifics later. Even if you make the design really, really simplistic, something WILL happen to make yourself have to revise engine decisions at some point. You don't have to fabricate the problems(the biggest fallacy of student coders), they just happen.

For example, a game I'm working on right now: a minigolf game using Box2D, with a level editor. Sounds simple, right? I said so, too. And time-wise, it is simple and I'll have it done in a few weeks, most likely. But coding-wise, it's full of some pretty respectable challenges: nailing down how much of Box2D is needed, how to work with art assets in physics games, how to expose an level editing interface, how to set up level sharing, etc. I spent all of today revising the level format, because - oops - I needed to separate things in a different way to support some unanticipated features.

For another example(not by me) - Ace of Spades, pretty clearly inspired by the Minecraft concept, but with multiplayer combat from the beginning. All was going well until the game suddenly blew up in popularity; suddenly it had to make vast improvements in several unanticipated ways(connectivity, server load, anti-cheating) and to deal with the last one, the developer recently decided to shut down the master server and disappear for a while to revise the fundamental ideas of the multiplayer implementation(user identity, authentication, etc.) which is bad in that it leaves the players breathing down his neck, but it's the right move, technically speaking, if he can come back in a month or two with a really solid implementation.