Tips for a starting game designer

[GoodDron]

I admire incremental games very much and USI is a wonderful game. I'm almost 500 in-game hours in, sector 69 and heading towards current year acumen achievement.

And as a starting game designer I want to know which math- and hard-skills I am to have for making, balancing, math-modeling and testing such complex games?

I'll really apreciate it if you even could advise some online courses on section of mathematics, programming languages/frameworks used in work.

My question is not only for Sylv, maybe the members of our community could also lend some tips.

Thank you.

[rob_s_cat2]

there are generally two ways to go with math in incremental games.

if you choose to go the rebirth/exponential route, you oly need to know how to balance exponents mathematically. though this sounds easy, if you get it wrong the balance is really out of kilter, so the more things you add, the harder it is. that said, there are a few notable games in the genre that use this method, though all are pregressive skill based, such as increlution or idlescape. the single hardest thing in this case is keeping the numbers manageable, as exponents that are too big can get to electronic infinity quickly. if successful though, this method has the advantage that any content that is slightly out of balance for the area (or even sometimes majorly out of balance, depending on the situation) becomes self correcting in that it will majorly raise the skill required to do it, so content 'fault tolerance' is inbuilt in this system. the major disadvantage is that it is hard to implement new ideas, so most of the developer playtesting will be working out how to fit new ideas into the system. a big risk with this system is making too many skills available.
if, on the other hand, you choose to use a prestige system such as USI or many other games, the hardest part of balancing is not making the perks from prestiging overpowered or insignificant. content has no fault tolerance inbuilt but is easier to fit within the framework, and new ideas and mechanics can be implemented slightly more easily than with the exponential system. also this system has the advantage that it's slightly easier to monetise if you want to get something back from the time invested developing it. further, this system has been in use longer, so there are more hints and libraries available for frameworks, meaning you are less likely to have to reinvent the wheel if you search for idle game libraries on github or so

[rob_s_cat2]

as for the design aspect itself, i would suggest it might be useful to make a framework of the math before putting any game content into the game. this way, when you begin to add content, you can make your life easier by having the content literally on a spreadsheet orinternal table, where you can balance numbers manually if needed or work out an algorithm to do it for you, and then you just need to make a function from the math handler to read in the necessary numbers, graphics, texts, etc. and the only real need for programing is when new mechanics are added.

these tips are deliberately broad, as there is quite a lot of range within the genre of both good and bad systems in use, it will be up to you to do the research to find out how best to implement your own ideas.

[GoodDron]

Originally posted by rob_s_cat2:

these tips are deliberately broad, as there is quite a lot of range within the genre of both good and bad systems in use, it will be up to you to do the research to find out how best to implement your own ideas.

Thanks for your answer!

I've already done some research and haven't found any specific instructions. Maybe my googling skills are also not that good I suppose :)

I assume what I need to do and that is really close to what you've written. But everything seems to be overwhelming and overcomplicated right now for me, and I just want to get my ducks in a row.

Should I be more specific in my questions?

[Sylv]

Rob gave great answers.

I would ask though, what kind of game do you intend? An important distinction for me is is the main "focus".

Is it going to be something resource based, IE The typical ish generate more resources to generate more resources to afford more stuff et cetera and make number go up. Or combat based Where you need to raise stats and progress through more difficult areas.

If it's just resource based you can get away with a little less stringent planning, as accidently scaling too fast can be mitigated easily by moving the next upgrades up in cost and it just feels like a nice pacing variety to the player. Combat based is a little trickier as its not great to blow through content too quickly as its harder to reign in and not feel silly to have enemy power growth fluctuate a ton.

As for learning resources, I don't really know any online courses or anything like that, but if you just want to get a grasp on basic growth for functions this Reddit post is neat: https://www.reddit.com/r/incremental_games/comments/2ztcfk/linear_polynomial_exponential_and_more_growth/.

During my initial planning and now when I am adding content I use Desmos (online graphing calculator) to compare and tweak growth functions that get used.

Past that, You just have to play and test yourself, and get some others too. The interactions between different systems get too complex for just graphs to actually tell you what's going to happen or how its going to feel to the player. Especially early on I had a version of the game up running through a section basically constantly while working on stuff.

[GoodDron]

Originally posted by Sylv:

Rob gave great answers.

I would ask though, what kind of game do you intend? An important distinction for me is is the main "focus".

Is it going to be something resource based, IE The typical ish generate more resources to generate more resources to afford more stuff et cetera and make number go up. Or combat based Where you need to raise stats and progress through more difficult areas.

If it's just resource based you can get away with a little less stringent planning, as accidently scaling too fast can be mitigated easily by moving the next upgrades up in cost and it just feels like a nice pacing variety to the player. Combat based is a little trickier as its not great to blow through content too quickly as its harder to reign in and not feel silly to have enemy power growth fluctuate a ton.

As for learning resources, I don't really know any online courses or anything like that, but if you just want to get a grasp on basic growth for functions this Reddit post is neat: https://www.reddit.com/r/incremental_games/comments/2ztcfk/linear_polynomial_exponential_and_more_growth/.

During my initial planning and now when I am adding content I use Desmos (online graphing calculator) to compare and tweak growth functions that get used.

Past that, You just have to play and test yourself, and get some others too. The interactions between different systems get too complex for just graphs to actually tell you what's going to happen or how its going to feel to the player. Especially early on I had a version of the game up running through a section basically constantly while working on stuff.

Thanks!
Desmos seems to be realy helpful.
I thought about smth combat based with several differently played but interconnected mechanichs

[rob_s_cat2]

https://github.com/Srickshaw/basic-idle
as i said in my tips, hunt through github.
this one is barebones enough, and in languages easy enough to read, to be useful in getting some ideas for possible frameworks.

https://github.com/scorzy/IdleSpace
this one is basically a complete game, with source, that you can even play to see how it works while going through the source to see what does what. pulling and running locally and seeing how changing the source changes what the game does could give you some ideas as well, and fits into what you've stated as what you think your main premise might be

https://github.com/scorzy/IdleAnt
this one takes a slightly different approach but was the grounding for the idea of the above game. note the dependencies if you plan on pulling it. you'll need them.

i could go on for days, but it's just as easy for you to sift through a simple 'idle' search on github to find things that aren't to do with scripts for other games or logging and dealing with idle chatters in whatever chat medium or using idle time on your computer to accomplish other tasks. i really don't know what else i can contribute to this without going into in-depth theory about how to balance and create content, so i'll just at this stage say have fun and don't let the bugs win in creating the program to bring your idea to life!

[GoodDron]

Originally posted by rob_s_cat2:

https://github.com/Srickshaw/basic-idle
as i said in my tips, hunt through github.
this one is barebones enough, and in languages easy enough to read, to be useful in getting some ideas for possible frameworks.

https://github.com/scorzy/IdleSpace
this one is basically a complete game, with source, that you can even play to see how it works while going through the source to see what does what. pulling and running locally and seeing how changing the source changes what the game does could give you some ideas as well, and fits into what you've stated as what you think your main premise might be

https://github.com/scorzy/IdleAnt
this one takes a slightly different approach but was the grounding for the idea of the above game. note the dependencies if you plan on pulling it. you'll need them.

i could go on for days, but it's just as easy for you to sift through a simple 'idle' search on github to find things that aren't to do with scripts for other games or logging and dealing with idle chatters in whatever chat medium or using idle time on your computer to accomplish other tasks. i really don't know what else i can contribute to this without going into in-depth theory about how to balance and create content, so i'll just at this stage say have fun and don't let the bugs win in creating the program to bring your idea to life!

Thank you for a great lifehack!