/v/ - Video Games

Seems fair.

Yes but BYOND is a garbage engine that many devs seek to smuggle their games out. If you're going to build one for commercial use make it good.

>>14609582

The argument against it would generally be that a tailor-made engine would not necessarily have functionality for your game that an off-the-shelf engine wouldn't, but then we're just going into the territory of assessing what fits your game on a game-to-game basis - that doesn't really work as the generalised statement that it gets delivered as.

>>14609582

How many games have you finished OP?

>>14609582

a game-specific engine would do everything that the game needs it to do without being bloated by things it doesn't need. Furthermore you can implement best practices at every level of its construction instead of relying on the devs to not half-ass it

the disadvantage is that if you are making a game without a team you will spend months making an engine instead of making a game. That can kill your momentum

>>14609970

Engine does not really have to take months though. Well it depends on what kind of a game is, but for something like a Battle City clone, or a hacking game.

If it is a good engine AND it provide means to make a good game, it is always better to create your own engine.

you have too many examples of current games being shit because they adopted a proprietary engine, or engines made by other people and not the developers.

This really isn't a simple yes or no question. A lot of CURRENT_YEAR game devs are not ever going to need to make their own engine to make their shitty games (or even some of the good ones, for that matter). Coding your own engine is a very time consuming process and is usually just a duplication of effort. It can be useful to do as part of a learning process, especially if you're not looking to profit off the experience, but if you've left your job to pursue gamedev or are otherwise trying to make it your main stream of income, consider using an existing engine, at least for your own sake.

Also existing engines have a lot of pros, like easy access to multiple platforms, and large bases of experienced developers and artists (should you ever need to employ others). This shit is why PHP is still popular even though it's fucking trash: everyone knows it.

Obviously, but that shit's hard and people usually don't create entire engines on their own, they usually at least have a group of people.

>>14610354

>I see too many people make their first project huge and they never finish it, start small and actually get a working game first.

Yeah but that's a separate issue. MMO in an engine is a bigger project than a hacking game + your own engine.

>>14609582

No. Just use Unity™ bro, you can make anything with it.

Nothing wrong with making your own engine if you plan to use it for several games.

People bitch about Gamebryo but you can't deny its commercial success.

By your logic, OP, you should make your own engine once and then once it becomes obsolete you can go ahead and use Unity because you already had the learning experience once.

Making an engine is useful for multiple reasons, including what you learn from it, but mostly for games that require functions not found in other engines. The same way you might want to create your own level editor sometimes, because for instance placing tiles manually for a 2D game in each level in Unity would be retarded.

In the end proper game development boils down to doing what you have to to make doing what is required to finish your game with the least effort, and then expending a little more effort on top of that to make everything feel right. But that is such an immeasurable thing that it's hard to quantify so focus on the first part first.

Why the fuck would you make a thread about a very small subsection of gamedev on a board about playing videogames, though? Either ask it in the /agdg/ general or on >>>/agdg/ itself.

Bear with my autism. When I think of video games, I think of objects on the screen that most players can see and maybe some AI. From what I've seen with modern game engines most of them are just object oriented languages that have most of the computing stuff like rendering video and audio built in. For those getting into making games for the first time this is okay for smaller stuff.

However the problems arise when you get into optimization when you need source code level stuff that you don't have access to. Which at that point you're going to have to accept engine limitations or look into coding your own software library because licensing and scripts is a bitch. Every pre-made script or library you find online has one.

/v/ is lording about how everyone should make their own engine because every free and commercial game engine is about pozzed by social justice warriors.

>>14609582

no, it's a waste of time

>>14611272

The source code of Unreal 4 is available though, and you're allowed to change as much of it as you want for your own game. The problem with that is that it's a gigantic codebase and frankly a mess, which is logical for an engine tha tries to be everything you need.

You own engine being more optimized has little to do with your code being more optimized, and more with your own engine doing only what you need it to do.

Don't listen to the shills. It's much more complicated and will take alot of research for your project and what you want to do with it. It also depends on how machine you want your game to speak if you want it to run on potatoes. Homebrew games more often than not require their own engines to run on old NES cats and DOSbox. I remember looking into modding quests for Phantasy Star Online and that practically uses machine language.

That said when you code an engine you're not exactly programing the visual objects players see in games, but the libraries these objects will use to run. So you might be able to make a 3D model in adobe but you have to recompile that model and texture to use in your game. And then your engine handles colission, hitboxes, etc. If applicable. Even Blender comes with built-in game making tools if you want to learn Python. Though I'm not sure how Python is for complicated AI.

And even then most engines let you import libraries you make from scratch. So if one engine doesn't work with your library you can re work it for another.

Game developement is expensive and time consuming if you lack the talent and knowledge and have to spend lots of money on licensing pre-made stuff. That said go to /adgd/. Good luck.

>>14611311

Well that makes sense. I liked it when Unreal was an engine for shooters that you can add models to the camera and turn it into an action game. Unreal was at it's best when it was about rendering objects on screen while the dev's made their own rules. If we have to rewrite Unreal 4 for it to work then we may as well build a game from nothing.

If you were going to write a book, would you first invent your own language?

Should you build a bike from scratch before learning to ride one?

First learn what you can with the skills and tools you already have available, its a lot easier to follow some tutorials for an already functional engine and make something that works.

Making a game engine is a much more complicated programming endeavor and requires years of knowledge and then years of work on top of that.

If you want to make your own engine go for it, if you want to make a game, make a game.

t. Very shitty amateur dev

PS. If you think making a game engine is more valuable experience than making a game, by the same logic writing your own compiler should be more valuable than making a program, and writing a kernel more valuable than writing a compiler, and so on.

The only upside to creating your own engine (aside from learning more on how they work under the hood) is the total artistic freedom that comes along with it. I forgot where, but I remember hearing that if you create an extremely "problematic" game that Unreal or Unity don't want their brandname associated with, they can revoke your commercial privileges to use their engine for profit.

Not sure if this ^ is true or not, but it might be. If you try to create a mohammad childrape simulator or something, they might get pissy if "Unreal" or "Unity" is credited for its creation.

>>14611345

>Very shitty amateur dev

Maybe you shouldn't speak so authoritatively then…

>>14609658

Just self medicate yourself with loads of caffeine.

>>14611345

You don't invent the language, that would be writing your own compiler. And multiple good writers invented languages for fantasy settings, yeah.

Building a custom bike is normal when you're serious about cycling.

Yes because using a game engine makes you assume things. Things you have no control over that will dictate how you implement your design, or worst case enforce a design paradigm on you.

I can understand not wanting to manually program certain aspects (like rasterizers), but you should at least have a passing knowledge of what that part of the code is actually doing. Most "game engine" users will never know.

Also writing your own code can make it easier to spot and thus fix errors. This will allow you to shed the notion that software has "bugs", and instead put the onus of a programming error squarely where it belongs: on the programmer.

>>14611345

>If you were going to write a book, would you first invent your own language?

False dichotomy. A hierarchy is not the same as the language. I don't have to invent English, x86, or C/C++ to write a game in C/C++.

/agdg/ here.

It comes down to results.

For 2D, for example, there's so many engines and frameworks out there, that, sure, you could make your own, but it won't really give you any advantages over someone using a framework, and will probably lose time.

With 3D, however, the engines and frameworks that exist are shit. The three main ones, Godot, Unreal and Unity all have major flaws in them that are a pain in the ass to fix, and with all the other strings attached to each engine, it's just a pain all around. In a lot of cases, the engines themselves stand in the way of progress, so aside from being a great learning experience, your own engine will end up being substantially better optimized for your specific project.

And don't fall for the Godot shilling, it's barebones and lacking in essential features, and the only reason people use it is because Unreal makes you give money to Tencent and Unity is a bloated mess. That, and muh FOSS.

>>14612018

>lacking in essential features

such as?

'yes' because it provides the most valuable learning experience into making a game by requiring the most active involvement in its lessons.

>>14611345

The book analogy makes no sense. People that write books have to follow a set of rules and requirements within the book genre they're doing. In this case it'd be going against those principles and making your own.

The reason people would make a game engine is that after all the work they've done on it they'd have a very easy time modifying it, building over it and creating new things nonexistent in already made engines. Otherwise you're working with the same old technical aspects and limitations.

If you're an amateur dev like yourself that doesn't matter much though.

>>14612018

Using a framework counts as enginedev to people who argue you should just use Unity/Unreal/Godot, anon.

As for Godot being "barebones", that's a plus in my opinion. It's still being added to at a relatively fast rate, but it's simple enough that you can add to it yourself a lot easier than with UE4.

Any engine you make should have intent and some form of comparative advantage over pre-existing engines.

Broadly speaking, consumer-ready engines have eclipsed anything a single, moderately capable hobbyist could hope to put together in complexity, even if efficiency suffers for various reasons.

In other words, if you want to make a fancy homebrew RTS and that's it, just go snag FIFE or something, you aren't missing anything. If you have a specific subject or task you're good at and you can demonstrably improve, contribute to FIFE's development.

If you want to make an extraordinarily efficient ant simulator with thousands of active subjects at any time in Common Lisp and you have some novel idea of how to handle 2d rendering, go for broke. Xconq did this way back, delivering a remarkably complex game that worked on basically any toaster you threw at it, even with a visual tileset.

>>14609582

>it provides the most valuable learning experience into making a game

That doesn't add merit to the game itself and is therefore only valuable to you, not the players.

Game based arguments would be features that engines usually lack but that are needed for some game mechanic you would like to implement (an example would be the xmoon game, where you actually shove a penis into a vagina and both are full physics-objects, which would make your average engine shit itself)

Alternatively, you could optimize performance through only including exactly what you need instead of having bloat attached.

That being said, making, debugging, and optimizing your own engine capable of handling >Y2k graphics is a major task even for experienced developers.

Unless you've already made a bunch of games and are very familiar with C/C++ and possibly Assembly, don't do it because it'll kill both your game and motivation.

>>14611272

That's why you use Godot, where you can access and change the source code at your leisure.

>>14612018

>Godot

>major flaws

Since you appear capable of fixing them, why not try that instead of whinging about it? It's Open Source for a reason.

>>14612309

<Since you appear capable of fixing them, why not try that instead of whinging about it? It's Open Source for a reason.

Spoken like a Jew/Chink/Communist fucktard.

<Here's our broken shit that you can use to half-ass a project!

<Oh yeah that part doesn't work, but it's free and you can make it work!

<Yeah if you make it work we're going to merge it to our codebase, probably not give you credit, and definitely not share any profits we receive from license fees.

Why waste time trying to understand your broken brown-people-code when we can write proper white-person-code from scratch, and if we make an error we can fix the error like a white man rather than blame it on unknown "bugs" like a brown person?

Is this your coping strategy, ika?

>>14612329

>Godot

>license fees

That may be the dumbest thing I've heard all day, good job ruining any argument you may think you had.

>>14611314

>Phantasy Star Online and that practically uses machine language

Everything uses machine language and assembly, you probably meant "written in assembly"

>>14612989

Yeah that. It's been a while. Sorry.

>>14611381

I need actual medicine

My 3rd engine was just glue between DirectX, OpenAL, Assimp, Bullet Physics and CEGUI - it was still a pain in the ass.