Game engine or programming luanguage?

When i tried to look this up on google some people said that if you know a programming luanguage you can make a better game because you are not limited by what Unity offers but games like:endless legend,cities skylines,rust are made in unity and seem like very good games.Can someone explain me how this works?Do they combine in some ways?

All general purpose engines use one or in some cases multiple programming languages, Those engines take care of the low level stuff (rendering, resource management, physics, sound, interactions with the underlying OS, etc) and provides various tools (level/scene editors, animation editors) + some functionality that lots of games will need (basic pathfinding, a few basic shaders, etc), You can't even make a pong clone in Unity without using a programming language, The editor only lets you create the paddles, walls and the ball and configure their appearance and physics properties and if you set the ball in motion using the editor the engine can make sure it bounces off the walls and paddles.

You still need to write code that moves the paddles(atleast the AI one, you can probably find a controller component that works for the player paddle in the asset store), counts the score and resets the ball after a player scores.

It's not one or the other. If you use unity, you will still need to know a programming language.

¿por que no los dos?

You can think of game engines like Unity as a big bag of tools which are required to put a game together. If you choose not to use a game engine, then first you have to program your own tools! Using an existing game engine just lets you skip that step and start making games using someone else's tool bag.

With infinite time and skill, technically you can make a "better" game coding your game from the ground up. Well, better might not be the correct term. You could implement features not present by default in the Unity engine. If your cool game idea requires you to write a new rendering pipeline from the ground up, you wouldn't need to ask the question. I challenge you to come up with the feature that your game needs that can't be done in Unity. :)

If your goal is to make games, you're probably better off using an existing engine (like Unity) to build your game. If your goal is to learn the ins and outs of game engines, start working on your own engine. If you have no programming knowledge whatsoever, you'll have to back up a step and start learning how to program.

If you're not sure what the difference is between coding a game from scratch, or using an engine, mess around with Unity one weekend. Work through the roll-a-ball tutorial https://unity3d.com/learn/tutorials/projects/roll-a-ball and see for yourself. It's a lot more like "real coding" than lots of other engines.

- Eck

I challenge you to come up with the feature that your game needs that can't be done in Unity.

i recently checked out the unity docs and capabilities.

some features which seem to be lacking:

1. support for procedurally generated scenes and characters.

2. support for large level areas bigger than can be represented easily by floats.

3. support for streaming large levels from disk.

4. support for procedurally generating large levels from underlying world map data.

it still seems to be focused on the "doom / level based" design paradigm, and loading what is essentially still hard coded data from disk in a data driven manner. which doesn't necessarily work so well with large continuous worlds or randomly / procedurally generated worlds. right now the game world size of the three titles i'm working on are 2500 miles across, 20,000 Km across, and 20,000 trillion Km across, and these are all continuous worlds you can travel across with no load screens. Two of the worlds are randomly generated. So using Unity might require a fair amount of home rolled code in such cases.

Follow a few Unity game design tutorials, and you will see that while in Unity you can place objects, you need to program those objects for them to be able to do something or interact with each other.

I challenge you to come up with the feature that your game needs that can't be done in Unity.

i recently checked out the unity docs and capabilities.

some features which seem to be lacking:

1. support for procedurally generated scenes and characters.

2. support for large level areas bigger than can be represented easily by floats.

3. support for streaming large levels from disk.

4. support for procedurally generating large levels from underlying world map data.

it still seems to be focused on the "doom / level based" design paradigm, and loading what is essentially still hard coded data from disk in a data driven manner. which doesn't necessarily work so well with large continuous worlds or randomly / procedurally generated worlds. right now the game world size of the three titles i'm working on are 2500 miles across, 20,000 Km across, and 20,000 trillion Km across, and these are all continuous worlds you can travel across with no load screens. Two of the worlds are randomly generated. So using Unity might require a fair amount of home rolled code in such cases.

The code wouldn't be all that different from what you'd have to write to support a 20 quadrillion km world normally. You don't build a static scene in Unity any more than you'd try to populate a single mega-level in "from scratch" code. You split your world into manageable chunks and dynamically load what's near your player based on your world generation algorithm. The code is going to be pretty much the same.

And I wasn't challenging the game dev community to come up with something that Unity can't do. I'm challenging FatDoggy to tell us about features that HIS game needs that Unity can't do. :)

- Eck

I challenge you to come up with the feature that your game needs that can't be done in Unity.

i recently checked out the unity docs and capabilities.

some features which seem to be lacking:
1. support for procedurally generated scenes and characters.
2. support for large level areas bigger than can be represented easily by floats.
3. support for streaming large levels from disk.
4. support for procedurally generating large levels from underlying world map data.

All that stuff can be done in unity.

doesn't necessarily work so well with large continuous worlds or randomly / procedurally generated worlds. right now the game world size of the three titles i'm working on are 2500 miles across, 20,000 Km across, and 20,000 trillion Km across, and these are all continuous worlds you can travel across with no load screens. Two of the worlds are randomly generated. So using Unity might require a fair amount of home rolled code in such cases.

I know two devs in my city that are working on a procedural 3D platformer, and a space MMO with a procedural model of the entire milky way galaxy to scale, both in Unity.

Sure it's not a push button thing - it requires some programming, but that'd be true in any engine (and also why even companies that use Unreal/Unity have engine programmers on staff). Even if not using the basic level structure, Unreal/Unity still give you an art pipeline, graphics programming framework, gameplay programming framework, audio/physics/etc out of the box. The art pipeline in particular is something that most homebrew engines neglect.

I know two devs in my city that are working on a procedural 3D platformer, and a space MMO with a procedural model of the entire milky way galaxy to scale, both in Unity.

It's possible, but I'm not sure it's the best starting point for a procedural setup. I've ported my universe generator into Unity before, and the combination of performance hiccups around implementing everything in Mono, and the lack of access to the underlying graphics hardware, make it a little bit tricky.

That said, I do think that building your procedural generation as a DLL which can be plugged into Unity sounds like a great approach.

That said, I do think that building your procedural generation as a DLL which can be plugged into Unity sounds like a great approach.

I think this is something that people either don't know about or just plain ignore when trying to dismiss engines like Unity/UE4. If something isn't supported or you just don't like how it's done in their scripting language there is nothing stopping you from creating a native level plugin to do it.

I recently went from writing from scratch (c++ and directx 11) to using unreal engine 4. I had decided to use only blueprint, as I wanted to learn it and went in with some preconceived notions about what the engine could and couldnt do. I was pleasantly surprised to find that streaming of large worlds, streaming of assets, and lots of other things I thought I might have to code myself just worked out of the box. The moral of the story?

Don't assume what engines can and can't do, rtfm and play with them and you'll be surprised :)

When i tried to look this up on google some people said that if you know a programming luanguage you can make a better game because you are not limited by what Unity offers but games like:endless legend,cities skylines,rust are made in unity and seem like very good games.Can someone explain me how this works?Do they combine in some ways?

First when trying to figure out what to use, ask yourself this: what game are you going to try and make RIGHT NOW. After you have answered that question, the decision between engine and language becomes easier. But to answer your question directly, an engine and language can both be used. It is not one or the other. Most times you will use both. What it comes down to is: time and complexity. And that depends on the scope of your game and the level of your experience.

I hope I vaguely answered all of your questions :)

That said, I do think that building your procedural generation as a DLL which can be plugged into Unity sounds like a great approach.

I think this is something that people either don't know about or just plain ignore when trying to dismiss engines like Unity/UE4. If something isn't supported or you just don't like how it's done in their scripting language there is nothing stopping you from creating a native level plugin to do it.

Its worth mentioning that going this route will make your life harder when targeting other platforms, defeating one of the main features of using "vanila" Unity.