🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Looking for advice on how to proceed with my game

Started by
4 comments, last by slayemin 6 years, 1 month ago

So I have probably spent about 200 - 250 hours in the past 4-5 months prototyping a top down 2D roguelike / survival game (something along the lines of CDDA) in Unity. While everything has been going ok, I am starting to think that most of the tile map managers (assets store ones or the newly built-in one) is just overcomplicating things for my needs. I am also starting to think that Unity itself is overkill.

My needs for a tile map manager is really just placing layered tiles on the map of x / y coords and maybe having a few basic brushes and that is about it. With the game being turned based, having actual colliders seems like overkill where just getting the tile and checking manually would work just as well with less overhead.

The Unity IDE also seems like overkill since I am hardly in it. I am only in it when building the UI, playing the game, and debugging. Everything game development wise outside of UI creation is done in code since pretty much everything is generated procedurally from data files.

If I decide to continue with Unity, I feel like I am going to have to:

  • Setup my own tile map data structure and manager just so I can make things as simple as possible even though that would probably require working with Unity 2D at a lower level which from what I hear is not that great (even with the tile map manager I had, I still had a number of issues with pixel snapping / artifacts and such at the beginning)
  • While I have 80% of the systems prototyped and working at a very basic level, the code would need moderate / major refactoring before I would be comfortable trying to start to build additional features on top of it

With this in mind, I figured now would be as good as any time to look at spending a couple of months prototyping the game in another engine or high-level toolset. Again my idea is that since I am not really going to be using a lot of the power than Unity has, there might be something to gain by going with some smaller and simpler engine / high-level toolset but still has the limited features that I need.

Instead of trying to figure out what the best game engine is (since that is subjective and does not really exist), I want to get some advice of what game engines / high-level toolsets might fit the requirements that I have. The must haves with no exceptions are:

  • The code that I have to write needs to be managed (and by that I mean I don't want to have to deal with memory management because this is no doubt I will shoot myself in the foot, leg, hand, arm, etc. if I have to deal with that).
  • I want all the lower level APIs (like calling OpenGL, DirectX, OpenAL, etc. directly) to be dealt with under the covers so that I can easily draw stuff, load sprites, play sounds, etc. using the engine's / high-level toolset's API.
  • Need to be able to develop on Mac
  • Need to be able to deploy to Windows / Mac
  • Needs to have the following features:
    • A true 2D engine that is designed to work ix X / Y and pixels (not a 2D game in a 3D engine like Unity)
    • A Sound API
    • An Assets Loading Pipeline (it should be relatively easy to load up a sprite sheet, slice it into is sprites, etc. through code)
    • An Input Management System

Now at the very top of my really nice to haves would be:

  • Has easy support for ECS (I have recently looked into this since I know Unity is moving towards that and from what I have researched, it looks like a very interesting way to structure code for reusability that fits more with me than traditional OOP)
  • Has an active community and helpful community
  • Has a decent UI system, stuff like:
    • Being able to display a list of UI "elements" of any number
    • Being able to have flexible container boxes (kinda like css flexboxes)
    • Being able to display images / sprites / icons in the UI
    • Being able to overlay the UI anywhere on the screen

And then at the bottom of the nice to have list would be:

  • Is being actively developed / maintained (it does not need multiple commits every day and releases every month but it should not have nothing for months on end)
  • Built-in / external module for 2D AStar Path Finding
  • Additional engine features like Lighting, Physics, etc. (again, I have no need for this stuff however if available, I would probably be able to make some small use of it)
  • Game logic is written in a lighter weight language or functional language (like Lua, JavaScript, etc.)
  • Has no custom Editor / IDE (this is because I prefer code and I don't want the "why are you trying to use code instead of the editor" response like I have often gotten with Unity when I asking questions).

For the specific points of my game that I would want to take into account when deciding on another engine / high-level toolset to prototype in, they would be:

  • With the game being turned based, it is going to work off of a global game action units system that increase when they player perform actions and all other entities would listen on and perform actions based on the game action units that changed since they last update (which will probably being at least in the 100's of entities, I can even see if maybe reaching 1000+)
  • I want to have a near infinite world that is procedurally generated (which I would imagine would be able to be done by storing the map is small chunks of like 16x16, 32x32, etc and then just loading / unload those chunks that are in a certain range of the player as they move).
  • I want to have a relatively large area of simulated world. Obviously I can't simulation the 10s of 1000s of entities that would be in the entire game world but I would like to try for what CDDA does with it reality bubble which is 132 x 132 (which is also 17424 tiles that would be rendered at any given time) and simulate the entities in there (and simulate I mean stuff like npcs / enemies moving, items decaying / rotting, building tiles burning, etc.).

Outside of these points, everything else in my game (like quests, npcs, enemies, items, skills, stats, AStar pathing finding, crafting building, etc.) I think should be able to work in any game engine.

Right now Love2D is at the top of my list of engines / high-level toolsets to try. It uses Lua as the scripting language which also has a number of ECS libraries that I could try out. While I would like to use a lighter weight language like Lua, my top concern with that is performance (especially related to point #1 + #3 with what how much I am going to want to simulate in the game) but from what I hear, LuaJIT, which Love2D uses, can provide near c performance so...

I would like to get people opinions on Love2D related to all the points above as well as any other engines / high-level toolsets that at least fits the must haves from an engine / toolset perspective and will support the performance based features of the game that I mentioned.

I plan on trying to get a character to move on a map in each engine / high-level toolset that should be able to support what I need and they make a decision of which to take further into the prototype.

 

Advertisement

So you want an allround game creation tool that is absolutely working for your special kind of game and expectations ... you're wrong here! Every game engine/creation toolkit you'll find on the net like Cocos 2D, Game Maker, Unity or Unreal is just made with the intention to be general and more powerfull to what mainstream game development belongs.This means that they are allrounder tools but also less specific so that you can develop any kind of 3D or 2D game with them.

This means too, that you have to setup your tools and working pipeline as you need it; by your own! (Programmers never die ;) )

If you have worked with Unity for that long time, you should keep staying on it unless you have very clear reasons why not to (and those reasons are not that you don't like the toolset). You have to dive into each system even if you switch to something else so my suggestion is to stay where you are if you already have the code base, learn for how to work with Unity more efficently. Unity allows to write own tools in the same language as you developed your game with and also provides any access to the 3D / 2D features by them or you look into Asset Store to find something that fits your needs

@Shaarigan Thanks for providing your advice.

I don't think I am looking for an all around game creation tool but more so a toolset (or lower-level engine) that provides me a nice programming interface to what I would consider the really bear metal code needed to make a game (like being able to load image / sounds / etc for use, making the draw calls through something like OpenGL, capturing events from input, etc.). For me, Unity, Unreal, Godot, Lumberyard, etc. are the all around game creation tools (which I have not completely excluded from this exploratory process I am doing right now) but the things I am definitely willing to consider more after working with Unity on this project are things like Love2D, MonoGame, etc... (I would not classify those as all around game creation tool but more building blocks for building the blocks need to build a game).

The reason I feel it might be worth while to make this exploratory process is that while I have been using Unity for the past 4-5 months on this specific game idea, not a lot of the code is Unity specific. About 80% of the codebase is just plain old C# with no dependencies on Unity. the other 20% are MonoBehaviours that really just connect the functionality of the other code and some UI specific stuff. The code is also in a state I just throw shit at it to just see what works and does not so I am going to have to refactor it a bit (probably completely re-write parts of it) so before I do that, I figured looking at simpler options that might remove a level of complexity that I don't need would be good. Wether I stick with Unity or go with a different option, I will be able to use that codebase as a model (regardless of what language I use going forward).

I mean after spending a little time reading up on Lua and about 6ish hours in Love2d, I have a prototype of being able to setup the data for a really large map (40K x 40K tiles) and have it just render a small subsection based on the players position with a section of the game blocked off for UI. Now I know there is still a number of things I need to do here but that is a good chunk of my graphical needs

Just because I have spent 4-5 months in Unity does not mean I should stick with it (of course my project requirements also does not mean I should move away from it either). I started with Unity foregoing the processing of look at other lower level options because my original idea that I had would have been able to make use of a lot more features that Unity would have been useful for. It seems to me since that has drastically changed, I might want to look at other options before I am too deep into Unity.

 

7 hours ago, 3dmodelerguy said:

after working with Unity on this project are things like Love2D, MonoGame, etc

The problem here is that you expect anything to work instantly on Windows, Linux, mac and whatever platform. This is just provided by the "generic game creation tools" like Unity or Unreal and you have to spend additional working to get it running on other platforms. Means something like Mono-Based needs to be build for .Net to work under Windows, needs to be build for Mono on Linux and as XCode project on Mac utilizing the Mono Runtime. We suffer this every day building our software for Windows and Mac, two different platforms means two different build pipelines and possibly API changes. This isn't something you would like to take attention to when "just prototyping a game" unless you have certain audience that creates the need to do so.

You wont have the convinient one-click deploy you have in Unity or Unreal.

7 hours ago, 3dmodelerguy said:

About 80% of the codebase is just plain old C# with no dependencies on Unity

This isnt really unnormal to development with unity. I last wrote a car simulation in Unity and most code was self written relying minimal on Vector3 and doing some transform in an update loop, anything else was too plain old C# code.I wont say "I don't use Unity's functions much so I don't use Unity much" because anything you do, launching the game, loading textures, materials, meshes propably and render the stuff is handled by Unity. Even the C# code is running on an internal Mono Runtime that is embedded into the Unity player. Unity handles your your Update loops, render pipeline and a lot more in the background so maybe you will read a little more technical about what Unity or a game engine really does.

But if you want something lower level, you should concider if it is worth either to seek a lot deeper in the net and maybe end on something that may be more buggy as Unity is (haha, good joke XD ) or you'll have to spend a lot in achieving your must-have bullets with more lower level systems:

  • I looked at but have never worked with Urho 3D, it is cross platform Angel Code supporting community driven game engine with an Angel Code extensible editor
  • OpenTK a pure C# wrapper arround OpenGL, OpenCL and OpenAL implemented cross platform so you could setup your building with it on different platforms. Taking Assimp# in addition and you have anything on hands to setup your game in C# from scratch

I've written my game engine/framework from scratch using just only OS dependent API code so I know how much work it us to setup an environment before be able to code a game with it. It isn't something you would spend just a few weeks on rather than a couple of years (measured in hobby time)

It sounds like you're saying, "I spent 4-5 months making a rough prototype in unity and now I have a lot of technical debt to pay off. Therefore, I need a different engine and I want to start over!"

That's... ridiculous.

Your top complain against unity is that it has features you don't need to use. So what? Don't use them. You also say that a lot of the features are overkill. Unless it directly affects performance in your final build, so what? You're trying to fix problems you don't have.

In my opinion, you should stay the course and spend some time paying down your technical debt and then building on top of your current work. Under the hood, game dev is messy and rickety. Focus on shipping, not on building a pristine palace of perfect code. If you try to make everything perfect, you'll be at this forever and will never release and you'll constantly be second guessing yourself and your tools. That's the opposite of productive.

This topic is closed to new replies.

Advertisement