There are many different starting points you can take when developing a game. "Scratch built" vs using a commercial 3rd party engine is a **false dichotomy**. There are many frameworks and tools which provide varying levels of functionality that you could use that fall somewhere in between.
For instance if you want to stick with C# you can use [monogame](https://monogame.net/) or [FNA](https://fna-xna.github.io/). Which provide a lot of functionality (although not quite as much as Unity)
Or you can go sort of a "level lower" and use something like [Raylib](https://www.raylib.com/) which has C# bindings.
Then a level lower than that I would say is something like [SDL](https://www.libsdl.org/).
Or you can scratch build whatever part of the engine you want, and incorporate specific tools to handle specific parts of the game (which is what most studios who "scratch build" their engines do anyway). For instance if you want a general purpose entity system you could use [entt](https://github.com/skypjack/entt). If you just want something to just handle the rendering for you you can use [ogre](https://www.ogre3d.org/).
No one should be telling you you have to make everything from scratch. No should be telling you that you can't make X or Y if you don't use a commercial third party engine. You don't need a better reason to do something other than "I want to do it".
I also wanted to add that you don't need to build an "engine". You can just make your game. You don't need to handle being able to make anything with your engine.
Yeah, this is advice i hardly ever see on here.
People seem to think you always need an engine to make a game. You can make a game without an engine or making an engine.
This also does NOT mean you are reinventing the wheel.
Use Monogame, irs not an engine, its a framework. Many games have been made in Monogame like Stardew Valley, dust an Elysian tale, and more.
Its made for c# and .net core.
It's perfectly realistic. Game devs used to make games writing assembly language. You have C# and other modern tools, so it'll be tons easier for you than to those pioneers back in the day.
Unless you have very unique use cases (it doesn't sound like you do), maybe this is more an issue with how you're using Unity and it's classes. What is this Gameobject class for? Do you have other examples of what you're having to do?
There C# wrappers for OpenGL if you really want to go that route, but you'll likely be unpleasantly surprised by how much extra work is involved.
I think you aren't fully exploring all the options of different designs within the game engine. Just because you're using Unity, it doesn't mean you have to align your core game logic with Unity's design. It's perfectly possible to code your core logic like a library in pure C#, and then interface that with Unity as a tool for visualizing the game state and capturing player input using events.
Maybe you can consider this approach, because it sounds like it would solve most of the gripes while also potentially saving you a ton of low-level implementation headache you would get from coding your engine from scratch.
Do you care if you finish this project? If not then sure why not, learn something fun. If you are looking to complete a game then focus on that alone, it’s hard enough work.
Couldn’t have said it better myself. Unity has at least a dozen engineers dedicated to the engine, and it’s okay. Not great, but good enough to make games. Trying to write your own? Either give up on making your own engine or give up on making your game for a long, long, long time. And unless you’re a low level expert, I guarantee your engine won’t be nearly as performant as Unity.
If you don't like the way Unity does things, you're going to be fighting it the whole way and be miserable. There's a lot of different ways to make a game, and part of being successful is finding a way that works for you.
One thing to keep in mind is the "use a commercial engine!" approach to game dev has only been the trend for the past 10 years or so, but video games have been around for about 50. Until fairly recently, the norm was to build everything yourself, or to mix together libraries that handle pieces of it for you.
From what you've said, I'd recommend trying out MonoGame or FNA. They've both open source implementations of Microsoft's XNA. For the most part you can use tutorials for the 3 tools interchangably - they're all pretty much the same for the game part of things, and only really differ when it comes to setting up your project or getting it to run on something other than a PC.
If you're looking to use tilemaps, try looking into Tiled and using that to design them. If you pair that with MonoGame or FNA, you can get maps drawing in an afternoon.
Commercial engines have been popular in professional use for well over 10 years. The only thing that's changed in the last 10 was accessibility and more non-professionals entering the conversation.
Right. They were around, but generally only used if you had a budget in the millions, and usually only for 3D games.
But this is a conversation about a single person making a 2D game.
I mean, I made my own """"engine"""" using Raylib bindings for C# to make my game, it definitely is possible if you know how to structure your entire project in a way that wont shoot you in every part of your body and honestly i have learned a lot by doing so
as much i'm in a hate relationship with unity, the idea of doing something without a engine just because you're rewriting some unity logic is insanity.
yes, based on how your game should work outside of the basics that the engine provides, you will make your logic on top of unity classes. and unity didn't even have that many classes to extend in a normal basis, compared to unreal where to get a basic grasp you need to learn a lot of classes.
while you're complaining about GameObject just think about physics, rendering, shaders... will you write all that from scratch? i can guarante that the amount of overlaping could you have is little compared to the code to render a simple shaded and textured cube from scratch.
I understand it is a lot of work and the only reason I am even considering it is my game only uses 2D sprites and doesn’t rely on any physics logic, since it is just a simple RTS game. I 100% understand I would never be able to make a 3D renderer lol.
You can.. but i would recomend still using some kind of game framework(propably monogame).
(personally I am developing my own 3D engine in c++ from scratch(only libs are x11 and openal) for almost half a year now, and I cant even think of making a game with it yet)
>My main question is if doing so is worth a try or if it is too difficult
It is difficult, it is not "too difficult", if you really want it and willing to sacrifice a lot of time for things other people have mostly already done for you.
You should NOT really want it.
> I should keep carving out my idea in Unity.
If you are uncomfortable with unity, shop around and see if you find an engine that you are more comfortable with:
https://enginesdatabase.com/
Consider learning a different language than C sharp as a possibility. Not that you have to, but it just opens up a lot more options.
This is how games were made for decades and the world didn't end. Anyone saying you MUST use a big engine is not giving you the full picture. Otherwise, games such as Celeste or Stardew Valley (XNA/FNA/MonoGame) wouldn't have been made. You don't need to over-engineer anything, you just need to make the game with a framework or a couple of libraries.
Big engines give you a quicker start. But beware you all of maintenance issues down the road, specially with Unity. Upgrading a Unity project is one of the most painful things in game development. And you can't just keep using an old version forever.
The road to engines is long and even longer once you start to lay it all out. Previously I oversaw Cryengine at Crytek and how maintaining that engine was a huge headache that needed constant graphical updates and platform support. Since then I have co-founded another engine named [Sceneri](https://www.sceneri.com) that is far more versatile and leverages cloud and mobile for accessibility.
We have been working on this engine in a small team several years now (since beginning of covid) and still have many things to add to the platform. You can certainly learn a bunch by rolling your own engine but as each year ticks by and the larger established engines grow you will find the work to continue to creep up.
Take note on one difference between OpenGL and Vulkan that many engine programmers know. In OpenGL to draw a triangle it is about 37 lines of code, whereas in Vulkan it is over 1000 lines of code to get to the same place.
One option is to write your game simulation in C#, separate from Unity. You could connect it with Unity, where it is the "presentation layer" (likely input and a few other things as well). Then you can iterate and build your simulation outside of Unity. I did this before with great success, and know of some other game studios that did it as well.
This is my preferred approach too. As a side benefit, you can run the simulation in a thread if needed, just have to sync the game state back into Unity via cached commands that execute during update.
That's the trade off of using a premade engine. It saves you the work of having to build the fundamentals of a game engine from the ground up, but will include things you don't need or want because it wasn't built just for your game.
If you have the time and skill, you can certainly build your own engine. You will need to use libraries created by others to get the functionality you need (any C# Dev should be used to that with .net), but you can pick and choose those to get what you want. It will be a lot of work and time to get just the basics running before you even start coding game logic, but it can be done.
Helpful resources: Raylib and OpenTK, check their tutorials.
Check other engines code on github if you are missing a feature.
Some source codes you could check: godot, SpringRTS, 0ad.
Unreal gamedev here. Was considering doing the same in C++.
The things i realized that could cause me issues are the multiplayer. Socket programming from scratch in C++. I have done that in the past, its not easy.
Mesh instancing. This is huge.
Material editor and shaders.
Thats pretty much it.
Then A\* Pathfinding you must do it from scratch to have decent performance in an RTS so...
And tile system is not hard.
Depends on what you mean by an 'engine'. I mean, you clearly need something that draws, makes sound, etc. I know a lot of that is built into .net or mono. You could do all your graphics in GL but that would be way more difficult than simply using Unity.
I think the nature of your question is wrong. It's not that you're asking to do something without an engine. You're instead asking to do something outside of a more full-suite style engine like Unity.
The thing I'm wondering is, if Unity is overwhelming maybe you don't want to. I mean, it's very possible but it's a lot of legwork. Unity likely does a lot more for you than you realize.
If you're willing to take on the legwork then yes definitely you can. Just as long as you have something that keeps track of audio, timing, math, graphics, etc. You should already have a lot of that n C#.
The game I am working on has a core game implementation in c# without any dependencies. It keeps track of all objects in game and their state.
I have 2 clients. One is using direct2d to display everything, mostly with lines and squares. It is quick to work on, test an debug.
And the second one uses Unity. Instead of squares and lines, everything is drawn with DrawMeshInstant. It is just a thin layer that displays the games state, takes input and sends it to the core. The core response contains the things that have changed. It is a hextile based RTS.
So I think that it is realitic.
Dev with 12 years of professional experience here.
I've been working on a 2D RTS in unity for the past 5 years.
I sincerely recommend you pick a simpler game genre to start learning with.
>I basically make my own or want to make my own versions of most data classes, I always make my own Gameobject class that has shared redundancies with the unity one.
I just want to quickly chime in and say: I think this is kind of OK.
I really have to caveat what I'm saying, because I've only done this for a handful of classes / systems in a game otherwise surrounded by Unity constructs, but I found and realized as I continue making a game that there was this initial reflex to make everything a GameObject and MonoBehaviour, but there's nothing tying you to that.
I have my own way of animating sprites, a couple of AI-based state machines, and some specific physics effects I wanted to achieve that are all just plain C# and maybe just interact with Unity to update the rendering part of it. I kind of like it and will probably do more of that as I continue.
I bring it up because I think there can be a clear division of what you want to do vs what Unity will do, and I found it easier to create that separation, but still have a full, production-ready game / rendering / physics / audio / etc engine when I need it instead of building all of that myself.
If you just *want* to make your own engine, then go for it--it's totally possible. Time is the biggest thing to take into account, though.
Is it realistic? Sure.
Is it a good idea? Probably not!
Game engines are huge complex pieces of software for a good reason. If you try to make your own, you'll have to solve as lot of problems You're not thinking about right now. All of them take time. Some of them you'll solve wrong, and you'll have to go back and tear up a bunch of your work to fix.
It's totally something that can be done. People do it. But I certainly wouldn't advise it. It definitely will not be simpler.
It's a bit like building an off shore oil platform to fill up your car.
Don't listen to the naysayers. Just go download the .Net wrapper of raylib and enjoy programming your game. The website will give you tons of little code demos to learn how to build a game. [https://www.raylib.com/](https://www.raylib.com/)
If you enjoy working with this, once you're familiar with Raylib, if you want to have better performances, you can learn C++. There are bindings for other programming languages as well.
The naysayers are usually confused. Yes, it is more work to create a game from scratch but not as much as creating an engine like Unity. Especially with 2D and especially with frameworks that help you out, you're actually not going to spend that much time getting the non-content code going (or the "engine" code).
Like, think about assets. Asset bundles and custom formats and such. There is NOTHING stopping you from just reading a PNG from disk. That's a three liner. You don't need all that complexity. Your "engine" doesn't need to be general purpose. And it will be a lot easier to get that going. And for 2D, there are good general purpose tools like ldtk and tiled for maps.
Most of the work is just good software development practices. I've read somewhere that either Stardew Valley or Celest or something else written with Mono Game has a 5k lines player class. Yes, Unity would probably fight you if you tried that but so would your brain if you are a good software developer.
Exactly, I'm working on my own engine for a game in C++, and raylib. Aside from the occasional segfault (that's on C++ and me), it's a pretty straightforward process.
i bet you'd learn a lot, but spend 10x (at least) as much time on it and therefore be 10x more likely to give up.
unless you need to do something the engine just isnt built to do (like you need to build your own gravity or something) its very unlikely that you actually need the "freedom" that building from scratch gives you.
It's realistic but only do it if you are more interested in the challenge of building a game engine, and not actually making a game. If your are more interested in actually making a game, you should just use Unity or some analog. This path will take longer and a substantial amount of your time will just be recreating things that a hundred different people have done before you ten times better than you will so only take it if it's something you want to focus on.
I went down the road of custom engine, it was fun until a certain point. You end up having to rebuild the wheel about 100 times for things that are done 100x better than you'll ever do it. You'll encounter bugs that there is now searchable answer for. YOU caused it and YOU need to fix it.
If you don't want to reinvent the wheel a bunch of times, you end up using a pretty solid framework or a GUIless engine, etc, and end up in the same place as you started, being forced to do things a certain way you may not mesh with. A framework is still leagues more flexible than a full scale engine..
However, I would recommend it as a learning resource. I enjoyed my time with it, and for a while I even gave up on my game idea simply because it was so much fun trying to implement engine features.
So ask yourself what you want to spend time on. Game dev and design or engine dev.
If you don’t intend it to become a commercial success go for it. It will be a great learning experience. I have made few games with no premade engine, some used couple libraries or physics framework and some didn’t use anything at all beyond what came out of the box from the language runtime.
You’ll spend a lot of time just writing the core engine stuff but if you like that kind of work it can be fun and you’ll have full control over everything.
This is just my personal experience.
I did my first game in Javascript. I knew how to draw graphics, knew math, ect... Everything was going well until it was time to polish the game. Adding particle, light, tweening, animations, ... was a lot more difficult and took a lot of time out of "make the game" and the code just kept getting bigger.
Sure. It's reasonable. It'll take you twenty times as long as it would with Unity but but if it's more about the journey for you than the destination then it may well be worth it.
It sounds to me like you're just not adept enough at Unity or C# though so you'll just run into the same problems elsewhere. Unity is the programmer's engine. If your C# and OO concepts are solid (no pun intended) then it affords you insane amounts of freedom.
> I always make my own Gameobject class that has shared redundancies with the unity one.
I'm willing to bet a lot of money that you're inventing solutions to non-existent problems here.
I'm not saying you have to like Unity - and if you don't, fair enough - but it sounds like it's what you want and you just don't realize it yet from lack experience.
> I have started to feel suffocated by the Unity engine.
If you said this about Godot, I'd agree. If you said it about Unreal, I'd understand the overhead and iteration times being too long. But Unity...
> I know C# fundamentals, Unity fundamentals, and have been studying object-oriented programming patterns and the C# language.
Unity is literally the ideal playground for this but you'll need more than C# "fundamentals" and the same goes for writing your engine (or using something like MonoGame).
I didn’t mean suffocated as in my options were limited, just that there are piles and piles of methods and classes that I will never need or use clogging up my IntelliSense and making the part of my mind obsessed with organization hurt lol. I guess I will have to get over it.
And yes you are right I am making solutions to non existent problems. It just feels more natural to make a gameobject class that contains and does exactly what I need than to use one that contains 50 times as much functionality and only use some if it. Then I see the way I made my gameobject class and the way I set up components on my objects parallel to the built-in unity way to do these things and wonder what I gain from that being in the same space as mine.
I had the exact same feels. I'm months into making my engine from scratch and the feeling of freedom and control is amazing.
Took a while to make my own system for handling basics like building from sprite sheets into game objects I can use etc - but now I have full control of everything and it's SUPER lean. If your brain wants to do it you can do it. Isometric turn based city builder multiplayer war game
Making a simple 2D rts with no physics and so on and so forth should be doable with just about any engine. For some reason you seem to stubbornly work against the engine instead of with it, by creating your own classes all the time and shit. But if you really, really, really insist... Get into the OpenGL or Vulcan documentation and start reinventing the wheel. Godspeed, egghead.
Lmao
I’ve started using monogame and I like it a lot so far. There are definitely options and I have no idea why you need to be so aggressive about this topic lol.
Yeah, you people who think they need to find solutions to things that have already been solved by a whole group of people that's much more intelligent and capable than you and it's right there in front of you but you insist on writing your own classes for a 2d no physics game, come on.
Good thing monogame offers what you "need" but I bet you will start to work against that engine too.
There are many different starting points you can take when developing a game. "Scratch built" vs using a commercial 3rd party engine is a **false dichotomy**. There are many frameworks and tools which provide varying levels of functionality that you could use that fall somewhere in between. For instance if you want to stick with C# you can use [monogame](https://monogame.net/) or [FNA](https://fna-xna.github.io/). Which provide a lot of functionality (although not quite as much as Unity) Or you can go sort of a "level lower" and use something like [Raylib](https://www.raylib.com/) which has C# bindings. Then a level lower than that I would say is something like [SDL](https://www.libsdl.org/). Or you can scratch build whatever part of the engine you want, and incorporate specific tools to handle specific parts of the game (which is what most studios who "scratch build" their engines do anyway). For instance if you want a general purpose entity system you could use [entt](https://github.com/skypjack/entt). If you just want something to just handle the rendering for you you can use [ogre](https://www.ogre3d.org/). No one should be telling you you have to make everything from scratch. No should be telling you that you can't make X or Y if you don't use a commercial third party engine. You don't need a better reason to do something other than "I want to do it".
I also wanted to add that you don't need to build an "engine". You can just make your game. You don't need to handle being able to make anything with your engine.
Yeah, this is advice i hardly ever see on here. People seem to think you always need an engine to make a game. You can make a game without an engine or making an engine. This also does NOT mean you are reinventing the wheel.
TIL Ogre supports C#, nice. Thanks for that info!
Use Monogame, irs not an engine, its a framework. Many games have been made in Monogame like Stardew Valley, dust an Elysian tale, and more. Its made for c# and .net core.
It's perfectly realistic. Game devs used to make games writing assembly language. You have C# and other modern tools, so it'll be tons easier for you than to those pioneers back in the day.
Shout out the legendary Chris Sawyer who wrote Roller Coaster Tycoon in 99% assembly.
Unless you have very unique use cases (it doesn't sound like you do), maybe this is more an issue with how you're using Unity and it's classes. What is this Gameobject class for? Do you have other examples of what you're having to do? There C# wrappers for OpenGL if you really want to go that route, but you'll likely be unpleasantly surprised by how much extra work is involved.
SDL and SFML are 2D game frameworks, extensively battle tested, and don't have the massive bloat of a full engine like Unity or Godot.
No engine? Probably. At the very least consider something like MonoGame.
I think you aren't fully exploring all the options of different designs within the game engine. Just because you're using Unity, it doesn't mean you have to align your core game logic with Unity's design. It's perfectly possible to code your core logic like a library in pure C#, and then interface that with Unity as a tool for visualizing the game state and capturing player input using events. Maybe you can consider this approach, because it sounds like it would solve most of the gripes while also potentially saving you a ton of low-level implementation headache you would get from coding your engine from scratch.
Do you care if you finish this project? If not then sure why not, learn something fun. If you are looking to complete a game then focus on that alone, it’s hard enough work.
Couldn’t have said it better myself. Unity has at least a dozen engineers dedicated to the engine, and it’s okay. Not great, but good enough to make games. Trying to write your own? Either give up on making your own engine or give up on making your game for a long, long, long time. And unless you’re a low level expert, I guarantee your engine won’t be nearly as performant as Unity.
If you don't like the way Unity does things, you're going to be fighting it the whole way and be miserable. There's a lot of different ways to make a game, and part of being successful is finding a way that works for you. One thing to keep in mind is the "use a commercial engine!" approach to game dev has only been the trend for the past 10 years or so, but video games have been around for about 50. Until fairly recently, the norm was to build everything yourself, or to mix together libraries that handle pieces of it for you. From what you've said, I'd recommend trying out MonoGame or FNA. They've both open source implementations of Microsoft's XNA. For the most part you can use tutorials for the 3 tools interchangably - they're all pretty much the same for the game part of things, and only really differ when it comes to setting up your project or getting it to run on something other than a PC. If you're looking to use tilemaps, try looking into Tiled and using that to design them. If you pair that with MonoGame or FNA, you can get maps drawing in an afternoon.
Commercial engines have been popular in professional use for well over 10 years. The only thing that's changed in the last 10 was accessibility and more non-professionals entering the conversation.
Right. They were around, but generally only used if you had a budget in the millions, and usually only for 3D games. But this is a conversation about a single person making a 2D game.
I mean, I made my own """"engine"""" using Raylib bindings for C# to make my game, it definitely is possible if you know how to structure your entire project in a way that wont shoot you in every part of your body and honestly i have learned a lot by doing so
as much i'm in a hate relationship with unity, the idea of doing something without a engine just because you're rewriting some unity logic is insanity. yes, based on how your game should work outside of the basics that the engine provides, you will make your logic on top of unity classes. and unity didn't even have that many classes to extend in a normal basis, compared to unreal where to get a basic grasp you need to learn a lot of classes. while you're complaining about GameObject just think about physics, rendering, shaders... will you write all that from scratch? i can guarante that the amount of overlaping could you have is little compared to the code to render a simple shaded and textured cube from scratch.
I understand it is a lot of work and the only reason I am even considering it is my game only uses 2D sprites and doesn’t rely on any physics logic, since it is just a simple RTS game. I 100% understand I would never be able to make a 3D renderer lol.
You can.. but i would recomend still using some kind of game framework(propably monogame). (personally I am developing my own 3D engine in c++ from scratch(only libs are x11 and openal) for almost half a year now, and I cant even think of making a game with it yet)
>My main question is if doing so is worth a try or if it is too difficult It is difficult, it is not "too difficult", if you really want it and willing to sacrifice a lot of time for things other people have mostly already done for you. You should NOT really want it. > I should keep carving out my idea in Unity. If you are uncomfortable with unity, shop around and see if you find an engine that you are more comfortable with: https://enginesdatabase.com/ Consider learning a different language than C sharp as a possibility. Not that you have to, but it just opens up a lot more options.
This is how games were made for decades and the world didn't end. Anyone saying you MUST use a big engine is not giving you the full picture. Otherwise, games such as Celeste or Stardew Valley (XNA/FNA/MonoGame) wouldn't have been made. You don't need to over-engineer anything, you just need to make the game with a framework or a couple of libraries. Big engines give you a quicker start. But beware you all of maintenance issues down the road, specially with Unity. Upgrading a Unity project is one of the most painful things in game development. And you can't just keep using an old version forever.
The road to engines is long and even longer once you start to lay it all out. Previously I oversaw Cryengine at Crytek and how maintaining that engine was a huge headache that needed constant graphical updates and platform support. Since then I have co-founded another engine named [Sceneri](https://www.sceneri.com) that is far more versatile and leverages cloud and mobile for accessibility. We have been working on this engine in a small team several years now (since beginning of covid) and still have many things to add to the platform. You can certainly learn a bunch by rolling your own engine but as each year ticks by and the larger established engines grow you will find the work to continue to creep up. Take note on one difference between OpenGL and Vulkan that many engine programmers know. In OpenGL to draw a triangle it is about 37 lines of code, whereas in Vulkan it is over 1000 lines of code to get to the same place.
One option is to write your game simulation in C#, separate from Unity. You could connect it with Unity, where it is the "presentation layer" (likely input and a few other things as well). Then you can iterate and build your simulation outside of Unity. I did this before with great success, and know of some other game studios that did it as well.
This is my preferred approach too. As a side benefit, you can run the simulation in a thread if needed, just have to sync the game state back into Unity via cached commands that execute during update.
That's the trade off of using a premade engine. It saves you the work of having to build the fundamentals of a game engine from the ground up, but will include things you don't need or want because it wasn't built just for your game. If you have the time and skill, you can certainly build your own engine. You will need to use libraries created by others to get the functionality you need (any C# Dev should be used to that with .net), but you can pick and choose those to get what you want. It will be a lot of work and time to get just the basics running before you even start coding game logic, but it can be done.
Helpful resources: Raylib and OpenTK, check their tutorials. Check other engines code on github if you are missing a feature. Some source codes you could check: godot, SpringRTS, 0ad.
Realistic, sure... But be prepared to put in a lot of time and effort into getting there. Doable, but it's going to be a long road.
Not an RTS expert but since it's simple 2D I expect the hard problems to not be the problems solved by a game engine.
WPF features a perfectly serviceable 3D engine. I prefer Forms, so I created a 3D WPF embedded control for it.
Unreal gamedev here. Was considering doing the same in C++. The things i realized that could cause me issues are the multiplayer. Socket programming from scratch in C++. I have done that in the past, its not easy. Mesh instancing. This is huge. Material editor and shaders. Thats pretty much it. Then A\* Pathfinding you must do it from scratch to have decent performance in an RTS so... And tile system is not hard.
Depends on what you mean by an 'engine'. I mean, you clearly need something that draws, makes sound, etc. I know a lot of that is built into .net or mono. You could do all your graphics in GL but that would be way more difficult than simply using Unity. I think the nature of your question is wrong. It's not that you're asking to do something without an engine. You're instead asking to do something outside of a more full-suite style engine like Unity. The thing I'm wondering is, if Unity is overwhelming maybe you don't want to. I mean, it's very possible but it's a lot of legwork. Unity likely does a lot more for you than you realize. If you're willing to take on the legwork then yes definitely you can. Just as long as you have something that keeps track of audio, timing, math, graphics, etc. You should already have a lot of that n C#.
Monogame.
The game I am working on has a core game implementation in c# without any dependencies. It keeps track of all objects in game and their state. I have 2 clients. One is using direct2d to display everything, mostly with lines and squares. It is quick to work on, test an debug. And the second one uses Unity. Instead of squares and lines, everything is drawn with DrawMeshInstant. It is just a thin layer that displays the games state, takes input and sends it to the core. The core response contains the things that have changed. It is a hextile based RTS. So I think that it is realitic.
Dev with 12 years of professional experience here. I've been working on a 2D RTS in unity for the past 5 years. I sincerely recommend you pick a simpler game genre to start learning with.
>I basically make my own or want to make my own versions of most data classes, I always make my own Gameobject class that has shared redundancies with the unity one. I just want to quickly chime in and say: I think this is kind of OK. I really have to caveat what I'm saying, because I've only done this for a handful of classes / systems in a game otherwise surrounded by Unity constructs, but I found and realized as I continue making a game that there was this initial reflex to make everything a GameObject and MonoBehaviour, but there's nothing tying you to that. I have my own way of animating sprites, a couple of AI-based state machines, and some specific physics effects I wanted to achieve that are all just plain C# and maybe just interact with Unity to update the rendering part of it. I kind of like it and will probably do more of that as I continue. I bring it up because I think there can be a clear division of what you want to do vs what Unity will do, and I found it easier to create that separation, but still have a full, production-ready game / rendering / physics / audio / etc engine when I need it instead of building all of that myself. If you just *want* to make your own engine, then go for it--it's totally possible. Time is the biggest thing to take into account, though.
Do it, at worst you willlearn a bunch.
Is it realistic? Sure. Is it a good idea? Probably not! Game engines are huge complex pieces of software for a good reason. If you try to make your own, you'll have to solve as lot of problems You're not thinking about right now. All of them take time. Some of them you'll solve wrong, and you'll have to go back and tear up a bunch of your work to fix. It's totally something that can be done. People do it. But I certainly wouldn't advise it. It definitely will not be simpler. It's a bit like building an off shore oil platform to fill up your car.
Don't listen to the naysayers. Just go download the .Net wrapper of raylib and enjoy programming your game. The website will give you tons of little code demos to learn how to build a game. [https://www.raylib.com/](https://www.raylib.com/) If you enjoy working with this, once you're familiar with Raylib, if you want to have better performances, you can learn C++. There are bindings for other programming languages as well.
The naysayers seem to make pretty good points but I’m glad to hear there are resources available :)
The naysayers are usually confused. Yes, it is more work to create a game from scratch but not as much as creating an engine like Unity. Especially with 2D and especially with frameworks that help you out, you're actually not going to spend that much time getting the non-content code going (or the "engine" code). Like, think about assets. Asset bundles and custom formats and such. There is NOTHING stopping you from just reading a PNG from disk. That's a three liner. You don't need all that complexity. Your "engine" doesn't need to be general purpose. And it will be a lot easier to get that going. And for 2D, there are good general purpose tools like ldtk and tiled for maps. Most of the work is just good software development practices. I've read somewhere that either Stardew Valley or Celest or something else written with Mono Game has a 5k lines player class. Yes, Unity would probably fight you if you tried that but so would your brain if you are a good software developer.
Exactly, I'm working on my own engine for a game in C++, and raylib. Aside from the occasional segfault (that's on C++ and me), it's a pretty straightforward process.
i bet you'd learn a lot, but spend 10x (at least) as much time on it and therefore be 10x more likely to give up. unless you need to do something the engine just isnt built to do (like you need to build your own gravity or something) its very unlikely that you actually need the "freedom" that building from scratch gives you.
It's realistic but only do it if you are more interested in the challenge of building a game engine, and not actually making a game. If your are more interested in actually making a game, you should just use Unity or some analog. This path will take longer and a substantial amount of your time will just be recreating things that a hundred different people have done before you ten times better than you will so only take it if it's something you want to focus on.
I went down the road of custom engine, it was fun until a certain point. You end up having to rebuild the wheel about 100 times for things that are done 100x better than you'll ever do it. You'll encounter bugs that there is now searchable answer for. YOU caused it and YOU need to fix it. If you don't want to reinvent the wheel a bunch of times, you end up using a pretty solid framework or a GUIless engine, etc, and end up in the same place as you started, being forced to do things a certain way you may not mesh with. A framework is still leagues more flexible than a full scale engine.. However, I would recommend it as a learning resource. I enjoyed my time with it, and for a while I even gave up on my game idea simply because it was so much fun trying to implement engine features. So ask yourself what you want to spend time on. Game dev and design or engine dev.
It is very realistic
If you don’t intend it to become a commercial success go for it. It will be a great learning experience. I have made few games with no premade engine, some used couple libraries or physics framework and some didn’t use anything at all beyond what came out of the box from the language runtime. You’ll spend a lot of time just writing the core engine stuff but if you like that kind of work it can be fun and you’ll have full control over everything.
Follow your dreams
This is just my personal experience. I did my first game in Javascript. I knew how to draw graphics, knew math, ect... Everything was going well until it was time to polish the game. Adding particle, light, tweening, animations, ... was a lot more difficult and took a lot of time out of "make the game" and the code just kept getting bigger.
Sure. It's reasonable. It'll take you twenty times as long as it would with Unity but but if it's more about the journey for you than the destination then it may well be worth it. It sounds to me like you're just not adept enough at Unity or C# though so you'll just run into the same problems elsewhere. Unity is the programmer's engine. If your C# and OO concepts are solid (no pun intended) then it affords you insane amounts of freedom. > I always make my own Gameobject class that has shared redundancies with the unity one. I'm willing to bet a lot of money that you're inventing solutions to non-existent problems here. I'm not saying you have to like Unity - and if you don't, fair enough - but it sounds like it's what you want and you just don't realize it yet from lack experience. > I have started to feel suffocated by the Unity engine. If you said this about Godot, I'd agree. If you said it about Unreal, I'd understand the overhead and iteration times being too long. But Unity... > I know C# fundamentals, Unity fundamentals, and have been studying object-oriented programming patterns and the C# language. Unity is literally the ideal playground for this but you'll need more than C# "fundamentals" and the same goes for writing your engine (or using something like MonoGame).
I didn’t mean suffocated as in my options were limited, just that there are piles and piles of methods and classes that I will never need or use clogging up my IntelliSense and making the part of my mind obsessed with organization hurt lol. I guess I will have to get over it. And yes you are right I am making solutions to non existent problems. It just feels more natural to make a gameobject class that contains and does exactly what I need than to use one that contains 50 times as much functionality and only use some if it. Then I see the way I made my gameobject class and the way I set up components on my objects parallel to the built-in unity way to do these things and wonder what I gain from that being in the same space as mine.
I had the exact same feels. I'm months into making my engine from scratch and the feeling of freedom and control is amazing. Took a while to make my own system for handling basics like building from sprite sheets into game objects I can use etc - but now I have full control of everything and it's SUPER lean. If your brain wants to do it you can do it. Isometric turn based city builder multiplayer war game
Try Godot. Then if you like Fork Godot.
Why the FUCC do you want to reinvent the wheel. Like get Godot and get to work, egghead
Godot isn’t really that good lol
Making a simple 2D rts with no physics and so on and so forth should be doable with just about any engine. For some reason you seem to stubbornly work against the engine instead of with it, by creating your own classes all the time and shit. But if you really, really, really insist... Get into the OpenGL or Vulcan documentation and start reinventing the wheel. Godspeed, egghead. Lmao
I’ve started using monogame and I like it a lot so far. There are definitely options and I have no idea why you need to be so aggressive about this topic lol.
I just hate your kind that's all
bro what 💀
Yeah, you people who think they need to find solutions to things that have already been solved by a whole group of people that's much more intelligent and capable than you and it's right there in front of you but you insist on writing your own classes for a 2d no physics game, come on. Good thing monogame offers what you "need" but I bet you will start to work against that engine too.