Unity or not?

I'm looking to program a 2D rpg but I'm not sure if I should use unity or something else? I can't use GML because that doesnt work for me. I have basic knowledge of C++ and little experience with SFML graphic library, maybe I should use that?

 

A graphics library and a big full-featured game engine are two very different things.

You didn't provide much information at all. Do you like creating engines and spending a lot of time building low-level systems? Does your game require something inappropriate for a general purpose game engine? Is absolute performance a requirement? Do you need your builds to be extra tiny?

If the answer is "no" to those, I'd say there's a high chance that Unreal, Unity, or Game Maker would good choices. If you're in love with C++, Unreal uses that. Lots of folks enjoy C# in Unity though.

 

If you want to write a game engine, you should use C++ (and maybe libSDL. Never liked SFML). Writing a game engine does not necessarily result in a playable game.

If you want to make a game, you should use existing engine. Unity is a good option, but if your game squarely fits into existing rpg format, you could slaos consider tools like RPGMaker.

If you start with C++ while trying to to make a game you'll simply waste a lot of time and possibly will never finish your project.

 

It all depends on do you like using these modern all-in-one game engines like Gamemaker Studio, Construct 2, Unity, etc or do you much prefer to just program everything using a high level game oriented API?

If the former than sure might as well give Unity a try. If the latter then I'd recommend going with AppGameKit (AGK2). I much prefer just programming everything and not having the scene editor and so forth. I looked for a solution for a long time. Finally found AGK2 about a month ago. It offers two options for the programming side. The first is their high level BASIC programming language and the second is using C++. Both languages have you using their game oriented API which is packed full of high level commands to help rapidly build games.

So really it is all about the environment you want to work with. Do you desire a Scene Editor, Animation System, prefabs, gameobjects and so forth like Unity has? Then go with Unity. Do you just want to use Tiled or some other tile map editor and program the game relying on a high level API? Go with AGK2.

 

Unity is great though I will admit there is something very weird about UE4 that somehow makes me feel comfortable. I tried it first time today and got hooked, documentation and learning isn't anywhere near as good as Unity but its really weird how attracted I am to it regardless. I suppose its because of how quick you can get things done, i created walls and landscapes in no time added lights etc and it was insane how good the graphics started to look off the bat.

Without having to do anything really, the graphics start to shine immediately even with a simple floor and wall.

There is one thing it lags even on my GTX 1060 FTW+ overclock video card 6GB GDDR5X ram and a 3ghz core i5 with 8GB RAM. I suppose there is a reason why it makes games look so good from so early the thing is a resource hog.

when you see the word "Cooking" its not a good thing. Good lord it takes long but boy does it look good. I am now in a position deciding between Unity and UE4 and I can't decide in the most first world problems way you could imagine, its a sad state of affairs my life has become since I started this game development thingy.

 

Yes, as always, Unity is the best bet. But that is the answer to expect when asking a bunch of people using Unity.

 

You are asking on the Unity forums. Which means everyone here has a bias towards Unity...

 

Didn't read thread, but yeah, use Unity.

 

Out of curiosity, why can't you use GML? What do you mean it doesn't work for you?

 

Saw you mention AppGameKit on Twitter. Curious about it now. Will have to read up on it.

 

UE4 is very heavy on memory usage. I'd consider doubling the amount you currently have or going even higher.

I voted C++ because no one else did.

 

If you're used to programming in something like AMOS or Blitz back on the Amiga then AGK is awesome. Here is a simple 2D raycasting engine I converted over from Blitz to AGK2 in a day or so. Of course, it is only solid shading but that is because I have always been interested in creating a 3D game with that simplified look.


It isn't very fast as you can see but that is because I am entirely redrawing the display with lines. Using sprites would work much faster these days due to the way the modern graphics cards work. Of course, I probably should have done all of the rendering to an image (think render texture) then drew that on the screen. Hmm... I might just try that sometime when I am bored. Of course this is also written in BASIC and I bet if I ported it over to C++ it would be considerably faster. So that is yet another experiment for another day.

It does actually support 3D as well but I haven't done anything with 3D in it yet.

I don't now man... I've always been a programmer first & foremost and so I always loved just being able to jump straight into a programming language and just start building stuff. Like this thing doesn't have a single file of media or data loaded for anything. Just defined the level in code inside the program. The map cells determine the base wall color and the shading is simple I just shade for darkness based on the distance the ray travels to hit that slice of wall.

 

I spent a lot of time with AMOS and even more time with Blitz3D back in the day, so I know what you're getting at. I really love the all-in-code approach too, but I feel like it's only really suitable to creating "retro" games these days. I think that one of the real benefits that a product like Unity or GameMaker provide is the asset management side of things, which is pretty indispensable once a project starts to get beyond a certain scope. The appeal of what you're doing in your example is that you get to work a little closer to the metal in terms of not having the engine do all of the work for you. You need to actually think about HOW you're going to draw things on the screen, which kind of largely gets taken out of your hands with a more complete engine like Unity. I've taken to referring to Unity/GameMaker type products as "Orchestrators", as this level of asset management/IDE really goes beyond the definition of an "engine".

 

Better yet build the raycaster inside of a shader.

https://www.shadertoy.com/view/MdXXz2

 

It is a wicked cool demo. Didn't realize you could do such things with a shader. I don't see where the data is stored in the code but I am guessing being a shader it is pulling the map data out of the texture that is fed in / attached, right? You can't actually make it interactive inside the shader can you? Like it surely can't read the keyboard and mouse, etc in there can it?

Kind of a shame I never got into shader programming because the code I have seen (this one looks very different from most I have taken a quick look at) actually looks like something I'd probably enjoy.

 

Searching for Breakout was actually how I found the website. This is actually playable.

https://www.shadertoy.com/view/MddGzf

Just ran across this tutorial for shaders that makes use of ShaderToy. Aside from that I don't know much about how it works internally but I do know you can have shaders read in textures and send the results from the shader to another texture.

https://gamedevelopment.tutsplus.co...s-guide-to-coding-graphics-shaders--cms-23313

 

I think some code outside of the shader is reading the input and passing it in. If I understand the code correctly, I believe this line is retrieving the paddlePos that is being passed in from outside code that is actually reading the input and updating the paddle position.

float paddlePos = texture2D( iChannel0, (txPaddlePos+0.5)/iChannelResolution[0].xy ).x;

But I could be wrong because I have never done anything with shaders before.

But it surely reminds me of long ago on the C64 writing games in BASIC then calling machine code subroutines and poking in parameters right before the calls. lol

EDIT: I forgot to say thank you for showing me this game. It is very cool. Really like this kind of stuff because it is what I was talking about very recently over in my thread about graphics: relying on programming to jazz up the display. And this seems to be the purest form of it from what I can see the cool rubbery paddle and glowing block hit are entirely a programmed FX.

 

There is definitely a lightweight framework sitting in the background passing data in and out of the shaders depending on what the channels have been set to. Below the code you might have noticed four images which represent the four channels you can configure.

It's definitely one of the few remaining ways to feel close to the hardware while still being able to do something useful.

 

I had the same question as Steve....what makes you not be able to use GML(and Gamemaker: Studio)??? People here will be biased to Unity, but in my opinion GML/GMS is superior to Unity for the specific purpose of 2d games, unless you have a certain need that it can't handle(which I doubt is the case considering you are asking this question in the first place).

 

It runs just fine on my testing system GTX 580 and I7 920 with 8GB. It shouldnt lag on your specs. What kind of scenes do you make? Well, without derailing to much. I would look into best practices with UE4. You should have quite a nice experience other, unless you go absolutely overboard with scene size. Doubling your ram is indeed the first thing I would though, as mentioned elsewhere.

 

As a programmer who seems to really enjoy programming just for the sake of it, drop everything and start playing with shaders, trust me on that.

Every time I have to write or modify a shader, I teeter on the brink of, "Why not build the whole game as shaders?" That doesn't make any sense, of course, there's a lot they can't do ... but I do have to restrain myself from going overboard with features and endless tweaking. As a bonus, I haven't run into debugging that was that primitive and frustrating since I gave up assembly. "Highly recommended, five stars, would write shaders again."

 

This. I never did assembly. So shaders where a whole new type of pain for me.

But if you really want a world of hurt, I'd suggest debugging mechanical systems. Finding that one relay which is slightly corroded and fails intermittently is some of the best times I've had.

 

lol... my other hobby is 50s/60s cars, I know all about that pain.

 

The craziest one I had was a pallet sensor on a string of conveyors. Every morning for about a month the guys would hit me up as soon as I went into work, saying the conveyor system was broken again. I would walk in, watch it, and it would work perfectly. No issues for the rest of the day. But sure enough, the next morning there would be the same issues. Always just before I got in to work. Never when I could see it.

It wasn't until daylight savings changed and the issue when away that I realised it was the sun coming through the windows at just the right time in the morning. A simple shade cloth and the whole thing went away forever.

 

@GarBenjamin

Definetly look at shaders. The C64 tec-tec shader (my first shader), was included in one of the files. It's just a line of code.

I did a couple of old school effects in shaders and it's really fun, feels much closer to the hardware, closest thing to "VIC tricks" you can get these days, I guess.

 

Do you want to actually make a game? If yes, then use Unity. It will save you time and let you focus on actually building your game.

You can build a game in C++ without any game engine, but that will take more time and will likely be a distraction from actually building your game. Going that route will mean coding solutions to mundane tasks already handled by a game engine.