Is game development Front end or Back end?

I am curious what exactly is front end and what is back end... What would be the back end of Unity? Developing the Engine itself or developing the games? And what's the front end? Developing the games or creating a website, promoting the games?

 

Those terms come from web and mobile app development but in game development a very simple backend could be a global highscore server application your game uses to store highscores from all the players into a database and also for querying and fetching that data which you then display in your game.

 

Yes.

 

The best answer so far

 

Thanks for the clarification

 

As @pekdata said, those are web and mobile terms. By my experience in mobile and gamedev I would say that everything you do in C# or shader script for exemple is backend, UI is the front end (there is also UX that is both), everything else is just gamedev (objects, animations, world building, decorations)

 

Those words are indeed fairly tricky to apply to game development. However even there it's not sharply defined (due to modern interactive websites that have a lot of javascript running in the browser as part of the frontend).
What are you trying to do? Match skillsets for some job application?

If you are going from Unity to Web dev: Pretty much all your programming experience in Unity will be backend. Web frontend is significantly different to develop. However you might be able to transfer knowledge about general user-experience and design principles over.

If you go Web dev to Unity: Web backend experience will help you with general programming in Unity. Frontend experience again only on an abstract level about user experience and maybe on the design of menus etc.

 

Yeah, I kind a started looking for a job related to programming and I got asked if I can do back end or front end and I wasn't sure what exactly was the difference and what my skills were closer to.

 

You would get a better answer if you told us your abilities from the start lol

C#, Shader code, Java, Javascript, PHP == Back end
UI, images, animated images, marketing related stuff == front end
UX == UX is just UX
animation, 3D, 3D Texturing and shading == 3D Dev
That Unity components on objects , GameObjects and prefab editing == Game Dev in general

 

Shaders - > backend and marketing -> frontend ??

Sorry but this is nonsense

 

OP, Back/Front end separation strictly belongs to the web. The idea is that there's server-side stuff, and user-facing stuff, which may even be using different tech stacks.

But.

Traditionally games used to be both and neither, because a game was a standalone program running on user's hardware. Which means it is not backend, it is not front end, but it is desktop/standalone programming. No, "front" or "back", because both parts are here, on the same computer, and cannot be separated from each other.

Now, if you start deploying some sort of networked title with user profiles, you'll hit web dev, and you'll hit front/back thing as a part of it. But, that's not inherently part of the game programming.

The reality is that in many cases games are not web. Hence no separation for front and back. Now, you can specialize in some part of the engine, for example, VFX programming, AI programming, GUI, graphics programming, networking, et c.... but that is not frontend/backend.

That's why the answer to your "Is game development Front end or Back end?" question is "Yes".

 

Some games ship with a server application that can be run on the user's computer. The standalone Neverwinter Nights games were an example of this. In my opinion this is a back-end even though it's run on the front-facing hardware.

 

I would not call this a back end.

In those sorts of scenarios, dedicated server is the main application with graphical render disabled or compiled out.

ID software games could act as single player game, act like a server, connect to a server, and at the same time a standalone server could be available. Which is quite different from the web, where a frontend cannot function offline at all.

To be a backend, the application should be required by the main game and the game should not be able to run without it. This sort of scenario applies to mmos. Some of the examples that come to mind are Mu Online and Lineage 2. Those require a server and cannot function without it.

 

lol, I did an aproximation, as I told before back and front are not used for gamedev.
And yes, trying to fit gamedev in front or back terms, shader writing can fall in back end category because it's surely not front end

 

It's fullstack

 

Game dev is game dev :u

 

Front end = client side, the stuff a user sees and directly interacts with. Eg: input handling, rendering (including shaders ).

Back end = server side, remote services which support or provide functionality which (typically) can't be implemented on an end user's machine. Eg: multiplayer servers, account management, cloud saves.

Game development commonly does have both, because many games these days are implemented using web services. MMOs are a classic example of this, as are many freemium mobile games. So all of that web dev stuff applies to them perfectly well, it's just using a game engine instead of a web browser for the front end. Typically, if you do it in Unity then it's "front end". If you do it in PlayFab or GameSparks or Firebase, or write your own service which runs on a server, etc. then it's "back end".

In many cases a tool isn't specific to front- or back-end stuff. For instance, C# can be used on both. So it's not about what tools you use, it's about what you're using them for. Are you writing the service (back end), or the client which uses the service (front end), or both ("full stack") or neither?

 

I quite disagree with all the responses right here, but let me explain why. The question is legit and the answers are correct. In Game Development can be harder to define what is backend and what is frontend.

But don't be tricked by these shenanigans words.

Conceptually is a correct deduction separate game logic from the engine specifications ( Meaning that this distinction tries to give ) From my experience, almost any game, are mostly 90% engine specific && 10% game specific.

Almost every aspects in game are Engine specific.
- Networking, Services, Shaders, Interactions, Inputs, UI, VFX, Editor... Monobehaviours generally.

Game Logic instead:
- Game Business Logic
- Databases ( Local or remote make no differences )
- Services ( Local or remote make no differences )

This separation is pure Utopia, but is a good target to aim.
Engine specific consideration can be done in 10000 different ways.

 

Backend/frontend is based on client server model.

https://en.wikipedia.org/wiki/Client–server_model

Basically, backend being server and front end being your web browser. So stuff that was done in the browser was front end and stuff done in the server was backend.

Sometimes people refer to it as business logic vs presentation. With presentation stuff being front end and systems logic being back end.

If you have a networked game, then the backend would be your servers and the frontend would be the game executing on the persons machine.

 

I love it when people resurrect a year+ year old thread to be confidently wrong.

 

Not at all, the definition is fairly simple :

and

Though frontend/backend are terms that aren't really used (except as a subset of devtools on the server side). The proper terms, as others have noted and Client and Server (fullstack). These are usually handled by different folks, though a very small team/solo may handle both or outsource/use a service for the server component.

Historically, "frontend" referred to folks built the interfaces for software, (later web applications). That was before we used terms like UI developer (and later UX). I started as a frontend developer for industrial software, which meant I designed and programed the user facing controls.

Note: no one would ever call shaders "backend". Shaders are quite literally the most front you can get.

 

Really, this predates the client/server stuff?

 

Here's the oldest example of the term that I was able to find after a few minutes of searching. This is a "small-sized" computer that had the purpose of handling communications between the mainframe and the peripheral devices.

https://en.wikipedia.org/wiki/Front-end_processor
https://en.wikipedia.org/wiki/IBM_3705_Communications_Controller

 

If development in general was a circus - you know one with lions, a bearded lady, a snake charmer, acrobats, and a sword swallower - your average game developer would be a bearded sword swallowing acrobat manticore.

So yep, in gamedev we do both front and back end, if you understand these terms as client/server. Most games interact with a server in some way, be it to store user data, multiplayer purposes, or having some sort of asset streaming mechanism.

 

I was misunderstood. I never claimed that front end and back are absurd concepts to understand.

I was talking about a different way to subdivide things. I never claim to be right, no vision is really the right vision. Subdivisions are conventions made by people, so subjective.

Never said otherwise.

Everyone talks about frontend and backend in terms of networking, like different machines (Server and client).

In a different way to see things, which you can avoid to follow, a client can be your software and not specifically the entire machine. What is not a client can be analogous to a local DB or another software that handle your game logic ( Like a card game engine or a chess engine), that is not involved directly with your software application, but si logically separated from that.

I was talking about another thing. I was not claim to overwrite what client side or server side meant by the last decade.

I hope you understand what i meant.

 

I was talking about this specifically.

 

Is this sarcasm? Shaders define what the user sees. It's like CSS for Meshes.

 

Why? Those things all already have names. Logic, display, interface, model, view, controller, etc. Its a technical field. While terms evolve over time, re-defining things that have existing, clear terms that everyone knows is just going to be a headache for you. It is better to learn/understand correct terminology.

 

Sort of? Before it it was called client it was terminals, but basically the same concept. When I was in art school, I worked part time as an industrial engineer. Because i could draw, clearly I was the best person to build the front ends, because that makes sense, I guess. I spent a couple of years building menus for anything piece of hardware that had a display. Building complex interfaces using ascii was oddly satisfying.