How to start game development when you already write software

TL;DR#

What Epic publishes about Fortnite, and what it does not#

Epic does not publish, anywhere in its reachable published documentation as of 13 September 2026, a statement of what Fortnite itself is written in. That is the honest answer to the question that brings most people here.

What Epic does document is Fortnite as the host for Unreal Editor for Fortnite, and for Verse. Epic describes Verse as "a statically-checked programming language with an emphasis on gameplay programming" (Epic Games, Verse documentation (opens in new tab), accessed 13 September 2026). That documentation sits under the Fortnite tree, with the application type recorded as uefn. Therefore the published, checkable fact is about the language you would write Fortnite islands in, not about the game's own internals.

That gap is worth sitting with for a second. A vendor publishing nothing is not the same as a vendor publishing a denial. Still, an unsourced claim repeated widely does not become a source.

How to start game development: a transfer ledger, not an engine ranking#

For someone who can already program, the first question changes shape. It is not "which engine is best". Instead it is "which of my existing habits survive a frame deadline, and which ones actively mislead me". In short, how to start game development is a question about habits, not about tooling.

That makes the useful format a ledger with two sides. On the credit side sits everything you already do that transfers unchanged. On the debit side sit three specific things that do not, each of which costs real time to learn. Engine choice does get answered later. However, it arrives smaller than you expect, and it arrives after the parts that actually decide whether you finish. Specifically, the ledger below separates what you keep from what you have to relearn.

One thing to set down plainly before the ledger opens. Atyantik builds backend systems and APIs. Nothing on this page is a claim about shipped game work.

The credit side: what transfers unchanged#

Most of your working practice moves across without modification. Version control is the same tool doing the same job, with larger binary assets to think about. Data modelling is the same discipline, applied to items, entities and levels instead of rows. Serialisation is the same problem wearing a different name, because a save file is a serialised object graph with a version number. For example, a level file and a configuration file have the same shape underneath.

State machines transfer almost too well. A character with idle, walk, jump and fall states is the same construct as an order with pending, paid and shipped. Furthermore, user interface state in a game is a state machine you have already written several times. Profiling transfers as a skill, though the unit of measurement changes, which the next section covers.

Client-server work transfers directly. A multiplayer game is an authoritative server, untrusted clients and a reconciliation strategy. Because you have already reasoned about trust boundaries and message ordering, you are not starting cold there. Also, asset pipelines behave much like the build pipelines you already maintain. Finally, the plain discipline of finishing a thing transfers, and it is worth more here than any of the technical items.

The debit side, part one: the execution model jumps#

A typical request-response service answers each request and keeps nothing of its own between them. A game is one long-lived loop holding mutable world state, and it must produce a frame on a schedule. That structural difference is the actual conceptual difficulty, and it is not an API you can look up.

Be precise about the scope of that contrast. Sessions, caches, websocket connections and long-lived workers are ordinary backend shapes that do hold state. The claim is not that backends are stateless. It is that the typical request-response habit, where each request is self-contained and the process forgets, is the one most likely to mislead you. A cached response is state, and so is an open socket. The habit to unlearn is forgetting, not holding.

In practice the mismatch shows up in small decisions. Allocating inside a handler is normal. Yet allocating inside a frame is a choice you have to defend. Since the loop runs continuously, anything you create sixty times a second accumulates somewhere. Choosing a tool by its execution model rather than by its popularity is the same move made in another domain in PHP versus JavaScript, compared by how each one actually runs.

The debit side, part two: latency stops being a log line#

At 60 frames per second, the entire budget for one frame is about 16.7 ms. That is one second divided by sixty, and it is the whole thing: input, simulation, physics, rendering and everything else. Miss it and the player sees the miss directly.

That budget is arithmetic on the frame rate. Modelled, not measured. The sub-costs it has to cover, input, simulation, physics and rendering, carry no published split, so none is drawn here.

Compare that to how latency usually behaves in typical request-response systems. A slow request waits. Then it lands in a percentile, and somebody reads about it later on a dashboard. Meanwhile nobody watching the screen knows it happened. A frame budget works the other way round. Consequently a garbage-collection pause of a few milliseconds, invisible in a service, is a stutter somebody feels in their hands.

That single number changes what performance work means. It stops being a metric you improve and becomes a correctness condition you either meet or fail. Therefore profiling moves from an occasional exercise to a daily one. Also, a dropped frame has no percentile to hide inside. Ultimately this is the shift that is easiest to underestimate.

The debit side, part three: the missing pass condition#

Design work has no acceptance criterion. A build can compile, pass every test and deploy cleanly while telling you nothing about whether the thing is any fun. That is a structural gap, not a skill you lack.

Consider how software people normally decide a task is done. There is a specification, a test, a review, or a stakeholder who signs off. Each of those is an external oracle. Because the oracle exists, "done" is a decidable question. Fun is not decidable that way. No test asserts it, no type system encodes it, and no amount of correctness implies it.

The judgement has to come from somewhere outside your toolchain. Playtesting is that somewhere, and it is not optional garnish. The gap widens as the project grows, because more systems means more places for fun to leak out. In practice the cheapest correction is showing the thing to somebody within the first week. In short, you will need people who are not you to play the thing, early, and you will need to believe them when they are bored.

Pick a language by what the vendor documents#

Unity, Unreal and Godot each publish which languages they support and where that support stops. That published scope is a better basis for a choice than any outside ranking. Each of the following comes from the vendor's own documentation, read on 13 September 2026.

Unity's manual describes extending a project's capabilities with C# code (Unity, documentation manual read as version 6.6, accessed 13 September 2026). Epic publishes a C++ Quick Start covering how to set up a C++ project and program a first gameplay class (Epic Games, page titled Unreal Engine 5.8 Documentation, accessed 13 September 2026). Godot states that "the officially supported languages for Godot are GDScript, C#, and C++" (Godot, official documentation FAQ (opens in new tab), accessed 13 September 2026).

Godot also publishes its own recommendation, and it is Godot's position rather than ours: "GDScript is the recommended language to learn and use since it is native to Godot" (Godot, accessed 13 September 2026). Second, read the published platform limits before the published feature list. Picking a language per layer against real constraints is the same decision shape worked through in a survey of the languages used across artificial intelligence work.

The worked example that dissolves the licence argument#

Run one hypothetical outcome through each vendor's published terms and the licence question mostly stops mattering. Take a solo beginner shipping one small 2D game that earns $8,000 lifetime gross. That figure is chosen to make the arithmetic checkable, and it is not a claim about what a first game earns or should earn.

Still, the arithmetic is worth doing once, so it stops occupying decision budget. Because each trigger differs, copying somebody else's conclusion does not work. Each vendor's cost is triggered by a different thing, so the four cells are not one test. Godot costs $0, because it is published under the OSI-approved MIT licence with no tier, no threshold and no royalty, so nothing triggers at any revenue (Godot, accessed 13 September 2026). Unreal costs $0, because Epic publishes that "no royalties are due on the first $1 million in lifetime gross product revenue", a per-product threshold the example sits far under (Epic Games, Unreal Engine licensing page (opens in new tab), accessed 13 September 2026).

Unity costs $0 only if your own position clears Unity Personal (opens in new tab) eligibility. Unity publishes that as less than $200K USD of revenue and funds raised in the last 12 months (Unity, Unity Personal page, accessed 13 September 2026). That test is on the developer's revenue and funding, not on one game's lifetime gross, so the $8,000 figure does not settle it. GameMaker costs $99.99, the published one-time Professional licence, triggered by commercial release rather than by any revenue level (GameMaker, accessed 13 September 2026).

The conclusion is narrow and worth stating exactly. These terms do not bind at this scale. That is not a statement that any one of them is cheaper, better or preferable. This is general information, not legal advice; check each vendor's current terms and consult a licensed attorney before you rely on them.

What the industry-survey numbers actually measure#

The widely quoted engine survey counts what working professionals name as their primary engine. It does not count what an individual's first project needs. The 2026 State of the Game Industry (opens in new tab), published by the Game Developers Conference (Informa), reports responses from more than 2,300 game industry professionals. In its single-denominator top line, 42% name Unreal as primary engine and 30% name Unity.

Because a figure can be accurate while the verb drifts, the safe statement is the one about naming, not about usage or quality.

The organiser's own text qualifies its headline too. It records that Unreal's lead is carried by larger studios, while a majority at older indie studios still name Unity. The sub-population figures each carry their own denominator, so they do not stack into one picture, and a market share is not advice. A hobby project answers to nobody's staffing plan. Keep hobby motivation and job motivation separate, and the survey stops arguing with you.

Shape a first project that can actually finish#

The smallest project with a fixed external deadline and a real audience supplies the pass condition a test suite cannot. That is our reasoning from the missing acceptance criterion, and it is why a game jam entry beats an open-ended personal project as a first target. Specifically, a jam hands you a deadline you did not set and strangers who will judge the result.

For scale, the GMTK Game Jam 2025 recorded 9,515 entries submitted and roughly 197,000 ratings cast (itch.io, the jam's own host page, accessed 13 September 2026). That is a submission count, and it supports no completion ratio, because the number of people who joined was not captured. The ratings figure is peer judgement at volume, not a quality measure. Still, both establish that external judgement at scale exists and is reachable.

Also, concrete first shapes work better than ambitious ones. A single-screen arcade loop or a one-room puzzle with three rules. An endless runner with one obstacle type or a turn-based board on a grid. Each is small enough to finish inside a fixed window.

How long does making a game take? No general duration is supportable, and anyone giving you one is guessing. Instead, fix the window first and cut scope until it fits. Because the deadline is external, scope becomes the only variable you control. Then ship whatever exists when the clock runs out. Once you start building loot tables, procedural levels or spawn variance, you will lean on a random number generator, and how randomness actually works in computers covers the mechanism most people get wrong by default.

The honest exit: who should skip this#

This is the wrong path for several people, and naming them is more useful than encouragement. If you want to make a thing rather than learn an engine, modding an existing game or using a finished toolkit gets you there faster. You give up control over the underlying systems. In exchange you skip the entire learning curve this page has been describing.

If your goal is a job in games, that is a different route and this page does not cover it. Indeed, hiring, portfolios and studio pipelines are their own subject, and nothing here should be read as guidance on them. Therefore treat that goal as out of scope rather than as served badly.

If the only pull is that games look enjoyable to build, weigh the two costs before starting. The frame deadline makes performance a correctness problem. The missing pass condition means you will not know if you succeeded without other people. Both are real, and concluding that a different project fits you better is a perfectly good outcome. Ultimately the honest question is which of those goals you actually hold.

When a hobby project becomes a backend problem#

A project that acquires accounts, saved progress, shared scoreboards or anything synchronised between players has quietly stopped being only a game problem. At that boundary you are doing ordinary software work again. Specifically, you now own identity, persistence, an authoritative source of truth and an interface between clients and it.

That crossing point is worth recognising early, because it changes what skills the project needs. The simulation loop keeps its own rules. Meanwhile the data behind it follows the same constraints any service does: schema changes, migrations, authentication, rate limits and uptime. In practice this usually arrives when two devices need to agree on one number. Knowing how to start game development also means knowing when part of the project stops being game work.

Atyantik builds systems of exactly that generic shape: accounts, synchronisation between clients, APIs and shared state. No game or game-engine work sits behind that, and none is claimed here. If the connective tissue between clients and services is what you now need, our API integration work covers that shape. Alternatively, if the project needs people rather than a project, hiring backend developers is the other route.