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

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.