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.
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.
Once you know how to do something, it’s easy to forget how much time and effort it took to get there. Making your own engine comes at a cost, and if you’re an artist or new to development, it’s a pretty high barrier of entry.
Unity initially presented a good value proposition. You lose some control, but the engine will do a lot for you. Even for experienced devs this meant saving time. And I think Unity got this popular because they largely delivered on that promise. It seems the problem is that they’re butchering the evolution of the platform. Judging by the comments here, if Unity we’re doing a better job of rolling out and documenting changes, and stabilizing the product I think people would be happy choosing it.
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
big difference is teams. If you're fine working by yourself, then an engine where you have 100% knowledge scope is great.
The moment you introduce another dev or artist or any individual that needs source access to work on your game, you'll probably have them hitting every pain point mentioned in the article and more. Why's your UI buggy (or does it even exist?), why's rendering this thing slow? So time is spent teaching them (and there's likely zero help on the internet unlike Unity/Unreal), or making tools/bugfixes to accomadate for them. i.e. less time on the actual game.
Hence the mantra: make games, not engines. If you like making engines, that's a good reason in and of itself to ignore that mantra. But if your goal is to make a game, then you shouldn't have to worry about the nitty gritty until it needs to be addressed.
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 made a bunch of half-finished engines in C++ and Common Lisp over the years, my problem is that I always end up bikeshedding the architecture instead of writing a game. And since I do it in my time off, life eventually intervenes.
E.g. this time around, between a new job and a pandemic, I don't have the headspace to think about my little experimental Roguelike I've been developing over the past year (which BTW. mostly took the form it has from me bikeshedding the ECS pattern).
So when the other day I thought it's time to test out the few things I wanted to test about VR, I eventually decided to screw writing my own code, and now I'm just poking around UE4 and doing everything in blueprints.
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.
Building your own thing is fine if you're solo. When you start having to collaborate with e.g. artists who expect their assets to render the same way they do in their editor, or a game designer who needs to edit levels in the engine, etc., then you introduce a bottleneck due to the fact that some people are working on the engine, and others on the game that depends on the engine.
This is the big bottleneck, plus, for shipping jobs (say <2 month timespans), writing some of the basic stuff eats up more time than you want.
I've been doing an engine on the side (c++ underneath, javascript on top) for pc,Hololens,magic leap,Mac, android, we , pi/Linux (finally) for about 4 years now. I can churn out tools (editors, daemons that run for months, hot-reloading remote-assets, vr apps&overlays, ML tools, streaming point clouds) and demos, but it's still missing rigid body physics and a lighting engine (outside ray marching)
I still have to resort to unity or unreal to get jobs out, because there's too much to do for one person. (Although this is finally starting to change :)
I can't agree more. Unity was a good way to do games because it provided visual editor and unified API between all platforms including mobile if you use unity only as a renderer, it's pretty good and stable.
The only problem, to use unity with comfort, you need to code some base for networking, asset loading, bundle management, caching, localization, visual scripting, and UI (using NGUI and happy with it). It's the way how large companies work with unity (blizzard for example)
Getting rid of all those layers of abstraction stacked over the generation and writing code using modern C/C++ much more satisfying. Especially now, when we have a nice minimalistic cross-platform layer SDL, not to mess with video card/sound directly.
For those who want a slightly higher level OOP API, I want to recommend to try out https://oxygine.org/. It's using modern C++ to provide API similar to MonoGame.
For those who like unity like editor experience I recommend trying https://www.duality2d.net/. It's free, stable, and extremely fast engine width C# scripting similar to the unity MonoBehaiours system.
I definitely support making your own game engine if you enjoy it as a programmer.
But it shouldn't be a surprise that it's not the best choice for the most developers. Every moment you're debugging and improving the engine is another moment you could have been working on the game itself, because almost all engine improvements are orthogonal to improving the game experience.
So given a limited amount of time, you will always end up with a better and more complete game if you start with a batteries-included engine than if you roll your own.
Also the fact is most peoples' game ideas are very derivative and it would be overkill to reinvent the wheel by implementing your own engine for, say, a game that'd easily be made in Game Maker Studio
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.
The way I put it is, "the engine isn't really done until the game is." So many polish features in games lead to new categories of assets, which in turn need new methods of rendering.
This is one of the multitude of reasons that so many older game devs reach for the C++ compiler; they don't know what the game will need, but they do know they can make the necessary modifications to ship if they approach it bottom-up.
Making your own game engine requires experience as well. If you've already used other engines, you'll have some idea of the "shape" that a UI library or texture loading system should take.
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.
> I'm not really sure why more people don't do their own thing.
I've certainly considered it, but one thing holds me back: cross-platform targeting. I'd love for my game to eventually run on the Switch, to say nothing of more basic targets like MacOS, Windows and Linux. Targeting those platforms would be a herculean effort.
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
> 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
The problem with this is that even if your code is 100% bug free and works perfectly, new platforms are created all the time. The PS5 is coming out in a couple of months - does your crossplatform code target that? Unity does. How about the Switch? How about VR? How about Webassembly?
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
I have watched quite a bit of handmade hero. As a fun hobby, it looks great, but using that strategy to make an actual game... well, let's just say it doesn't surprise me he's multiple years in and hasn't even gotten to gameplay yet.
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.
Yeah the cross-platform ease and great VR support is what keeps me there. I've done my own game engines in the past and really enjoyed it, but that was when I was purely focused on PC gaming.
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.
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.
> You're just trying things and seeing if some api gives you what you want or works as you might expect.
I don't do most of my programming this way, because mostly I'm writing new things, not gluing together existing APIs with a tiny amount of simple glue code. But when I do need to characterize existing APIs, I find that unit tests are a really helpful way to do it — especially in languages without REPLs, but even in languages that do have REPLs, because the tests allow me to change things (parameters, auth keys, versions of Somebody Else's Software) and verify that the beliefs I based my code on are still valid.
You are right, but technically speaking you already did implementation for POC without having the tests. So the full answer is "do POC without tests first, continue implementation with tests first".
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.
If they can, certainly. Assuming the developer still exists, and they still have the source code, some idea of the build environment, and they want their game to still be accessible. And even then:
> Isn't this just a matter of opening up the project, changing one line and recompiling? Should take five minutes, it's not really a big deal? Yes and no. The 64-bit change itself is small but they change enough other things every few months that recompiling against new versions of the libraries doesn't simply work. You get a few linker errors and have to look up the new names for a couple of functions. Or there's a new element in one of the libraries with the same name as one of my variables so I have to find+replace to change its name. And then you run it and find that it's in portrait mode, squished into half of the screen, so you have to look up what changes they've made to how screen orientation works and change a few more lines. [...] It adds up.
Sure, you can work around it, but from the developer's perspective their game has just been designated obsolete for no reason that Apple couldn't have fixed themselves.
> 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?
This has not been my experience at all. It's a different subject entirely, but it is very common for clients to be much happier to pay for 20 days at $550 a day than 5 days at $2,200 a day, even if they got it two weeks earlier. People are not rational.
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.
This aggravates me, because as a customer, I want the expert who charges the highest rate, but also does things really fast and correctly, because I know what a difference there is between competent and incompetent people. But other people don't think like that, and if I say I'm ok with a high hourly rate, they think I'm saying I want to be ripped off in terms of both rate and hours.
If you spend 80 hours you're being inefficient.
If you spend 20 hours (and they're being charged for value,) they feel they were deceived.
Selling your hours to anyone truly seems like a lose-lose situation.
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
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
History says otherwise, unless you mean people should be free to abuse of others lack of judgement when their survival is on the line. That's why they started to cap working hours and protecting children from being part of the workforce. Also, you don't have to go that far into history. Some uber drivers I've talked to want to get out of that business but can't because they were bamboozled into signing a car loan they can't pay without working for Uber and they mention that when they signed it they had an expectation of earnings that has been steadily going down.
No comment on your assumption that I'm a developer unless you meant it as a standalone fact.
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
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.
I do work in software, and I do save my money. However, unless I'm suddenly given a massive raise it's going to take 5 or more years until I have what I consider "FU money" saved up. I wouldn't really consider saving up money over years and years as "just getting it"
Wow. A whole 5 years to get "FU Money" saved up. That's a blessing, and can strongly be considered "just getting it". Short of an inheritance, or winning the lottery, normally salaried or hourly workers will never have "FU money"; let alone in 5 short years.
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.
There are a lot of people who are programmers but aren't "software developers", particularly not "full stack" buzzword enabled types. If you've been programming for a decade or two, and haven't had that title, you're likely not going to get that $70K that fresh grads will. Likely not even hired, for "cultural fit".
Hope you don't fall off the treadmill, because if you do, you'll find out there is no way back and no pity.
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.
Demonstrating what you can do at a temporary job is a viable tactic, but it takes luck to find the right one and sacrifices if it's paying half what you're used to.
When you're just out of college, you can tell people in an interview that you've been learning a language on your own, and you've done this and that, and you're confident you can be useful. And they will hire you. That's how I got my first post bachelor's job.
But ten or twenty years down the line, you can't do that. Any job with 5-10 requirements, they aren't interested in hearing how you have been studying it at home, how you were working with something similar 6 months or 10 years ago. You have to be using all of the things on a daily basis now. And confidence you can learn any language equates to arrogance and "not a cultural fit".
You don't appreciate the difference between a college grad and someone a bit older. The issue isn't that everyone who's older insists on a senior level salary, when they don't know, say, Java or Python. The issue is that it's assumed they can't even learn anything new, regardless of experience, if they aren't doing it right now.
What I did personally was to find a job with zero technical requirements that happened to be ripe for automation, so I could do whatever I wanted in any spare moment and learn whatever I thought might be useful. But in retrospect, I think it was extreme luck that I found it, and that I was at my best for the interview. Because 99% of similar jobs are just, file stuff, answer phones, move boxes.
Congrats on having no debt of any kind. I have debt. I also strictly budget my income and expenses (also with a big ass spreadsheet). Healthcare costs me more than $300/mo. Daycare (1.8k/mo), housing (1.2k/mo), car ($600/mo all inclusive) and food ($550/mo for a family of 4), are my largest expenses. Don't tell me to get rid of the car; I don't live in a city or area with ANY public transportation. The car is literally, it. No I'm not moving to CA. I don't have luxuries to cut. I don't go out to eat, I don't have Netflix, Spotify, Amazon prime, or the latest phone (my phone is a One Plus 3). I use a service provider that costs me $60/mo for two lines (TOTAL - $60/mo) for cell phone. TV is friends Plex or free Roku apps.
I won't say how much I have in savings, but your 100k in five years (20k saved a year?! SERIOUSLY?! that's more than min wage full time job, PRE TAX!) is not at ALL realistic. No I don't work a Min Wage job, but I'm not SF/Bay/SV area salary wither.
100k in accessible funds is "FU, I'm going to go get another job, even if it takes 6-12 months" money.
I have an emergency fund of roughly 3-6 months of necessary bills. It's not really enough to say "FU", but it's enough to give me an emotional buffer of, "I could leave if things got bad enough"
I've already been saving for 5. And by "FU" money I was considering an amount that would allow me to say "fuck you" to a boss and survive until I found a new job without worrying too much. Like, $100,000 or less. Probably closer to $70k, after ten years of saving.
I do have a software job in the USA. However, with the exploding prices of everything in Austin, it's getting harder and harder to hang onto any cash. I get consistent raises year over year but don't feel that I have any more money.
Even better! I would suggest studying for interviews with something like interview cake & leetcode and getting a job at a FANG.
Try moving to seattle or if rain doesn't work for you, the bay area. With an income of $300k+ you could probably save that $100k amount in a few years. Don't move until you have job, that way you get a relocation benefit and that $3000/month rent won't seem that crazy to you.
Even working at a startup will pay you better than what I'm estimating you make in austin.
Yeah, no thanks. I've been to Seattle and to the bay area and I wasn't a fan of either. I have an entire life built here and have zero desire to ever move, and even less to work for a FAANG.
There's much more to my life than being a programmer, that's just what I do for work. My life does not revolve around it.
Just trying to point out that your advise is not universal. I have moved to UK, but if my parents were ill and in need of care, that would have been impossible.
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
Yeah, I'm with you on that. My original comment was really tongue in cheek, and I agree with most of what you said in your original post. I'm the same way, I refuse to put work email or slack on my phone and once I clock out for the day I am done. I work from 7-4 M-F and do almost zero thinking about work outside those hours. I've been at my company for five years now and I keep getting promoted so my email habits are obviously irrelevant to my employment status.
If I were to get fired for "not responding fast enough" or something like that, then I wouldn't want to work at that place anyway. I'm a programmer and I get paid to program, so that's what I do. It's worked out pretty well so far :)
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.
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
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.
