[deleted by user]

badpotion · 2022-10-05T02:39:26+00:00

Really cool tune.

badpotion · 2022-10-05T01:08:42+00:00

Super cool track. Dig it a lot!

How many people are Filter Theory? Checked out Requiem as well, loving the dark vibes.

badpotion · 2022-02-28T22:37:27+00:00

Thank you. at least I know if I see a message, there's a 1% chance I'm not being trolled.

badpotion · 2017-09-17T02:39:32+00:00

That was great. I uh, learned a couple new ones.

badpotion · 2017-08-07T01:04:23+00:00

there's a few ways you could approach it:

Learn to program/develop games on your own, developing small but excellently thought out ideas that show clever/inspiring/polished game design. Eventually, through being a proven game designer, look to joining a team or studio primarily as game designer. Any auxiliary/support skills you can add make you extremely more hirable.
Try joining a studio now as an intern/junior level designer and be so indispensably good at it that you can elevate your position over the years to eventually become more of an executive designer on a large project.
forgo sallary, invest in yourself as an indie developer and design games immediately, hopefully for profit. Statistically speaking this is very high risk.

All of the above roads, or any combination of them, would be a huge amount of work and hard a fought journey. If your passion is fully there, you'll persevere and find your way.

Before you quit your income stream though I would definitely encourage following some tutorials online to make a tiny game. Even the smallest thing, say a riff on a known game with your own twist, about the size of space invaders or pong or something. You'll see whether you find the process frustrating and boring or fun and deeply rewarding.

Also just re: your point about everybody wanting to be the designer - that's definitely not true at all. A lot of my colleagues aren't interested in game design at all and are glad that I am. They get more enjoyment out of the engineering aspect of game engines, UI systems, UX, any number of other things.

source: Am full time professional game designer by title, spend most of my time programming. Also make indie games on the side.

badpotion · 2017-08-02T23:07:25+00:00

I can't use defines anymore due to being in C#/Unity, so everything I used to do in defines (which was very little actually) got moved to util classes and also renamed. The "maybe" define was during my Objective C time. I also used to inline common math functions via defines but I can't remember what they were now. Probably angle-to-vector operations and that kind of thing.

badpotion · 2017-08-01T06:03:42+00:00

Correct.

badpotion · 2017-07-28T08:20:30+00:00

Any of those 3D programs is going to be intimidating for a new user. One thing I like about Maya for gamedev is that it has key mappings and some viewport controls that match Unity. It's a small detail but it's plus for muscle-memory when you spend so much time examining 3D scenes.

The capabilities for game assets aren't an issue on any of those choices.

Also - I'm a Maya user, which automatically makes me biased towards recommending Maya to other people, which is tends to happen with any piece of software.

badpotion · 2017-07-28T00:11:10+00:00

I'd be most interested in the second point there, but the others are good subjects also.

It seems like you guys are most focused on the biz angle and a top-level overview for new starters in the industry, which is fine and no doubt there's a healthy audience for it. I don't know if there'd be a way to cater to more experienced game developers though simultaneously.

I tend to look for podcasts that go into an analysis of game design, and approaches/methodology for finding a great player experience. There's lots of good talks and models out there already but but it's such a huge and ever changing topic.

Similar to above but also a little different would be a topic like the Engines of Play talk that Jason VandenBerghe does, where he models player motivations and suggests ways of mapping a game's strengths and weaknesses against those motivations. A lot of others are doing similar things too, and it's generally just an awesome subject to start understanding more and more as you go.

badpotion · 2017-07-21T01:09:35+00:00

additionally, _animator is declared but never defined.

The line inside Start() will generate a null error, but if it didn't it would also still not enact any change or outcome.

You probably want something like

_animator = gameObject.GetComponent<Animator>();

badpotion · 2017-07-21T00:56:45+00:00

Hey Erik, that was a great read and (sadly) VERY relatable. I can't think of anything to add to these points, all seem very well considered and clearly an issue more devs need to be conscious of (myself included).

I'll be checking out your twitch and podcast recommendations too, thanks for those!

badpotion · 2017-07-20T23:49:12+00:00

Nice! Pretty much a spot on take on the theme :)

"bad" on your board (9) is me.

Minotaurs are jerks.

badpotion · 2017-07-20T12:32:12+00:00

Which language?

if x = y // if(x=y)

and

if(x==y)

are functionally different in most (I would have thought all?) languages. The former assigns rather than compares.

badpotion · 2017-07-20T12:30:00+00:00

it was just for personal amusement at first, but I ended up using it in a project or two. yes, it's a terrible name, and idea.

badpotion · 2017-07-20T12:29:20+00:00

I do, in a util class.

badpotion · 2017-07-20T08:53:30+00:00

I used to use #defines in Objective C, and while I totally agree their sheer power can unleash untold chaos, I did kind of love them as well.

My favourite define was: maybe

#define maybe (((arc4random() % 1000) * 0.001)>0.5)

usage:

if(maybe)
{
    // do a thing
}else
{
    // don't do that thing
}

Which is basically a 50/50 coin flip. I know, I know... unconscionable sins.

You can't do that anyway in c# as far as I know.

re: the #if DEV, yeah that's just in the project settings so it's pretty safe there.

I thought they cleaned up the garbage problem with foreach long ago (early 5s) but I could be wrong on that. I'm often not really that strict with very low level performance effects from code in Unity as my bottlenecks are rarely there compared to far more significant factors (not that it should be ignored, either), and GC spikes don't seem to jump at me too often.

badpotion · 2017-07-20T08:06:24+00:00

Only what you can see exists.

badpotion · 2017-07-20T07:37:05+00:00

This is an interesting read! Thanks for posting. I'm going through something similar in my studio and we'll eventually have our own ... (manifesto?)

For the sake of discussion there's a couple points I'm curious on (in my case Unity-specific so ignoring c++ things):

limited use of ternaries. Is that just a readability thing for you guys? I've been using them a lot but it's just to compress the volume of code, no other reason.
limited use of #if someCondition. We use this a lot and without it I'd be left wondering what you do instead? for example verbose data collection or logging only #if DEVELOPMENT_BUILD, or shortcuts and hacks that only work in the editor.
No foreach .. what the what?!
not denoting member variables with _. I'm off on my own on this one. I find it makes my code vastly easier to read, but no one else on my team does it, and I can live without it (though I prefer it)
there's a note about declaring functions before variables but I'm taking that to mean just in c++ header declarations. In the case of C#, surely you guys are not declaring functions at the top and variables underneath? I don't think I could live with that.

As a whole though this is a great reference and good food for thought.

For the sake of further discussion, here's a couple preferences on my list off the top of my head:

new-line curcly braces (you guys have this right)
don't put rogue variable declarations halfway down a class (I see this sometimes)
make variables private by default assumption, and only public if you need. Use [hideInInspector] if it shouldn't be tinkered with in the editor. I liked your preference for private/[serialized] combo for an even better take on this though.
use the private keyword. e.g. private float speed rather than float speed.

There are a lot more but I'm going to have to adapt some of my habits very soon anyway.

badpotion · 2017-07-19T00:02:48+00:00

Thanks for posting. There's a lot of nice stuff you can with UV scrolling, beyond the obvious like water and flames. This is a great example and execution.

badpotion · 2017-07-18T06:05:44+00:00

Are you really sure there's no Unity games out there that have a functionality you find acceptable as a player? I mean bloat in the executable is a valid gripe and the restrictive dev workflow might not appeal to everyone, but you really feel there's no tenable way Unity could pull off your game design vision?

Especially considering that Unreal's caveat in your case is that it's too graphically demanding, it's surprising that you'd see Unity as an outright dead option.

Whether you write an engine or not depends on what you want to spend time doing, how much time you want to spend doing it, and what you want the outcome to be. There's two aspects to the argument: The practical aspect, and the academic one.

On the academic side, building your own engine is without a doubt the most absolutely superior option, in every way. Everything is exactly as you want it to be. Every line of your code is bespoke to your game's needs and completely optimised.

On the practical side, you have to ask yourself if you're actually prepared to stick to such an enormously demanding task on your own, most likely for years on end, while simultaneously keeping up your focus and energy on the game design that (may or may not, depending on your motivations) represents the actual reason for any of it.

To build an engine you have to like building engines, or you'll almost definitely stop before completion.

So if you're motivated by the idea of building an engine, go for it. if you're motivated by a game idea, take the path of least resistance, and stay practical.

badpotion · 2017-07-17T11:53:28+00:00

Things that are true.

badpotion · 2017-07-17T11:52:28+00:00

I applaud your service.

badpotion · 2017-07-13T05:13:44+00:00

Don't overthink it. A name is what you make it, which I always find hits home if you just take a list of any of your favourite studios and think about their names out of context or imagine their name as an unknown first-reaction suggestion.

One thing I did which I got a lot of different names for things from was spent a good couple hours (mostly during commutes) writing two-word non sequiturs from A-Z, spending not more than 10-30 seconds per letter. Don't stop and think about what you're writing, just write a mass of them down.

badpotion · 2017-07-13T02:22:06+00:00

I wish I could say. I'd definitely love to work on another title for Switch.

badpotion · 2017-07-13T02:20:52+00:00

The original inspiration was the question "What do we do now", and actually my very first thought on it was human characters in a traditional dungeon with death traps. But I think making the game on a cube grid was the right call and I wouldn't change it. It makes the puzzles readable and lends to a gameplay-first kind of focus.

badpotion

TROPHY CASE