sloopy543

None! Don't do it! It's a foolish and dogmatic way to make software, and a waste of time.

I had pretty much no experience when I started mine. "Shape" is an arbitrary thing. The shape of the tool should match the shape of your problem, and if you don't know what your problem is yet, you don't know what the best tool for it will look like.

It's funny because I have the same mantra. Make games not engines.

I focus on making the game, and the engine is the thing left over at the end.

But in so many ways, I have learned that a really productive game engine programmer should be spending his/her time building tools for the team. That's kind of the point.

You're making these tools that unlock the creativity of others, so they can help you with the team's creative vision.

I would expect any programmer I hire to be a problem solver, first and foremost, the kind of person who wouldn't need hand holding to modify the engine. I would hire people who I expect to make sensible decisions.

That's going to rule out a lot of people, and that's fine. When it comes to hiring, I select. I don't instruct.

I've found that making a custom engine is more amenable to teamwork, not less.

I can build a simpler level editor that I can give to a totally nontechnical person (a.k.a. my spouse), and they can go to town making levels.

They don't need to know anything about Unity/Unreal. They just need to know about my game.

My game already includes levels my friends have designed using tools I made for them.

He hasn't gotten to gameplay because it is meant to be an educational series, which means skipping the parts that don't serve the educational purpose.

I've followed Casey's approach but taken a different path. Instead of focusing on covering anything an engine could do, I started making my own game.

And I discovered that once you get the basics of a platform layer and some GPU communication down, it's pretty easy to start throwing together a real game.

I'm doing it. I've got a real game with real gameplay, actual levels, real things you can do. All of this after a year or learning.

I definitely relate to the bikeshedding thing. I like what someone from Nintendo once said.

"You're making a game. The engine is what's leftover when you're done."

I like to think that way as well.

Sure, I have a laundry list of things to do, but it all starts with a gameplay idea that I want to explore. I force myself to justify all development efforts by way of serving the gameplay ideas.

That way, you're making a game first and foremost and the "engine" is the tool you make to make the game.

I would encourage you to check out Casey Muratori's Handmade Hero. I believe he does a nice job of separating platform-specific code from non-platform specific code.

My engine is based on his. It has a cross-platform library that only handles the game logic itself. Each platform has its own thing called a platform layer that handles the platform specific aspects of the game (things like setting up a window, setting up a sound buffer, getting a basic communication channel to the GPU on that platform, etc)

Once you've got a few basic platform layers for each platform you intend to target, you just update them every now and again as needed.

Also, you don't need to make your thing cross-platform right away. Just do a basic separation, knowing you will come back later and make it work for various other platforms.

At the current stage of my project, I'm just exploring the space and nowhere near shipping. All of the platform porting will come later, once I know I've got a unique product that will sell

In my experience, it was easy... until I got to the part of my game that makes it unique. Then it went from easy to very very hard.

That's the thing about engines. They'll get you up and running quickly for basic stuff, but you'll be tearing out your hair when you need to do anything non-basic.

For context, it took me about a year of learning in my spare time to get to place where I could do my own cross-platform game engine, and some of that time was spent doing the code for the game itself.

What exactly is the expectation here? Would it have taken that much less time to learn the little nuances of Unity that folks here are complaining about?

Also for context, my full-time job is demanding, and I have a lot of outdoor hobbies like snowboarding and mountain biking. I bet if I were even more focused, I would have learned it faster.

It's not a big deal. You're already expending effort learning Unity/Unreal. It's only a little more effort to do your own thing. You might enjoy it

I don't actually think it's that hard once you know how to do it. You basically make a cross-platform C library that generates the GPU commands and sounds per frame, then you just plug that into whatever platform you're running on.

My Mac Platform code is only like 1500 lines or so. Pretty small considering that it runs a 2D game full-screen on my iMac.

Not sure what is meant by 'Herculean'. Once you know how to do it, you don't lose that knowledge. You literally have the code to use on the next project. No big deal

I'll just sit back and eat popcorn as I work with my custom handmade game engine. None of this is a concern for me, and it has been refreshing to work directly with the graphics pipeline and in lower level languages that give me direct control. If something is wrong, it's my own damn fault.

For those who want to get away from being totally dependent on third-party frameworks and tools, check out Handmade Hero. It was life-changing for me, the difference between making a game I'm happy with vs. not.

I also have a YouTube series discussing how to get setup on a Mac, if that's that platform you're starting with.

https://youtu.be/M5l6CvHwWsc

I'm not really sure why more people don't do their own thing. It has been really satisfying for me. Overall, the process of making games is way more rewarding, and I think I'll have something better on the other end of all of this.

Plus I'm getting better as a programmer, which helps with other aspects of employment.

1. Owner didn't pay me. Lots of manipulative BS. Wanted more money.

2. Startup seemed okay with me being remote at the start but weren't actually okay with it.

3. Contract ended amicably with contracting company.

4. Job seemed okay but they sold the client on an impossible deadline. Left when shit hit the fan.

5. On a very longterm contract but grew bored with the tech and suspected the contract would get cut short so I jumped to something that seemed more long term with potential to learn something new.

6. CEO made promises and didn't deliver so I'm fielding offers and will probably leave once I get something that pays more.

Lessons: 1. You make more money every time you jump ship. 2. Don't listen to what people say. Listen to what they do. 3. No boss/company is interested in providing you with opportunities to learn. They all want to exploit an existing skill set and all real learning has to happen on your own time. 4. Employers don't really want remote. They give it begrudgingly because enough of the talented people are demanding it. 5. It's probably better to just let contracts end, then double-dip during the transition. 6. These people aren't your family.

Yeah, I'm all for unit tests when they're needed. They just aren't the first thing I'll write

Nope. I pretty much always find it to be counterproductive.

Most of programming happens in the exploration phase. That's the real problem solving. You're just trying things and seeing if some api gives you what you want or works as you might expect. You have no idea which functions to call or what classes to use, etc.

If you write the tests before you do the exploration, you're saying you know what you're going to find in that exploration.

Nobody knows the future. You can waste a crazy amount of time pretending you do.

Regarding the 32-bit thing, wouldn't it be in any game developers interest to create additional x-bit options to rebuild the game in higher bit systems? I would want my game to be amenable to historical preservation, which is the reason I do my own engines in lower level languages.

Oh I've had plenty of struggles myself. I've gone six months without work and had to spend several years just building my skills to the point where others would find them valuable.

On top of that, I was super stubborn about always working remotely, which I got but only after rejecting one place after another. I would have kept employment easily had I just been more willing to drive into an office every day.

I happen to be young, but I work with plenty of people who are much older than me and greyer too, so I don't really buy the ageism argument. The market is hot and if you can deliver the goods, chances are you can get a job.

It depends. Some days I work more, some days less. I honestly don't even count the hours because I think the entire premise of it is complete nonsense.

It's more like what thing can I work on such that if I were to complete it by tomorrow, people would think I was doing something amazing? If that thing takes one hour in the evening, and I have that hour free, I'll do it. If not, maybe I'll just call it a day and start on it first thing in the morning.

But it's really all about creating a perception and managing expectations, which I suspect anyone running a business does naturally

Yep. It's all about VALUE. If you are there when it matters and you help your customers achieve the OUTCOME they care about, they will happily forget those few moments when you were late to a meeting or didn't answer an email or Slack message right away.

Life is not grade school. You don't get points for just showing up. You actually have to do meaningful work that produces a valuable result for someone. People will happily tolerate the slightly disheveled dude who shows up with the critical component of their gold mine. They fire the smug well-spoken guy who keeps making excuses.

Where does your money go? Do you regularly audit your finances and account for it all?

I have a bigass spreadsheet I use to track every last dollar, and I ruthlessly optimize everything.

Cell phone plan, down to $30/month. Health insurance, just $300/month. No tv. No subscriptions. No commute. Even if I did, I own my car outright so no car payment. No B.S. pre-packaged food. I cook pretty much everything at home. Have done so for years. Minimal eating out, once a month or so at inexpensive restaurants. No debt. Of any kind. So therefore no interest payments.

A few small "luxury" expenses here like a ski pass because you only live once.

All of this is completely within the realm of someone who makes $70k per year or more, the bottom rung of software development.

You should be able to hit $100K in savings in five years if you are smart with your money. Likely more if you really hustle and audit every dollar. Maybe a little less if you're supporting kids, but you can optimize how you spend your money on them too.

I meant more like 80 hours a week. It is, in my experience, difficult and cumbersome to charge for more than 40 hours a week since it kinda disrupts the usual cadence. You can do it sometimes for deadlines but wouldn't want to make a regular habit of it

Right right. They have other weird concepts like "market rates" and average timeframe lodged in their heads.

It's complicated and pardon me if I have glossed over the details somewhat.

If you're smart, you get all of the work done in advance, then stage it over the course the next few days, providing a steady trickle to create the perception of steady progress and to have something to mention at the standup meetings. I suspect a good percentage of experienced developers with good customer management skills do something akin to this.

Yup. I suspect this sort of thing is going on all over the place but most people don't speak openly of it.

All work is value-based. Never forget that.

No clients care if you spent 80 hours a week not solving their problem, so why would they care if you spent 20 solving it?

Semantics. It obviously takes time to build independence, but you can do it. It is in your power. Nobody really has to tolerate micromanagement unless they're just starting out

Umm... nothing and that's the point. It's free market capitalism. People should be free to do whatever they want with their time.

So long as the value they provide is greater than their cost, the deal is good for both parties

Ideally people would only work 30 hours but get paid for the full week.

Hourly billing is bullshit anyway. The natural cadence of work doesn't map to always being able to extract value from every single hour. Sometimes the value is in being more or less available for that week.

It's astonishing how many developers can't grasp that concept and insist on being super strict about hourly work

If you provide value and they really need you, they won't treat you this way. Find a way to become more valuable and competitive in the marketplace demanding your skill. Save your money so you can say goodbye to micromanagers.

Nobody with valuable skills should put up with crap like that

If you're in software, it's easy. You just have to learn how to control your spending and save the rest. Get comfortable living at about $30K per year

I don't have any of these concerns. I just don't answer emails or Slack messages right way.

Nobody has fired me for it yet because I am there when it matters, I consistently provide value, and I show up to all meetings scheduled in advance.

Just get a big ball o' FU money and let the good times roll. You're the one who decides if you need to be "always on," and guess what, you don't. The world can learn learn to wait like 30 minutes or a few hours if you're really far away from tech.

I routinely leave my place in the middle of the day to ride my bike, climb, or whatever and I have suffered minimal repercussions.

It's all in your mind

I would like to think I might experience a cognitive acceleration when I retire. No more bullshit occupying my mind. No need to meditate to stop thinking about such-and-such shitty interaction at work. Hoping to get my mind back so I can do things more creative than whatever is in the JIRA.

Oh for sure! There are so many different FU cards, money being the obvious one

My only advice is to get your finances together and have a giant ball of "FU" money so you can afford to quit situations where you're wasting your time. Software engineers have the luxury of making large sums of money, so it shouldn't take too long to get a few hundred K together. Things start to look much more rosy after that.

Just remember to think like a business person. They're doing that. Why not you?