There’s a popular joke about money and game development. It goes something like this: To make a small fortune from gamedev, start from a big one.

A key element of gamedev finances is risk. Games are entertainment products, and even when someone has a great time testing your game at a conference or all the reviews come in at 11/10, that still doesn’t mean people will want to give you money. You can have vocal fans demanding a balancing change, or people with 1,000 hours logged that never say a word. Neither ultimately help you pay the bills in the longer term. You’re always building your game with someone — maybe yourself — gambling on its potential. Taking a financial risk.

To provide material for discussion, this post will go over the often unintuitive ways game developers make money.

Enjoy. Or disagree in comments (or to annander@gmail.com).

Budgeting

Budgeting and cost analysis sounds about as exciting as it is. But if you want to make money making games you need to invest money or at least know how much you will be asking someone else to invest.

By far the biggest cost for digital game development is staffing. Estimates run as high as 90-95% of gamedev budgets (not counting marketing), but it really depends on how you structure your company. When you calculate your budget, the easiest way to start is to list all the roles you want to fill and then multiply that headcount by the number of months they must do their job. You then take this number and multiply it again by a set price per month that covers both expenses and salary. This last number is usually somewhere in the range €5,000 to €15,000 per developer per month, where 5k is an idealistic basement-based indie studio (at least in the west), and 15k just about covers a San Fransisco receptionist working half-time (I jest, but SF is incredibly expensive).

If you are a solo developer, don’t forget to set a rate for your own hours and tally them as a cost, even if that money is taken from some other fulltime job in practice. It’s still a budget; still an investment.

After summing up all staffing costs, add any other costs for software licenses, conferences, marketing, computer hardware, office rent, office cleaning, accounting, etc. Add everything, no matter if it’s €10 or €10,000.

Let’s say you have one artist/designer and one programmer. That’s two “roles.” Let’s say they will work 6 months. That’s 12 months total. Then slap a monthly cost on this, say €8,000. Maybe you’re also accumulating total additional costs that amount to €4,000 for some travel tickets and licenses. All those things added together come out to €100,000.

Once all is summed up like this, you add another 30% on top. Don’t ask why — just thank me later. Adding 30%, our budget amounts to €130,000. This would be the budget for this team of two to make a game in six months.

If you want to read more about game business, I recommend the books The Gamedev Business Handbook and The Gamedev Budgeting Handbook, both by Michael Futter.

Breakeven Formula

A handy formula for calculating how to achieve the following goals is:

Breakeven Sales = Budget / (Unit Price * X)

• Budget should be the total money that the game costs you to make (plus 30%).
• Unit Price is what you will be charging your players. In tabletop gaming, the Manufacturer’s Suggested Retail Price (MSRP) is often around five times the cost of production per unit. This would be a tough sell in video games. In digital games, what you charge for your game is much more hotly debated. Also note that “Unit Price” can be replaced by an Average Revenue Per User (ARPU) metric if you have more of a games as a service setup.
• X is a fraction of 1 that takes sales tax, platform cut, etc., into account and modifies the unit price accordingly. Do some digging into VAT rules for your country, so you can be sure that your revenue per unit is reflected.
• Breakeven Sales will be the number of units you must sell to make back your budget, in case of unit price, or the number of players you will need in case of ARPU.

Example 1: Total budget of €130,000, Unit Price at €19.99, and X of 0.5. Breakeven sales come out at 13,006 units (130,000 / (19.99 * 0.5)).

Example 2: Same budget, but with a €0.99 ARPU instead of unit price, you’d need 262,626 players to reach breakeven (130,000 / (0.99 * 0.5)).

Business Goal

Contrary to popular belief, the goal of making money as a business isn’t to be able to buy a Ferrari. Rather, there are four quite specific goals you can set out to achieve and anything beyond those goals is a bonus (literally).

Goal: Breaking Even

Your goal may simply be to break even. If you sell those 13,006 units, you’ve made back what you invested and lost nothing. You have a game out in the wild! This is fine as a goal. To see the time and money you put in returned in some form is more than most indies can say about their gamedev adventures.

A word of caution is that you should remember to count all the hours that you put into your project before you consider it breaking even. If you worked two hours every evening for a year, but you only calculated the budget based on money you paid for a sound commission, then “breaking even” won’t actually tell you anything. It’ll be undervalued to the point of meaninglessness. However, don’t put the Ferrari into your budget either. Focus on the cost of doing business.

One factor of breaking even you should also consider is the timeframe. Different strains are put on your finances depending on if you break even in a month, six months, or eight years. Consider a range of scenarios and their consequences before you commit to your project.

Goal: Sustainable Development

On the other hand, you may want to be able to sustainably make your next game. That requires your sales to hit breakeven quickly enough that you are paying for the next game in the meantime.

If you can achieve sustainability, you can keep making your small games as long as you keep making them. It’s the dream goal of many small indies I know, to have Game A pay for Game B pay for Game C, and keep you salaried, stress-free, and happy, along the way. No Ferrari, but the lights are kept on.

With a bit of luck, each project can provide you with passive income for a longer duration and the credibility and following you build over time may provide more stability than only relying on new releases for your income.

Goal: Growth

You may also want to get enough money back from your first investment to be able to scale up and build more ambitious projects after. Hire more developers, maybe get a nice office, make a multiplayer version, or deploy your game to more platforms.

It helps to look at money in a business less as money and more as investment capital. By all means, put some money in your own pocket as a reward for a job well done, but then you must account for it as well. Getting a Ferrari may sound amazing, but company capital that turns into private money gets taxed and won’t benefit the company’s long-term growth or short-term needs since it doesn’t exist anymore.

If you aim for growth, you need to put the costs for both Game A and your hoped-for future Game B into the Budget field of the breakeven formula. At that point, the numbers will grow considerably, and you’ll start understanding the complex nature of game finances. Not to mention the reason you will often want someone else to take the financial risk in your stead.

For most game studios that don’t have longterm first-party backing, growth will not be planned for but will happen organically due to Game A doing well enough to support it. You can’t count on it, but should at least be mentally prepared for it if it happens.

Goal: Art

Maybe you don’t actually care about breaking even, getting your money back, or any of it, because you either consider game development something you do for fun or you look at the things you make as a way to express yourself. You’ve probably read the past few sections feeling like you need to spit out the sour taste of capitalism.

If making art is the goal you have, then power to you, and may you find the expression and reach the audience that you seek. The rest of this post will probably not apply to you, but may still be interesting to read (I hope).

Revenue Streams

What is generally the most surprising to people when I discuss my job with anyone else, from gamers to people who have no personal experience with games, is that game developers actually rarely make their money from selling games.

It sounds deeply unintuitive, even as I type it, but it’s true.

To explain why this is, let’s talk about sales.

Direct Sales

Probably what most gamers think of as how game developers make money is by selling games to players of games. Putting your game in a store and asking for some money. A first party (the “producer”) sells their product to a second party (the “consumer”). Economy 101.

Unless you put a page up with your own Paypal connected, release your own launcher as the only place to buy your game, or travel to cons to sell physical copies, you are not actually making direct sales. There will almost always be a go-between that’s not just a banking or payment service.

One benefit of direct sales is that you won’t have to pay anyone a percentage. The downside, and why it’s quite uncommon, is that you must make everything yourself, including the server architecture to host your game, support forums, storefront, and so on. Things that will take time away from making the game.

Direct sales will affect your X considerably: it can go from 0,5 to 0,7 or higher since you are only paying taxes, backend costs, transaction fees, etc. and don’t need to pay a cut to any platform holder.

Platform Sales

Steam, App Store, Google Play, Good Old Games, PlayStation Store; there are many platforms where players can purchase games. You’ve heard of them, probably used more than one of them yourself as a consumer, and may have worked with them for your own projects.

Here’s the thing with these platforms: they have their own best interests in mind and not yours. When Apple was celebrating the 15th anniversary of the App Store in 2022, they said that “today, the App Store has more than 123 times as many apps — nearly 1.8 million — to choose from, compared to the thousands available on the App Store at the end of 2008.”

This isn’t good for you, the individual developer. It’s only good for the platform owner, who can attract people with the implied software diversity of their platform. In the case of this example, it’s Apple, but the same is true for Google Play, Steam, and all other online stores.

In fact, in the 2010s, some developers were talking about the “race to free,” which is an unfortunate side effect of the growth in competition. With more direct competitors for market attention, you are forced to rely on platform discount campaigns to shift more units. This means that your Unit Price from before is shrunk down by anything from 5-95%. You choose your own discount, of course, but if everyone else has a 95% discount and you provide 5%, this affects what people are likely to buy.

Some can make more money by offering a discount because they find the sweet spot between discount and volume, but the dark side of that moon is that your unit price may shrink so low that it has effects on your sustainability as a business.

Let’s say you used to get €19.99 for one unit before fees, but you discount it down to €4.99 in a Steam sale. Even such a thing as writing an answer to a support e-mail may start costing you more than your take from the sale of that customer’s unit. Meanwhile, the platform keeps getting its 30%.

This “race to free” has been accelerating for some time, and while Steam and Apple revenues soar, there is a shrinking number of developers who can actually sell enough to make a living. Something that gets further exacerbated by a growing number of competitors with a decreasing development time cycle.

Looking at VGInsights.com and its Revenue Distribution, you can see that only about 12% of all purchasable games on Steam made enough money to break even with our budget example from before. A percentage inclusive of all $50k+ brackets, even though the $50k-200k bracket is heavily skewed towards the bottom. So that 12% is likely to be lower in reality.

If you sell your game on Steam, your game must do better than 88% of games on the platform if you want to have a chance to make enough money to break even with a €130k budget.

This doesn’t mean you shouldn’t use Steam or the App Store. You just need to be aware of its caveats and prepare to make less per unit than may actually be sustainable.

Also, don’t kid yourself in this regard. AAA and AAAA may be able to set prices at €70 and beyond per unit, but that’s because of a long-standing direct relationship with their customers. If you, as the theoretical small indie, push prices too high, people simply won’t buy your product. For you, the race to free is real.

Platform sales is more or less the assumption. Your X will be around 0,5 depending on your taxes. But at least some other fees, including transaction fees, are baked into the platform’s cut. You should add unit price discounts into your breakeven sales calculations, because you are very likely to have to do them at some point and you need to know what that means for your numbers.

Third-Party Contracting

A game can’t make any money until it’s actually ready and done. Before then, someone still needs to foot the bills. This is why it’s common that your studio doesn’t make money from selling games but from delivering milestones to someone else who is fronting that money and taking the financial risk.

This can either be third-party contract work delivering a whole game, or it can be what’s referred to as co-development or just codev.

Requests for Proposal

A Request for Proposal (RFP) is a document that asks you to pitch your version of something. Classic examples are spinoff sequels and movie tie-ins, but a RFP can ask for almost anything. If you run a studio known for a certain thing, you may get RFPs asking you to pitch that thing within certain creative boundaries.

I can’t use real world examples for obvious reasons, but RFPs can be anything from a single page asking you to hop onto a call and discuss specifics with the owner of an intellectual property (IP), to giant design bibles asking you to add the flavor on top that your studio is known for. Picture HBO contacting you to make a Game of Thrones-based strategy game, for example. They’d be doing so with a RFP.

Unsolicited Pitching

Probably what most people think of as “pitching” isn’t based off a RFP but is the style of pitch that you write yourself and bring to a publisher at a conference or some other gathering. Today, you must usually bring a prototype as well if you want to be seriously considered.

This is particularly common among indie developers, who often strive to sell their creativity more than their credentials, but is actually not as important as you may think. Not in the grander scheme of things.

Be mindful that no one will ever say “no” to you while pitching. They may ask for more details, a bigger prototype, a functional build, or something else, but they will rarely say no. Whatever you do, don’t take a lack of nos to mean yes. Pursue multiple leads, and if things don’t move forward, move on.

Milestones

Once your pitch is successful, you agree on a timeline and a budget, and schedule some milestone deliveries. The cadence of milestones varies immensely. Maybe you can have weekly check-ins with your publisher sometimes, while at other times it’s half a year between deliveries. Generally, the longer time you have, the tougher the requirements will be.

Usually, a plan outlines what needs to be achieved at each milestone and once a milestone gets accepted an agreed amount of money shows up in your bank account. There can also be termination clauses built into a contract, where a certain number of failed milestones voids the entire contract. There can be cancellation fees to be paid, or penalties, and so on. How contracts look like is almost as varied as the stars in the night sky.

Milestone payments will cover your running costs, and if you added those 30% I told you to add, they may give you a little bit of margin on top. But they also tie your company’s survival to the consistency of your financer’s payments.

With milestone payments, you don’t need to do the breakeven calculation, because that whole thing is up to your financer. But you will also have to be more specific with your budgeting, and may have to cut some costs that the financer doesn’t think is worth it. Some costs may also be cut because it’s something that the financer can help you with; for example if you are working with a first-party publisher who also owns a platform, like Microsoft or Sony. Then they will be able to help you get your game onto their platforms, among other things.

Bonuses and Royalties

Maybe you are asking yourself how you can possibly reach your goals of growth or sustainability if you are only getting paid for milestone delivery. The answer is generally quite simple: you can’t. But it’s not all doom and gloom either. Many contracts will have various forms of bonuses that can be paid out if a game does particularly well.

A bonus on delivery can be applied. Usually tied to delivering faster or to a higher standard (for example, a better Metacritic score). There can also be penalties to this or reductions to other bonuses if a project gets delayed or fails to achieve agreed-upon goals.

There can also be straight-up royalties. Maybe you get 20% on all revenue that the game accumulates in stores. This is where the concept of “advance on royalties” will often come in and bite you. If you have such a contract, which was probably more common 10+ years ago, your 20% royalty will have to pay back all of those juicy milestone payments you got before you can bank any money towards your sustainability or growth.

In other words, with a 20% advance on royalty, the financer will have to make its costs back five times over before you start seeing any royalties. Chris Taylor, then of Gas Powered Games, once called this a “500% loan.”

The reality of the model described here is that most games either don’t break even at all or barely break even, for the developer, but the financer can still break even. In the meantime, the developer is forced to look for a new project with new milestone payments coming in or they are forced to cut staff or may even go bankrupt. This is one of the reasons you sometimes see studios do massive layoffs right after project delivery: no more milestone money coming in, and uncertainty around royalty profits for anything that isn’t an immediate hit.

Codev

Many studios today don’t make their money making their game but solving the problems of bigger or more financially successful studios. This can be to handle porting, localisation, rendering optimisation, bug fixing, testing, or really any other thing that you can specialise in and that another studio may want to pay for.

A codev studio may have the ambition to make its own games on the side, but codev can also be good business in itself. Particularly if you have a solid network of contacts that can provide you with a steady stream of work.

It’s not unusual for experienced developers to found smaller codev studios that then sell their work to previous employers. It allows a bit more independence and flexibility.

Codevs will usually function like any other contractor would, with an agreed-upon fee paid per developer per hour, week, month, or other time unit. As an example, a codev that charges $50/h (plus tax) would be paid around $8,000 per fulltime developer per month (i.e., 50 * 160).

Crowd Funding

In 2012, Tim Schafer’s iconic studio Double Fine made games industry history. They launched their “Double Fine Adventure” crowdfunding campaign on Kickstarter, promising to make the kinds of point-and-click adventure games that Schafer used to work on back in his Lucas Arts days. The campaign went on to pull in $3,336,371 from 87,142 backers, while originally asking for $400,000, and demonstrated quite clearly that there was real money to find in crowd funding.

However, before you jump off to work on your crowdfunding page, you must first realise two things. First, that Tim Schafer’s credentials as a developer was already proven and his quirky adventures from the past were games that many remembered fondly. Second, that even three million dollars is actually not all that much money for a mid-sized game project. Remember that just two people working for six months amounted to a €130k budget. Try doing the numbers for 15-20 people working for two years or more, and deduct all the costs to produce and ship the physical rewards you promised to some backers.

Crowd funding can be incredibly successful. Let’s not forget to mention Star Citizen in this context, having made over $800,000,000 selling what Wired once called “doubly virtual” space ships. But the fact is that building a successful crowd funding campaign today is extremely hard and also unlikely to give you enough money to finish your game.

Crowd funding can be used to gauge interest and to get you enough cash to build a prototype to bring to a publisher, but beyond that it’s a massive amount of risk to rely on crowd funding to pay your bills. The draw, of course, is that you’d only pay Kickstarter’s fees and taxes; you get to keep the rest. But if you think milestone penalties sounds like a tough consequence of delays, wait until you see the reactions of your future crowd funders when you tell them that they’ll have to wait another six months.

Ad Revenue

With the explosion of Roblox and Fortnite, an entirely new revenue stream came to games: advertising revenue. Not just in the form of popup ads, like we’ve seen for years, but pure advertising. Big brands and franchises like Nike or Burger King, with giant treasure chests of advertising money normally transformed into TV commercials and roadside billboards, now want to grab the attention of the hundreds of millions of kids who are playing these insanely popular games.

Of course, games have had instances of this before. It’s not entirely new. The Flash era, Second Life, and the various multimedia enterprises that cropped up to make low (and big) budget FMV games had similar goals and probably similar financing as well. So in a way, the current wave of ad revenue is just a much bigger version of what has come before.

But what it means is that you can certainly make a living from building Roblox experiences or Fortnite levels for big brands.

Service Games

Though gamers may talk about Games as a Service (GaaS) kind of how the characters in Harry Potter talk about Voldemort, service games are some of the most lucrative games on the market. One reason is that they typically have no spend ceiling. Where the types of sales we based the budget example on earlier have a unit price, a service game’s price range is between €0 and infinity.

Nicholas Lovell, in his book The Curve, refers to customers who pay nothing as freeloaders, but also point out that they are a crucial part of how you get superfans. Customers who can pay you so much money that they can finance your whole studio. Data varies between games, but some GaaS projects will see just 5-10% of players represent 90% of the continuous income.

One key transformation that happens when you start working on a service game is that you have to make business and monetisation part of the whole experience. It’s not unusual for service games to apply various dark patterns in their user experience and to incorporate behavioral sciences in ways that are absent from other types of games.

Just think about how many of World of Warcraft‘s features are built around wasting your time. Be it fighting the same monsters over and over, playing the same raid multiple times, or having to find your way back to your dead remains after getting killed. This ties quite nicely into the fact that you are paying a monthly subscription. For as long as the game can have you waste your time (willingly and lovingly, mind you), the developers keep making money.

Publishers and Investors

On one side of the table you have yourself, a hopeful developer that may or may not run out of money a month from now and that are seated at this particular table maybe once every few years. On the other side, you have a professional negotiator who holds practically all the cards. Your future is in their hands.

If you are going to a publisher or investor hoping that they will pay your budget, you are asking them to take the financial risk and you will have to make some kind of tradeoff for this to be worth it for them.

If you attempt to go the publisher or investor route, you can forget about anything beyond sustainability. No publisher or investor out there will pay you ten times what your current game will cost to make in order to finance your future growth. They will pay you the least amount of money that they can get away with, and the pressure is then on you.

Portfolio

The reasons publishers have for parting with their money in one instance but not in another are sometimes indecipherable to us mere mortals. Some deals can be signed based on timing and how your game fits a financer’s portfolio. This type of deal can have decent terms, but can also come with the strangest of caveats.

If you are a publisher, and maybe for some investors too, what matters sometimes isn’t so much the game you are financing as its place in the larger scheme of things. Maybe you don’t have enough releases to coincide with Christmas, or you haven’t released a contemporary game or fantasy game in a long time and your competitors are about to do so.

If you can find this type of slot with your game, as a developer, it can be a golden opportunity. But it won’t give you the biggest budgets or most generous timelines.

Revenue

Probably the most common exchange is to sell parts of your future revenue to a publisher. This is that “advance on royalties” scenario that was mentioned earlier. You get paid up front, usually in milestone arrears, and you then pay everything back once the game launches.

It’s actually not that common for publishers to ask for the big 80% chunk anymore. Today it’s more common with something like 50%. The more risk you take yourself, the better. So a game that has a solid playable prototype that demonstrates both that the game is worth making and that you are the ones who should make it will put you in a better negotiation spot and may allow you to keep a bigger percentage of potential future revenue.

Just remember that the publisher is taking the biggest risk. If your game doesn’t make any money, they will still have lost theirs, while you can just walk away.

Co-ownership

Some investors, and more rarely publishers, will want a percentage of your game company and a proportional role in your business decisions.

There are some tricky things with trading money for equity. For example, if you start at a rate of €1,000 per percent in your company, that caps how much money you can get in and may force you to sell more of your company than you want if you run into delays. It’s also all but impossible to get someone who comes in later to pay more than the previous rate per share, unless something drastic happens to your evaluation.

Another tricky thing is to make sure to rely on what’s called “smart money” in finance. You don’t want partners whose only contribution is money. You want them to know the business, have good contacts, or provide extra value of some other kind. If they don’t, it may not matter how much money they offer, because they are not improving your chances.

Exit

During a PocketGamer meetup a few years ago, there was a panel on investment in games and how to build sustainable businesses. One topic that came up was exits. An exit is when someone who owns equity in something sells that something at a higher valuation than it was bought and then leaves (“exits”) the company. When a big-name game company is sold, it’s likely that it’s because some of its investors made an exit on their investment. Sold off all their shares, took the money, moved on.

For years, this was what investors in gaming were after. If you played your money right, you could get returns on investment that were 10-100 times the money you invested. This was one of the reasons that there was so much “free” money to be had. It was simply quite lucrative to invest in games, with the kinds of payoffs that made the risk of losing it all quite worth it.

In that PocketGamer panel, a developer in the crowd asked a question. “What if we really believe in what we do, and we don’t want an exit, can we still find investors?”

Few things illustrate the mentality of some investors better than one panelist’s answer. They laughed, waved their hand dismissively, and said something like, “Why wouldn’t you want an exit? You can take the money and start a new company.”

All of that is to say, if you work with investors who are looking to make a buck on your credibility in this way, you need to be aware of it and in on it. They are not investing in you because they believe in you or your game, but because they believe in the potential to grow the value of their investment. In some cases, this means talking about the game being made to make the market react, and not to actually deliver the game.

It’s an investment strategy and not a creative enterprise. Know if that is what you want before you sign at the dotted line.

Full Ownership

One model you may run into is a setup where an external party buys your company outright. Usually paid for with shares in something else, such as the parent company. This can provide a safety net if the organisation is a mature one but also means that you are going from a founder or co-owner role to become what amounts to a glorified employee.

If you can retain some authority over what you are selling, or if all you want is the relative safety of a larger organisation, this can still be worth it. Just be very careful to read the contract terms.

Making Money Making Games

Many developers I know have a romanticised image of the scrappy indie developer bursting onto the scene and taking home enough money to never have to work again. For several decades, the aspirational image was that of id Software’s DOOM-delivering founders posing with their Ferraris.

But here’s something you need to remember. id Software was an independent company. They didn’t “just” make a good game and then get rich, they owned their intellectual properties, the technology they worked on, and they also experimented with how to sell and distribute games in the early 90s. There was no 30% Steam fee, no publisher taking a 50% cut of revenues (actually, for DOOM retail sales, GT Interactive took 80%…), no advance on royalties; it was all (mostly) theirs.

Every time you give something away, whether it’s stock in your company, future revenues, or IP rights, you’re making a tradeoff that may buy you some security in the short term but will also cost you parts of your independence.

If there’s any single takeaway you can make from this long-winded post on unintuitive ways to make money, it’s that. Consider carefully what you are willing to sacrifice, because you will have to sacrifice something.

If at all possible under your particular circumstances, experiment and prototype with business the same way you would with gameplay.

Don’t assume that you must have a publisher, or that you must use Steam to sell your game. Don’t assume anything.

.

Read the full article on GamingOnLinux.

"I've always been jealous of the glory authors get," explained Wolverton, assembling fresh Ikea bookcases to display his newly-published oeuvre. "Actual writing takes time away from surfing for deepfake porn. I just want books with my name on them to impress my friends. ChatGPT made that happen."

Chaz is not alone. Machine learning engineers believe millions yearn to be creativity-adjacent.

"These people are entirely bereft of the basic skills necessary for creativity and they aren't interested developing them," said Victor Drolet, Spicy Autofill Evangelist. "A few could potentially string enough words together into something worth reading, but research shows they will never try."

Egon Hunt, who teaches a $4000, eight-week online prompt engineering course, asserted that "authors" like Wolverton can fulfill dreams of passing as a real-enough writer to those who don't read. "A creative vacuum like Chaz can manage to type in a few prompts, and then the LLM does all the rest." [...]

Accusations that LLMs combine greed with sloth are "narrow-minded", assert experts. With the right prompts, they insist LLM's can deliver far more comprehensive moral transgressions. "In addition to the classical seven deadly sins," adds Drolet, "LLMs even generate entirely new deadly sins such as grath, hoth, and lurm!"

Previously, previously, previously.

When debugging Java programs, developers are often under the impression that they’re interacting directly with the source code. This isn’t surprising – Java’s tooling does such an excellent job of hiding the complexity that it almost feels as if the source code exists at runtime.

If you’re just starting with Java, you likely remember those diagrams showing how the compiler transforms source code into bytecode, which is then executed by the JVM. You might also wonder: if that’s the case, why do we examine and step through the source code rather than the bytecode? How does the JVM know anything about our sources?

This article is a little different from my previous posts on debugging. Instead of focusing on how to debug a specific problem, such as an unresponsive app or a memory leak, it explores how Java and debuggers work behind the scenes. Stick around – as always, a couple of handy tricks are included.

Bytecode

Let’s start with a quick recap. The diagrams found in Java books and guides are indeed correct – the JVM executes bytecode.

Consider the following class as an example:

package dev.flounder;

public class Calculator {
    int sum(int a, int b) {
        return a + b;
    }
}

When compiled, the sum() method will turn into the following bytecode:

int sum(int, int);
    descriptor: (II)I
    flags: (0x0000)
    Code:
      stack=2, locals=3, args_size=3
         0: iload_1
         1: iload_2
         2: iadd
         3: ireturn

Tip: You can inspect the bytecode of your classes using the javap -v command included with the JDK. If you are using IntelliJ IDEA, you can also do this from the IDE: after building your project, select a class, and then click View | Show Bytecode.

Note: Since class files are binary, citing their raw contents would not be informative. For readability, the examples in this article follow the format of javap -v output.

Bytecode consists of a series of compact platform-independent instructions. In the example above:

1. iload_1 and iload_2 load the variables onto the operand stack.
2. iadd adds the contents of the operand stack, leaving a single result value on it.
3. ireturn returns the value from the operand stack.

In addition to instructions, bytecode files also include information on the constants, the number of parameters, local variables, and the depth of the operand stack. This is all the JVM needs to execute a program written in a JVM language, such as Java, Kotlin, or Scala.

Debug information

Since bytecode looks completely different from your source code, referring to it while debugging would be inefficient. For this reason, the interfaces of Java debuggers – such as the JDB (the console debugger bundled with the JDK) or the one in IntelliJ IDEA – display the source code rather than bytecode. This allows you to debug the code that you wrote without having to think about the underlying bytecode being executed.

For example, your interaction with the JDB might look like this:

Initializing jdb ...

> stop at dev.flounder.Calculator:5

Deferring breakpoint dev.flounder.Calculator:5.
It will be set after the class is loaded.

> run

run dev/flounder/Main
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
VM Started: Set deferred breakpoint dev.flounder.Calculator:5
Breakpoint hit: "thread=main", dev.flounder.Calculator.sum(), line=5 bci=0

> locals

Method arguments:
a = 1
b = 2

IntelliJ IDEA will display the debug-related information in the editor and in the Debug tool window:

As you can see, both debuggers use the correct variable names and reference valid lines from our code snippet above.

Since the runtime doesn’t have access to the source files, it must collect this data elsewhere. This is where debug information comes into play. Debug information (also referred to as debug symbols) is compact data that links the bytecode to the application’s sources. It is included in the .class files during compilation.

There are three types of debug information:

• Line numbers
• Variable names
• Source file names

LineNumberTable:
line 5: 0
line 6: 2

Importantly, line number information is also used for source references in exception stack traces. In the following example, I compiled code from my other tutorial without line number information:

Exception in thread "main" java.lang.NumberFormatException: For input string: ""
at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
at java.base/java.lang.Integer.parseInt(Integer.java:672)
at java.base/java.lang.Integer.parseInt(Integer.java:778)
at dev.flounder.Airports.parse(Airports.java)
at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1939)
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
at dev.flounder.Airports.main(Airports.java)

The executable compiled without line number information produced a stack trace that lacks line numbers for the calls corresponding to my project code. The calls from the standard library and dependencies still include line numbers because they have been compiled separately and weren’t affected.

Besides stack traces, you may encounter a similar situation where line numbers are involved, for example, in IntelliJ IDEA’s Frames tab:

So, if you see -1 instead of actual line numbers and want to avoid this, make sure your program is compiled with line number information.

Tip: You can view bytecode offset right in IntelliJ IDEA’s Frames tab. For this, add the following registry key: debugger.stack.frame.show.code.index=true.

Variable names

Like line number information, variable names are stored in class files. The variable table for our example looks as follows:

LocalVariableTable:
Start  Length  Slot  Name   Signature
    0       4     0  this   Ldev/flounder/Calculator;
    0       4     1     a   I
    0       4     2     b   I

It contains the following information:

1. Start: The bytecode offset where the scope of this variable begins.
2. Length: The number of instructions during which this variable remains in scope.
3. Slot: The index at which this variable is stored for reference.
4. Name: The variable’s name as it appears in the source code.
5. Signature: The variable’s data type, expressed in Java’s type signature notation.

If variables are missing from the debug information, some debugger functionality might not work as expected, and you will see slot_1, slot_2, etc. instead of the actual variable names.

Source file names

This type of debug information indicates which source file was used to compile the class. Like line number information, its presence in the class files affects not only external tooling, but also the stack traces that your program generates:

Exception in thread "main" java.lang.NumberFormatException: For input string: ""
	at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
	at java.base/java.lang.Integer.parseInt(Integer.java:672)
	at java.base/java.lang.Integer.parseInt(Integer.java:778)
	at dev.flounder.Airports.parse(Unknown Source)
	at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
	at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
	at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1939)
	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
	at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
	at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
	at dev.flounder.Airports.main(Unknown Source)

Without source file names, the corresponding stack trace calls will be marked as Unknown Source.

Compiler flags

As a developer, you have control over whether to include debug information in your executables and, if so, which types to include. You can manage this by using the -g compiler argument, like this:

javac -g:lines,vars,source

Here is the syntax:

Note: Defaults might vary between compilers. Some of them completely exclude debug information unless instructed otherwise.

If you are using a build system, such as Maven or Gradle, you can pass the same options through compiler arguments.

Maven example:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.11.0</version>
    <configuration>
        <compilerArgs>
            <arg>-g:vars,lines</arg>
        </compilerArgs>
    </configuration>
</plugin>

Gradle example:

tasks.compileJava {
    options.compilerArgs.add("-g:vars,lines")
}

Why remove debug information?

As we’ve just seen, debug symbols enable the debugging process, which is convenient during development. For this reason, debug symbols are usually included in development builds. In production builds, they are often excluded; However, this ultimately depends on the type of project you are working on.

Here are a couple of things you may want to consider:

Security

Since a debugger can be used to tamper with your program, including debug information makes your application slightly more vulnerable to hacking and reverse engineering, which may be undesirable for some applications.

Although the absence of debug symbols might make it somewhat more difficult to interfere with your program using a debugger, it does not fully protect it. Debugging remains possible even with partial or missing debug information, so this alone will not prevent a determined individual from accessing your program’s internals. Therefore, if you are concerned about the risk of reverse engineering, you should employ additional measures, such as code obfuscation.

Executable size

The more information an executable contains, the larger it becomes. Exactly how much larger depends on various factors. The size of a particular class file might easily be dominated by the number of instructions and the size of the constant pool, making it impractical to provide a universal estimate. Still, to demonstrate that the difference can be substantial, I experimented with Airports.java, which we used earlier to compare stack traces. The results are 4,460 bytes without debug information compared to 5,664 bytes with it.

In most cases, including debug symbols won’t hurt. However, if executable size is a concern, as is often the case with embedded systems, you might want to exclude debug symbols from your binaries.

Adding sources for debugging

Typically, the required sources reside within your project, so the IDE will have no trouble finding them. However, there are less common situations – for example, when the source code needed for debugging is outside your project, such as when stepping into a library used by your code.

In this case, you need to add source files manually: either by placing them under a sources root or by specifying them as a dependency. During debugging, IntelliJ IDEA will automatically detect and match these files with the classes executed by the JVM.

When the project is missing

In most cases, you would build, launch, and debug an application in the same IDE, using the original project. But what if you have only a few source files, and the project itself is missing?

Here’s a bare-bones debugging setup that will do the trick:

1. Create an empty Java project.
2. Add the source files under a sources root or specify them as a dependency.
3. Launch the target application with the debug agent. In Java, this is typically done by adding a VM option, such as: -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005.
4. Create a Remote JVM Debug run configuration with the correct connection details. Use this run configuration to attach the debugger to the target application.

With this setup, you can debug a program without accessing the original project. IntelliJ IDEA will match the available sources with the runtime classes and let you use them in a debugging session. This way, even a single project or library class gives you an entry point for debugging.

For a hands-on example, check out Debugger.godMode() – Hacking JVM Applications With the Debugger, where we use this technique to change a program’s behavior without accessing its source code.

Source mismatch

One confusing situation you might encounter during debugging is when your application appears suspended at a blank line or when the line numbers in the Frames tab don’t match those in the editor:

This occurs when debugging decompiled code (which we’ll discuss in another article) or when the source code doesn’t fully match the bytecode that the JVM is executing.

Since the only link between bytecode and a particular source file is the name of the file and its classes, the debugger has to rely on this information, assisted by some heuristics. This works well for most situations. However, the version of the file on disk may differ from the one used to compile the application. In the case of a partial match, the debugger will identify the discrepancies and attempt to reconcile them rather than failing fast. Depending on the extent of the differences, this might be useful, for example, if the only source that you have isn’t the closest match.

Fortunately, if you have the exact version of the sources elsewhere, you can fix this issue by adding them to the project and re-running the debug session.

Conclusion

In this article, we’ve explored the connection between source files, bytecode, and the debugger. While not strictly required for day-to-day coding, having a clearer picture of what happens under the hood can give you a stronger grasp of the ecosystem and may occasionally help you out of non-standard situations and configuration problems. I hope you found the theory and tips useful!

There are still many more topics to come in this series, so stay tuned for the next one. If there’s anything specific you’d like to see covered, or if you have ideas and feedback, we’d love to hear from you!

Das Test-Sonderheft von Retro Gamer kann jetzt vorbestellt werden – und jede Vorbestellung erhöht die Chance, dass das Heft auch wirklich gemacht wird.

Kurz und bündig das Wichtigste zuerst:

• Wir machen unser erstes “eigenes” Sonderheft!
• Es wird 196 neue Seiten haben, also 0% Wiederverwertung.
• Tests von 90er-Jahre-Klassikern aus heutiger Retrofan-Sicht, für alle Plattformen
• Wertungen und Wertungskästen fast „wie damals“
• Noch besseres Papier als im Hauptheft!

> Und hier ist der Shop-Link zur Crowdfunding-Vorbestellung <<

Und jetzt die Langfassung: Für unser erstes eigenes Sonderheft steigern wir den Aufwand noch mal beträchtlich: Das Sonderheft „Die 90erJahre“ wird mit 196 Seiten um 16 Seiten umfangreicher als das Hauptheft, und wir nehmen dickeres Papier. Und wir schreiben jede Seite neu.

Unser 1. Sonderheft liefert etwas, das ihr im normalen Retro Gamer nicht findet: Retro-Spieletests. Natürlich steht dabei weniger die Kaufberatung im Vordergrund als vielmehr Einordnung und Würdigung. Wir schauen uns hochbewertete sowie unterschätzte Spiele von damals neu an. Wir bewerten sie aus heutiger Retrofan-Sicht: weder durch die rosarote Brille, noch als pedantische Liste von Unvollkommenheiten. Wir erwarten keine Prachtgrafik oder modernen Komfortfunktionen. Wir erwarten aber, dass das Spiel heute noch Spaß macht.

Wieso die 90er Jahre als Thema? Weil es vielleicht das beste Spielejahrzehnt überhaupt war – und weil ihr euch mehrheitlich für dieses Thema entschieden habt bei unserer großen Sonderheft-Umfrage. Die 90er Jahre sahen das Ende der Homecomputer-Ära (mit einigen letzten, genialen Vertretern), den Aufstieg des Spiele-PCs, die Transformation der Konsolentitel von modulbasierten zu CD-ROM-Spielen. 3D-Karten und -Chips kamen auf, gleichzeitig feierte die liebgewonnene „16-Bit-Grafik“ weiterhin Höhepunkte.

Wieso der Fokus auf Spieletests statt unserem normalen Mix aus Interviews, Making ofs und Co.? Weil wir euch eben nicht nur „mehr vom Gleichen“ verkaufen wollen. Und weil wir in der RG-Redaktion wehmütig an Magazine wie die Happy Computer Spiele-Sonderhefte zurückdenken, die gekonnt Bekanntes und Unbekanntes zusammenfassten, Marktüberblick und Lesespaß vereinten. Das Sonderheft stammt vom deutschen Retro-Gamer-Team, ergänzt um einige neue Schreiber. Und ja, es wird ein 100er-System und “Wertungsgesichter” geben!

Die gewohnte, hohe Qualität bei 0% Wiederverwertung kostet Geld. Eine Auflage von nur wenigen tausend Stück (im Vergleich zu den 17.000 und mehr beim Hauptmagazin) erhöht die Kosten pro Heft. Mehr Seiten und bessere Papierqualität kosten zusätzlich. Jede Seite neu zu schreiben kostet Geld. Deshalb müssen wir den Preis fürs Sonderheft im Vergleich zum Hauptheft um 5 Euro anheben, auf 19,90 Euro (plus Versand). Dieses Sonderheft wird es nicht am Kiosk geben, sondern maximal im Bahnhofsbuchhandel – doch die Entscheidung für letzteren ist noch nicht gefallen. Mit einer Vorbestellung seid ihr auf der sicheren Seite und helft mit, das Projekt überhaupt zu verwirklichen.

HILF MIT, UNSER SONDERHEFT WAHR WERDEN ZU LASSEN!

Noch ist das Spiele-Sonderheft “90er Jahre” nicht in trockenen Tüchern. Das Konzept steht, das Layout steht, die konkrete Heftplanung ist weit fortgeschritten. Wir wollen das Projekt mit Bedacht und genügend Zeit angehen. Die Veröffentlichung ist darum erst für November 2025 geplant. Würden wir nun aber über ein halbes Jahr hinweg an einem Magazin werkeln, das dann womöglich zu wenige Käufer findet, wäre das nicht gut für das kleine gallische Dorf in Putzbrunn, in dem Retro Gamer verlegt wird.

Deshalb haben wir bereits jetzt den Vorverkauf (Neudeutsch: Crowdfunding) eröffnet, denn eine Bestellung nebst Zahlung ist ein realistischer Gradmesser für das vorhandene Leser-Interesse. Sollte sich das Sonderheft wider Erwarten als nicht realisierbar erweisen, erhaltet ihr natürlich euer Geld zurück.

Aufgrund des Crowdfunding-Charakters wäre es wichtig, dass ihr uns schon jetzt unterstützt. Wir peilen mindestens 1.000 Vorbestellungen bis Anfang Juli als Ziel an. Damit sind zwar die Kosten noch nicht drin, aber dann halten wir die Chance für sehr hoch, dass bis Jahresende 1.000 bis 2.000 weitere Käufer dazu kommen werden. Natürlich werden wir unsere Supporter wissen lassen, wie der Stand ist!

Über die vier Varianten von ePaper (15 Euro) bis Superduper-Förder-Angebot (129 Euro) informiert euch unsere Shop-Seite zum Spielesonderheft.

Mozilla's recent announcement about the shutdown of its Pocket service has taken many users by surprise. We wanted to share some thoughts as a farewell message to Pocket and to talk about the available options for Pocket users looking for a new platform.

Pocket and the early days of wallabag

Back in 2013, Google decided to kill one of its most famous product, Google Reader. As a Pocket user at that time, Nicolas asked himself what would happen to his data and all these saved articles if Pocket decided to do the same. Then, wallabag was born. Well, it was known under the name "poche" in its early days, which means "pocket" in French, and for the fun fact, the change of name is a result of a trademark issue with... Pocket's company, Read It Later, Inc. Therefore, poche became wallabag in early 2014.

Here are some articles if you want to read more about this backstory:

• Open letter addressed to Read It Later, Inc., creator of Pocket
• Pocket reply
• Let's go!

In 2017 Mozilla Corporation announced the acquisition of Pocket and planned to open-source the server part, which was never fully done.

So Long, and Thanks for all the Fish, Pocket; Or we should say: thanks for pushing us to change our name and thanks for streamlining read-it-later apps.

Surviving the web by being open

It's always bittersweet to watch a service shutting down, especially when this one was widely known and used. Omnivore is another read-it-later service that was shut down in late 2024. In both cases it was the decision of a for-profit coproration killing a product they bought. Mozilla explained that their decision was made because "the web and the way we are using it changed a lot". Even though this statement is true, we still strongly believe in giving power to people and helping them to keep control of their data and privacy.

That's why we still continue to develop wallabag, 12 years after its creation.

You are a Pocket user? Read this

Further reading from Mozilla:

• Pocket is saying goodbye - What you need to know
• Investing in what moves the internet forward

Now that Pocket is expected to close this year, what to do if you are a user?

The most important thing is to ask an export of your data, ideally an export that could include the content that has been fetched with the links. This will at least let you keep the list of links you've saved over time.

Then if you are seeking for an alternative to Pocket to continue saving articles, here are some ideas:

• You can self-host your own wallabag instance
• Or you can subscribe to wallabag.it if you don't want to manage anything
• You can also find other wallabag instances through CHATONS

wallabag is not the only read-it-later app available, you can also take a look at Readeck and Raindrop, to name a few.

End words

We would like to thank the community and the users and remind you that wallabag is a free and open-source software. You can use it freely, host it and also contribute to it.

The work on this project is mostly done on our free time so, if you are able and want to, don't hesitate to donate to wallabag through Liberapay.

Feel free to come chatting with us on matrix or the fediverse :)

Happy reading.