sloopy543
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 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.
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.
"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.
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
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.
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
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
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.
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.
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.
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.
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'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
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.
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.
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.
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?
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
Nobody with valuable skills should put up with crap like that
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
Just remember to think like a business person. They're doing that. Why not you?