How to promote your game?

[Wuzzy]

So after 15 years of development (or so), the impossible has happened: You have finally finished your little free software game and feel super proud of it.

There's only one problem: Nobody except a tiny amount of people have ever heard of your game. Games are like art, their creators want them to be admired! What's the point of creating libre games, if nobody gets to enjoy them? I absolutely think we should be more outspoken about our games. Hence this thread.

So do you have any advice to spread a finished (!) libre game to a wider audience? Especially with a budget of 0?

Which tried and tested strategies do exist?
And which strategies are just a complete waste of time?
Which potential pitfalls do I have to avoid?

[fluffrabbit]

Wait a second... 15 years??? I thought 4-5 years of development was a long time, but this is ridiculous. I'd say if it's free-as-in-freedom so the hackers can be free, get it into Debian or whatever and post some letsplays.

[rubenwardy]

The same advice applies to free gaming as indie/proprietary.

If you've left it until your game is finished, you've left it too late! You should be doing marketing ever since you get a basic semi-playable alpha version, it allows you to obtain feedback and gain followers. Post dev logs, pretty gifs, and ask for feedback

Website - Create a website which acts as a primary "marketing" page for your game. It is very important to include a good description, galleries, and links important information. It's also important to have a modern web design, as bad designs make potential players doubt your artistic skills

Create trailers - Create trailers and demonstrations showing gameplay. This is often the first thing a potential player will see.

Social media presence - Create Twitter/Mastodon accounts, etc. A lot of more casual free software users will use Twitter, and not mastodon. You can bridge the two. Post dev logs, lots of gifs, respond to questions, run polls.

Post on reddit and such - It's a good idea to contact subreddit moderators first. Good subreddits include https://reddit.com/r/freegaming and https://www.reddit.com/r/opensourcegames/

[Lyberta]

Deleted.

[rubenwardy]

I'd say this is different for proprietary games. Since proprietary games are based on trade secrets, you only have 1 launch. If you launch as "early access", well, that's your launch. Nobody cares when you finish your game because by that time there will be thousands of other games on Steam.

With libre games, you constantly want more developers so you'd better go public when you have a gameplay prototype so ppl will fork your code and start contributing. Completely different.

Proprietary indie games tend to have many launches - early access, alpha versions, full release - and also tend to market pretty early on to gain validation and followers

[GunChleoc]

Also make entries on sites like heise.de, gog.com, indiedb.com etc...

Posts need to look professional and pretty (images, video trailer) and any tl;dr needs to be optional

[fluffrabbit]

This is better advice for promoting proprietary games than what can be found on most of TIGSource. Well done.

[GunChleoc]

I'm not a marketing expert. If you have some interesting information to share, please do.

[Julius]

Tongue in cheek mode: how about intentionally stirring up some social media shitstorm as even negative coverage is probably better than no advertisement. Call it viral marketing if you want

[fluffrabbit]

Trolling is a lot harder than it used to be. I think that somewhere during the development process, if you see people reacting positively to some aspect, focus on that.

[rubenwardy]

Tongue in cheek mode: how about intentionally stirring up some social media shitstorm as even negative coverage is probably better than no advertisement. Call it viral marketing if you want

I realise you aren't being serious, but this is a pretty bad idea and can wreck new projects

[Julius]

Yeah... thin line to walk on I guess

On a more serious note, I think foreign language coverage in markets/geographic areas not commonly using English as second language might have a very good effect (if your game is sufficiently multi-lingual of course). E.g. Spanish, German, French, Arabic?, Chinese, Japanese, Korean, Vietnamese etc.

[mdtrooper]

I think that to promoting a game is necessary:

The game has several packages types ( .deb, .rpm, .snap, .flatpak....)

If the game is in an official repository, it is a ten points.

[fluffrabbit]

Having something in official repos is very helpful, but I would think that most Linux users who go to the trouble of downloading an RPM would just compile it themselves.

[smcameron]

Having something in official repos is very helpful, but I would think that most Linux users who go to the trouble of downloading an RPM would just compile it themselves.

Unless they can just "yum install" or "apt-get install" it. That is, getting a game into the official distro repos is good (though the distro version will soon be out of date, if it is an active project.) Probably a lot harder now than it was say 10 or 15 years ago. And there are a *lot* of people that refuse to compile anything. For a lot of people, if they have to compile it, it might as well not exist. (Yet I still distribute my game only in source form.)

[fluffrabbit]

Refusing to compile anything, huh? Interesting philosophy in this community. This is why I hate everyone who isn't me. You can't just go along for the ride. If you want to use something other than Windows, Mac, or a mobile device, you have to sacrifice your time to learn the tools, or you have to pay me. I won't be flexible for people who are expected to be flexible but aren't. They can all go back to Mastodon with all their non-technical furry protester friends and die in a fur fire.

[smcameron]

Go look on r/linux_gaming, for instance. Most of those people will refuse to compile anything, in my experience. I wasn't talking about the freegamedev.net community.

[rubenwardy]

One of the benefits of Linux for me are the package managers. By not providing versions in the repositories of popular distros, you're missing out on users finding your game and users even trying out your game.

I want Linux to become available for the less technical users, because only then is there any chance of "the year of the Linux desktop". These elitest attitudes don't help with at all, and put off people who one day could become contributers or technical users

[smcameron]

One of the benefits of Linux for me are the package managers. By not providing versions in the repositories of popular distros, you're missing out on users finding your game and users even trying out your game.

I want Linux to become available for the less technical users, because only then is there any chance of "the year of the Linux desktop". These elitest attitudes don't help with at all, and put off people who one day could become contributers or technical users

Eh, the game is still evolving and the network protocol changes from time to time. Although it has been playable since 2013, any version of it that managed to get into any distro repo would be hopelessly out of date in a matter of a month or two. The distribution system is "git pull; make".

[Lyberta]

Deleted.

[rubenwardy]

Eh, the game is still evolving and the network protocol changes from time to time. Although it has been playable since 2013, any version of it that managed to get into any distro repo would be hopelessly out of date in a matter of a month or two. The distribution system is "git pull; make".

We provide PPAs and flatpaks for this reason

Also, I very much doubt it's "git pull; make". In my experience, you do that then get loads of linking errors or missing includes or plain weirdness

[smcameron]

We provide PPAs and flatpaks for this reason

Who's "we", and what do you provide?

Also, I very much doubt it's "git pull; make". In my experience, you do that then get loads of linking errors or missing includes or plain weirdness

The first time sure. Subsequent times, for my particular game, it's literally "git pull; make mostly-clean; make update-assets; make" I was exaggerating a bit. My game will be distributed when it's good enough someone other than me thinks it's worth packaging. If it's not at least that good, then it's not good.

[Jastiv]

ah, the dreaded dependency hunt - for a while it was known as "the only game for linux" I hate it when your distro doesn't come with the newest libraries that you need for the game (or worse yet, the game requires some old library your distro has already surpassed.) I have no idea what to do in those situations, and usually I give up. Sometimes I try again with a newer distro, only to end up with the same problem(s).

Java (sort of) solved this with SDKman where you can have multiple versions of stuff for the purpose of development and testing. I also know stuff like snaps, flatpacks and docker are popular, but I haven't experimented much with that, and not every hard to compile game has one of those. (besides doesn't someone have to put it in one of those in the first place?) Really, I'm talking more about how to get abandoned games or those with noob developers to compile.

Also, I very much doubt it's "git pull; make". In my experience, you do that then get loads of linking errors or missing includes or plain weirdness



The first time sure. Subsequent times, for my particular game, it's literally "git pull; make mostly-clean; make update-assets; make" I was exaggerating a bit. My game will be distributed when it's good enough someone other than me thinks it's worth packaging. If it's not at least that good, then it's not good.

I think it would be better to get other developers involved in the process early as possible so you can at least do some bug testing. If it is complex to compile it should come with directions. If no one else can compile it, it comes with a bus factor of 1.

[Julius]

The biggest problems is that C and C++ games use or don't even use package manager and build system. In Go you type "go build" and it downloads dependencies and builds everything, in $XDG_CACHE_DIR even, in Rust you type "cargo build" and sure enough, it does the same. In C and C++? Please "apt install" a shitload of -dev packages? What? Why do I need root to build? Why do I need to ruin my rootfs with this crap? And most importantly, how am I going to uninstall all this shit when the build is done? Debian has this "recommends" thing where if you install package, it installs recommended packages by default. But then if other packages... wait, is it "suggests"? Anyway, many times where I was putting the list of packages I just installed and uninstalled, I've found that a lot of times not all packages become "autoremovable". There is some kind of dependency hell going on. You really need to have a text document listing all the packages you've installed and the reason you did in order to manually remove them. This is insane.

So yeah, the correct way to build software is to use package manager that will install dependencies locally, statically link them and have an easy way to remove them after the build is done. This is the only way that doesn't turn your system into a garbage dump.

I hear that people these days make a build container (usually Docker) to circumvent this issue and have a clean & reproducible build environment. It can also be used to compile on a older LTS system like Ubuntu 16.04 even if your dev. system is more up to date.

[fluffrabbit]

I'm probably speaking out of my league here, but I don't think Docker is *the* solution. Yes, it keeps dependencies out of your root folders (I think). But you still have to run it as root and it's not particularly secure from malicious actors, especially if you're using it to get dependencies. Most Docker packages seem to be third-party. I only use Docker to run Emscripten. Everything else I am able to get working some other way.