Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411196 Posts in 69314 Topics- by 58380 Members - Latest Member: feakk

March 18, 2024, 10:18:51 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Game Engines for Indie Developers
Pages: 1 ... 13 14 [15] 16 17 18
Print
Author Topic: Game Engines for Indie Developers  (Read 371456 times)
Sixmorphugus
Level 0
***


._.


View Profile
« Reply #280 on: June 07, 2014, 05:23:38 AM »

I tend to code my own Game Engines when I'm making 2D stuff, since the logic for 2D isn't anywhere near as hard as it is for 3D. There's a lot of stuff to keep an eye on if you go down this route though, especially if you're doing it in C/C++ and have to deal with memory management.

There's also the SMALL issue of a proper working rendering system. I remember my first game engine didn't have an FPS counter until near the end of development, at which point I realized that all of the menus in my game ran at 1000-1200 FPS and the GPU was starting to smell funny.
Logged

There's no place like 127.0.0.1.
Damycles
Level 0
**



View Profile WWW
« Reply #281 on: June 07, 2014, 10:08:09 AM »

I'm a pretty big Unity4 fan, as I've used it for multiple projects and enjoy the support that many SDKs offer for it. For all oculus fans, developing on Unity is really simple and with the right research, it's pretty straightforward to put out some cutting edge stuff.
Logged

@nick_joebgen<br />@bearfootgames
Si
Level 0
*


View Profile
« Reply #282 on: June 21, 2014, 03:50:25 AM »

Recently I started developing games and writing experiments in SFML, to which I transitioned to from Unity. Do note that in the past, especially when I was learning to write code and create graphics applications, I would use gfx APIs such as OpenGL and DirectX. So from this I would safely say that I have a fairly solid experience in not only programming but also games and graphics. The point I am getting to is why I am using SFML now, instead of Unity or any other commercial engine that I have tried. Here's some thoughts:

Unity is great for design, not serious game development. Unity is an engine developed for people who are not low-level C++ graphics or engine programmers, people who want to get in and get something working. The scripting API and the methods in which the API interacts with the engine and the underlying systems initially presents itself as a direct and appropriate entry point into rapidly producing ideas and content.

When you start implementing systems and features, especially that interact with the physics system, issues start to emerge, many of which that have not only left me, but colleagues and fellow game developers running in circles. Unity is like the Apple UIKit framework and libraries - it wants to be used in a very specific manner. Pushing the system to do anything more than this is setting yourself on the road for an uphill struggle. Of course, many things can be achieved in Unity, but deviating away from the intended path is going to make the road ahead a lot harder.

I'm not saying in any form a game developer should not use Unity, I'm saying if you want to create something complicated and you know you have specific requirements of the system, especially in relation to physics, think again. This extends itself further, potentially causing the developer more headache when using the 2D system within Unity. What's wrong with using the lovely new 2D features in Unity? you don't use a 3D engine to make 2D games, the result is some bloated bastardisation of code, architecture and systems. Use a 2D engine to make 2D games.

So why am I using SFML? zlib licence is an influencing factor, no more issues with licence or royalties. I create 2D games, I don't see myself creating an 4D MMO online Space sim anytime soon, SFML offers everything that is needed to get something up and running in 2D as quick as needed, but allows enough open space to take it as far as is needed. It is fast, easy to use and any systems or specific requirements I, or my team need can be elegantly and appropriately implemented without spending five hours rewriting physics operations to stop strange glitches. Of course there is the argument that development will take longer, that some factor of reinventing the wheel has to be applied, but does it really? Writing an API from the ground-up, yes, but using a library middleware, it's a case of building architecture and systems on top of it, not much different from writing scripts. The GUI interface controller and state-handling system I wrote in Unity ported to C++ and SFML rather well, and so did the logic of some other systems, once I had a foundation in which to build it into.

So in conclusion: don't buy into the hype or jump on the "current trendy engine/editor" train that is in fashion. You're making games, you're making art and investing your time and energy into this. Find the right tool for the right job and don't be afraid to invest some time into learning something out of the ordinary if you have to; follow the path of least resistance. If it means using "Engine/editor x" then so be it, but why and for what reason? Because everyone is using it, because it's "easy", because you're afraid to try something different? Or because it's the right tool for the right job that will provide you the platform you need to realise your creative vision in the most effective manner possible.

 
Logged
Gatlink
Level 0
***



View Profile
« Reply #283 on: June 21, 2014, 04:05:20 AM »

I've seen only one mention to Love2D... What about it? I quite like it, at least for prototyping. Haven't gone to full project with it yet...
Logged
Si
Level 0
*


View Profile
« Reply #284 on: June 21, 2014, 04:46:42 AM »

I've seen only one mention to Love2D... What about it? I quite like it, at least for prototyping. Haven't gone to full project with it yet...

It depends entirely on what you want to achieve in respect to your projects technical requirements. LÖVE is great fun for knocking out ideas and experimenting with the feel of mechanics. It's one of the easiest and quickest ways to get into the "fun" aspects of developing a 2D game. But this of course has limitations, something you can learn and starting making experiments with in one afternoon isn't going to offer you the capabilities and full extended facilities that are needed from a long-term project. Of course you are free to extend the system if you download the source, modify itself and manually compile the binaries, but it's not what it's intended for. It's a "pick up and play" solution, really very ideal for game jams and having a good time dicking about in.

I cannot personally attest for making a fully functional game within LÖVE, as I have not done so, but I have observed some interesting longer term projects being developed. It seems that it operates very well for the quick "sketches" and ideas utilising basic elements of game development: moving sprites about with simple physics. Of course you're not limited to your logic and algorithms you implement in your game architecture that promotes with the LÖVE engine, but you're not going to get the existing systems doing more than you want. This can be annoying with using LUA, as you are completely limited in what you're doing, you are placed in a box with some toys to play with and you can't go beyond that.

So in conclusion I personally perceive LÖVE as a fantastic means to experiment, create cool, simple projects and demos, but would not see it functioning as a means to implement into your tech pipeline for your project as the sole means to producing your long-term game project if you can see any requirements deviating slightly away from the tech integrated within the LÖVE LUA API.

There may exist other bindings for LÖVE, I have not looked into and even some extensions of the system itself, however it would seem at this point it's getting to a point of desperation and many other options exist as a means to accomplish your requirements.
Logged
DarkBulb
Level 0
*



View Profile
« Reply #285 on: July 22, 2014, 05:41:19 AM »

I've being going through listed game engines and couldn't find GameMaker there. What's the opinion on it? I've being playing with it few months back with really small things not remotely being close to full fleshed games or prototypes of those like Spelunky. Now I have lot of free time and I'd like to work on one of the designs I have and I'm not sure whether I should stick with GM or try something different. What I'm looking into is 2D game, top down view, randomly generated sets of rooms (all same size) and interiors, around 40 of them per level and around 25-30 types of characters per level. As for programming goes, I've been learning C# for last 2 months.
Logged

Apologies for my grammar and punctuation.
SolarLune
Level 10
*****


It's been eons


View Profile WWW
« Reply #286 on: July 22, 2014, 07:05:19 AM »

Haven't really used Game Maker in ages, though I did download and try Enigma-dev, which is a GM clone. In any case, at this point, I think it's safe to say that if you have any 2D game ideas, GM should be able to handle them no problem. Tons of 2D games were made with GM (Nuclear Throne, Spelunky, etc).

The only thing I might advise you of is that there's not a lot of built-in types for GM's language to my knowledge. Like, there are dictionaries or maps or whatever, but they're not built into the language, so there's functions specifically to handle them, which is very, very odd and a poor choice in my opinion. Coming from Python where you can just do

inventory = {'gems':10, 'coins':95, 'backpack':{'potions':10, 'iron_sword':1}}

to having to run entire functions to add keys and values is just plain odd. However, this is based on the equivalent language in Enigma-dev, which is very similar to GML for cross-compatibility purposes, so I'm not sure how accurate this is with GM:Studio (which is free for Win, Mac, and Linux now, I think).
Logged

Adam_
Level 1
*



View Profile WWW
« Reply #287 on: August 27, 2014, 11:45:26 PM »

I happen to develop an Open Source game engine called Duality. Maybe that's something for the list, too? Smiley

NameLicenceSupported PlatformsScope, Intent and useageProsCons
DualityMIT License / FreeWindows / .NetComplete game solution. Editor-based workflow.
  • Plugin architecture
  • Basic Graphics, Audio, Physics, Input, ...
  • Visual editor
  • Live Editing
  • 2D only
  • No official Multi-platform support yet
  • Small community
  • 2D only

There is also a devlog about it, right here in the forum.
Logged

KyleBatteson
Level 0
*


View Profile
« Reply #288 on: November 03, 2014, 11:57:37 AM »

Unity seems to be the best bet for quality and platform range and it's cheaper.
Logged
LuisAnton
Level 1
*


View Profile WWW
« Reply #289 on: November 20, 2014, 05:23:38 AM »

Reading cons makes me feel that no game engine is nice enough to bother about it!

However, I've been using Unity3D basic since 2009. I paid for iOS and Android versions a while ago, but they are free new! That is, with with basic version of Unity3D you may publish now on quite a lot of platforms, for free (Windows, Mac, web(player), iOS, Android, Windows Phone...)

It's great to build small games (all our games were created with Unity3D!). c# is a nice language to work with, I'm pretty happy with it. Sprites, added a year ago, are great for 2D games.

Sure, it's not enough if you want to dig deeper and go low level - you can still manipulate meshes and textures, but it's CPU expensive sometimes. Or if your game requires a certain look (I've not toyed with shaders, though) . But I can't imagine a mechanic I can't code in Unity3D right now (there probably are, but I've been able to hack most ideas in a breeze)

I still think it's a great engine for many, many projects, and I don't see myself moving away from it for a while.
Logged

HDSanctum
Guest
« Reply #290 on: November 22, 2014, 03:09:38 AM »

I've been working with Urho3D lately, which is an opensource (MIT) engine that supports C++, AngelScript and Lua (+ LuaJIT). Like Unity, which I've recommended before, it has a lot of features that just work out of the box (although, it doesn't have anything like the Unity video tutorials to get you started), and as someone who's submitted a few small contributions, I can say both the C++ and scripting is quite easy to get into.

1.32 was just released, with quite a long change log: http://urho3d.github.io/

Notable features:
  • Builds without a fuss - many have commented on how easy it is.
  • An editor that auto-reloads resources, and will display errors in scripts. It's not quite as integrated as Unity yet, but it does have things like displaying public script variables on component attribute editor, a material editor, UI builder, and more.
  • Community, although small, is active in answering questions and bug fixing. Many cases of same-day bug fixes.
Logged
iDev
Level 0
**



View Profile WWW
« Reply #291 on: February 03, 2015, 10:49:27 AM »

Seem's as if no one is considering dx studio. Dx studio has absolutely no start up costs for you to start developing both 2D/3D commercial games. Early last year dx studio was made completely free. Though the engine is no where near as advanced as unity, it still is in my opinion the perfect engine for single developers to make 3D games. I Suggest taking a look.
Logged

SolarLune
Level 10
*****


It's been eons


View Profile WWW
« Reply #292 on: February 06, 2015, 07:22:11 AM »

^ I just checked, and actual engine development seems to have stopped. Last time I checked, I seem to recall that it's pretty "singularly platformed" as well (just Windows or something like that)? I don't quite remember, and the Wiki seems to not have that page up. It'd be nice if development were continued.
Logged

eyeliner
Level 10
*****


I'm afraid of americans...


View Profile
« Reply #293 on: February 13, 2015, 06:53:46 AM »

DXStudio is amazing, but the company needs people pushing them to update.
I messed with the engine quite a lot, and became well versed with it, but the outdated physics engine kill it for me.
Logged

Yeah.
deathbeam
Level 0
**


Master Devil Cyborg


View Profile WWW
« Reply #294 on: February 27, 2015, 12:30:46 AM »

I always loved simplicity of Love2D.

Only thing that I do not liked about it is bad support for Mobile. Yes, there is LOVE port to Android, but it is simply script runner and no "native" android applications what can be published to Google Play cannot be made with it. Also, I do not liked language choice. Yes, Lua is super simple, but also lacks some OOP features and it have it´s weird table system.

I decided to take best from Love2D, Game Maker and Gradle (Java build automation tool) and I created Non2D in Ruby with support for direct access to Java for some low-level code. My engine works on most platforms, including Windows, Mac, Linux, iOS and Android because of Java and LibGDX backend, what can be easily compiled to Dalvik VM for Android and Roboto VM for iOS. Also, when using Ruby, I was able to use RubyGems as deployement platform, so you can install my engine CLI with single command. As for Ruby scripting I am using JRuby, Desktop and iOS build times are blazing fast, but for Android it can take a while cause JRuby code is big and it exceeds 64K method limit, so for Android builds, Non2D is using multi-dex, what have really slow build times.

You can check Non2D in thread right here on forums: http://forums.tigsource.com/index.php?topic=46351.0
Logged
eyeliner
Level 10
*****


I'm afraid of americans...


View Profile
« Reply #295 on: March 29, 2015, 07:19:03 AM »

I always loved simplicity of Love2D.

Only thing that I do not liked about it is bad support for Mobile. Yes, there is LOVE port to Android, but it is simply script runner and no "native" android applications what can be published to Google Play cannot be made with it. Also, I do not liked language choice. Yes, Lua is super simple, but also lacks some OOP features and it have it´s weird table system.

I decided to take best from Love2D, Game Maker and Gradle (Java build automation tool) and I created Non2D in Ruby with support for direct access to Java for some low-level code. My engine works on most platforms, including Windows, Mac, Linux, iOS and Android because of Java and LibGDX backend, what can be easily compiled to Dalvik VM for Android and Roboto VM for iOS. Also, when using Ruby, I was able to use RubyGems as deployement platform, so you can install my engine CLI with single command. As for Ruby scripting I am using JRuby, Desktop and iOS build times are blazing fast, but for Android it can take a while cause JRuby code is big and it exceeds 64K method limit, so for Android builds, Non2D is using multi-dex, what have really slow build times.

You can check Non2D in thread right here on forums: http://forums.tigsource.com/index.php?topic=46351.0
I'm not sure if you'll ever read this, but make a tutorial for your Spooker framework, pretty please.
Logged

Yeah.
motorsep
Level 0
***


View Profile WWW
« Reply #296 on: April 29, 2015, 11:38:05 AM »

Have anyone mentioned Darkplaces engine and idTech 4 (sorry, tought to find in 15 pages thread) ?
Logged

Kot-in-Action Creative Artel
@motorsep
@phaeton_game
website
YouTube
Armageddon
Level 6
*



View Profile
« Reply #297 on: April 30, 2015, 12:49:41 AM »

Have anyone mentioned Darkplaces engine and idTech 4 (sorry, tought to find in 15 pages thread) ?
I've never had any luck compiling either of those sadly. They don't have a whole lot of documentation or tutorials. Love the look of idTech engine games though.
Logged

motorsep
Level 0
***


View Profile WWW
« Reply #298 on: April 30, 2015, 01:59:47 AM »

Have anyone mentioned Darkplaces engine and idTech 4 (sorry, tought to find in 15 pages thread) ?
I've never had any luck compiling either of those sadly. They don't have a whole lot of documentation or tutorials. Love the look of idTech engine games though.

Well, to be fair CryEngine has pretty bad documentation (from what I gathered reading forums). UE4 isn't great either in that sense, but I am almost certain Epic will get there - engine is just too new.

Darkplaces was the easiest engine to compile for me on Linux (gcc) and Windows (MSVC) Smiley

Original release of IdTech 4 is indeed painful to build, but there are a few good forks that use make, which makes them very attractive for cross platform building.
Logged

Kot-in-Action Creative Artel
@motorsep
@phaeton_game
website
YouTube
quarkrobot
Level 0
***



View Profile WWW
« Reply #299 on: May 07, 2015, 06:40:42 PM »

Anyone else out there using FNA?
Logged

Pages: 1 ... 13 14 [15] 16 17 18
Print
Jump to:  

Theme orange-lt created by panic