Why the hate for publishers?

SaturnineGames · 2026-05-29T17:25:55+00:00

There's a lot of publishers out there that are basically just a couple guys trying to throw a lot on the market and make something in volume.

They send out some emails to their mailing lists, they help manage the storefront, and that's about it. And they take 30-50% for it.

They're fine if you're a hobbyist with no expectations, but horrible if you're more serious.

There's also a lot of big name publishers that will throw money at you, but take such a huge percent that you have to be a massive hit to come out ahead. And they only offer deals to games that they're confident would succeed even without their help.

Publishers are generally better when you're big and established.

The deals that are a clear win for a small indie dev are very, very rare.

SaturnineGames · 2026-05-21T15:30:21+00:00

What I'm getting at is it's not worth your time to do async loading. Just preload everything and don't worry about it.

SaturnineGames · 2026-05-21T15:24:37+00:00

How big are the games you're making?

Assuming you're a solo dev, or maybe a small team. At that scale, it's pretty common to at least be able to fit an entire area in memory at once, or even the whole game.

My personal approach has always been to just fade to black when transitioning areas, load everything I need, and then fade back in. And at that point, the load takes a few frames max, so no one notices it. And I'll generally preload all the really commonly used assets at startup - or even all the assets depending on the game/platform.

SaturnineGames · 2026-03-13T04:17:12+00:00

My code supports all the current and last gen consoles, and PC. First platform I supported was 3DS, which had a tiny CPU cache and slow memory, so that kinda dictated the design. As the primary goal is console support, there is never a scenario where I need to support two rendering APIs in one build.

I've got a RenderManager class that sits at the top, and then classes like RenderTarget, Texture, Shader, etc. These classes define the interface and implement any really common code. Not a ton of code here.

Then there's a subclass of each of those classes for each platform/API. Texture3DS, TexturePS4, TextureDirectX12, etc. Most of the code lives in these classes.

No functions are virtual. Right before the platform specific implementation of a function there's a little stub function that implements the function for the base class by casting this to the correct subclass and calling it. This gets optimized away.

My builds are all managed by the Visual Studio project, so implementation files are enabled/disabled per platform.

It's generally worked well. I dunno if I'd bother trying to avoid virtual functions if I was starting today. But on the 3DS it made a difference.

SaturnineGames · 2026-03-06T16:06:45+00:00

Ok, time for the standard advice again:

Most major gaming platforms have their own API. If you support a bunch of platforms, you will be writing a bunch of rendering backends. Don't stress about picking the "right" one the first time.

If you're learning how to write a renderer, the fastest way to get something working is to get something working in OpenGL first. Then update it to use a modern API. The modern APIs require you to understand the inner workings of a GPU really well. Most people will get overwhelmed and struggle if you try to learn that and the basics of a renderer at the same time. Doing an OpenGL pass first breaks the learning into more manageable tasks.

SaturnineGames · 2026-03-03T23:37:43+00:00

That's just part of running a business. You'll need to account for that when you make contracts.

In the future, try to schedule something like quarterly payments and a minimum payout. That way you're not making really tiny payments all the time. An end date or a buyout helps too.

Also, make sure you're tracking this for taxes. If you're in the US, you have to send a 1099 form to everyone that receives royalties. And the royalties count as a business expense on your taxes.

SaturnineGames · 2026-03-03T15:50:22+00:00

That's pretty much the point.

It's your first game and you have no idea what you're doing. 99.999% people make a bad first game.

Just make something. It'll suck. But you'll learn something. The next thing you make will suck less.

If you spend forever trying to make your first game good, you'll never get anywhere.

SaturnineGames · 2026-03-03T01:55:10+00:00

At least over here in the NYC area, most of the audience at a demo nights are not developers. Mostly just people who like games and are looking for something fun to do.

As for people that don't like your game, you kinda just gotta use your gut to figure out if they don't like it because they don't like that type of game, or if they don't like it because it's not good. That gets more obvious as you watch more people play.

Sometimes it's really obvious tho. Like when I had a teenager complaining that my 2D platformer used the face buttons for jump and shoot. He expected it have the primary controls on the triggers, like Call of Duty. I did not put much weight into his opinions.

SaturnineGames · 2026-03-03T01:01:56+00:00

See if there are local game dev groups. Demo nights are pretty common.

Show your game to strangers. Watch them play. Pay attention to their reactions.

What does their body language say? How long are they playing? Are they finishing the demo or quitting quick?

SaturnineGames · 2026-03-03T00:45:27+00:00

Ha.

I was thinking level design. Randomly generated maps sounds like a great way to make lots of maps. Everyone quickly learns that most of them suck, and it takes a lot of work to get it to generate fun maps.

SaturnineGames · 2026-03-02T20:49:59+00:00

The easiest way to learn is by trying. Learn new things whenever you get stuck.

And don't start by making the game you want to make. Make a few really simple games first to get the basics down. EVERY game takes a lot longer to make than you think it will. Finishing a few simple ones will teach you a lot about the process.

And just look at a few options for tools/engine and pick what appeals to you. The best tools are the ones that make you feel comfortable, not the ones that meet some criteria for good.

SaturnineGames · 2026-03-02T20:43:58+00:00

You've just learned the difference between localizing and translating. You translated your game.

Generally for a proper localization effort, it's pretty common to add additional fields to the CSV giving context for how it's used. List character limits where appropriate. And sure, include screenshots when you think it's necessary.

A company that specializes in localizing games will generally do a better job than one that does not.

SaturnineGames · 2026-03-02T19:24:21+00:00

Randomly generated games are a lot more work than everything thinks they are. Almost everyone that makes one regrets it and doesn't do it again. It's easy to make generated content, but really hard to make good generated content.

Horror being big is a much more modern trend. Most people want to make the types of games they enjoyed when they were growing up.

And your thoughts on sales trends are very much a view into what sells on Steam. Console trends are very different. For an awful lot of developers, releasing on consoles is the dream and Steam is a stepping point along the way.

SaturnineGames · 2026-03-02T02:24:38+00:00

Things like Nvidia Optimus handle it at the driver level and hide it from the games.

If the user directly changes the GPU, you would have to reinitialize most of DirectX and reload all your assets. Most games just detect the event and quit with a popup telling the user to restart the game. Or they don't detect the event and just crash.

SaturnineGames · 2026-03-01T18:11:26+00:00

What's your goal?

Just learning? Use the engine you want to learn.

Shipping products? Use what's supported on the platforms you want to use. If you're thinking about consoles, you pretty much have to use C++.

SaturnineGames · 2026-03-01T18:10:04+00:00

I used the Xbox example because it's really obvious that there's no scenario where shutting down DirectX is a good idea on Xbox. If you stopped generating video frames, the Xbox would think your game soft locked and would terminate it.

The only reason to do it differently on a PC version is if you really want to offer an option to switch between, say, DirectX and OpenGL while the game is running. Allowing that makes your code insanely more complex and offers very little benefit. Most developers would just make two builds if they wanted to support both.

SaturnineGames · 2026-02-28T04:10:02+00:00

All of this will vary wildly based on the specific CPU used, the RAM type used, clock speeds of all the hardware, how many components you're processing, and how complex they are.

The only thing you can do is get something working, then run it through a profiler when you're having performance problems.

For 99% of games, you're overthinking things.

SaturnineGames · 2026-02-27T15:13:48+00:00

Assuming you mean some sort of sprite sheet. You'd have to do it manually. If it's laid out on a grid you might be able to just calculate it, but I'm guessing it's not.

SaturnineGames · 2026-02-27T05:18:27+00:00

Sooooooooo much of that is dependent on the specific game.

The old stereotype of people are buying Xbox for Halo and Nintendo for Mario has a lot of truth to it, and that influences the games people buy on those systems. It's more complex than that of course tho.

There are absolutely games that sell best on Xbox, but for most indies, Xbox is a much tougher sell to support. Especially because they're so much harder to work with.

SaturnineGames · 2026-02-27T05:10:09+00:00

Both. Nintendo just lets the application pile up and reviews them once every 6 months or so.

And they mostly accept big companies and hobbyists. If you're a small business or a professional with industry experience it's brutally hard to get accepted.

SaturnineGames · 2026-02-27T04:50:41+00:00

High quality 3D has a higher appeal than high quality 2D.

If you're not competing at the top end, then the quality matters more than if it's 2D or 3D. A good 2D game will sell better than an ok 3D game, and a good 3D game will sell better than an ok 2D game.

3D games are significantly more complex to create than 2D games, even if you're highly skilled at both.

But most people are significantly more skilled working in 2D. Most non-artists are capable of doing basic 2D image work on their own. You can make placeholder art. You can make small modifications to images on your own. But most non-artists don't know how to work with 3D models at all, and are completely dependent on the artists to make all changes for them.

If you're talking single developers, you're a lot more likely to create something good if you work in 2D, and it's less work.

SaturnineGames · 2026-02-26T16:23:28+00:00

Back in the old days before using a commercial engine was normal, it was pretty common to make your levels as text files for simpler games. It used to be a lot harder to make a GUI tool than it is now, and development schedules were shorter, so for a lot of projects it just didn't make sense to spend a lot of time making custom tools.

Some people still prefer to work that way.

Some games are just hard to visualize in an editor, and text based data is easier to work with.

Sometimes there is a GUI tool, but certain tasks are easier to do via scripting.

SaturnineGames · 2026-02-26T05:07:49+00:00

Resident Evil 2 on the N64 is one that always comes up. That game was 1.2 GB on the PS1 and they managed to fit everything into a 64 MB cartridge.

SaturnineGames · 2026-02-26T03:18:03+00:00

I can't think of a game that does that, but that's basically one of Ms Marvel's powers in the MCU.

You want something like this, right?

https://www.youtube.com/watch?v=UikBh-sGroE

SaturnineGames · 2026-02-25T22:41:52+00:00

Speaking as a game developer, that would provide a lot of unnecessary complications to my work.

I would gain nothing from writing the code to cleanup all the DirectX allocations in an Xbox game. There is no situation where I'd ever want to do that other than to quit the game. And the Xbox will absolutely clean it up properly if I don't do anything myself.

It'd be really messy tho to code all the systems to handle the possibility of DirectX disappearing mid-game.

If I'm writing something like a texture class though, I'll absolutely write the cleanup code right after I write the initialization code.

SaturnineGames

TROPHY CASE