In these days i’m investigating on the engine vs non engine opinions around the web.
My first resource was this episode of Roguelike Radio, ( link ).
Which just for a coincidence had as one of the topics “The motivation for a roguelike library/toolkit, the limitations of curses, and the failure of attempts at bigger generic engines”.
After a bit of research and comments, the user Trefall posted a very useful link ( link here ),which i think it’s an older post on the topic.
The “non engine” group of users have as main points observed that
- a game engine without a game over it is useless
- the risk of making a “too much generic” engine causes big heavy engines ,which hasn’t an optimal way to solve requirements that a game developer could have.
- If you have no experience on writing a game, it’s not a good idea to create an engine
While all these opinions make perfectly sense,my theory is a bit different:
based on my previous experience as a developer , i do not agree with almost everything said:
To do my job i use a php framework (Symfony ) that allows me to create sites and web applications in a matter of hours.
If i had to make all that i do with a single symfony task, i’d use days of work.
In just a bunch of lines of configuration i can build a whole database and the admin generator “modules” which allows me to handle CRUD interactions with the database.
It’s a matter of 5 minutes.
I think that every branch of software development has its standards and its way to create a common set of instruments that can make the job easier.
That’s why i think that the first assumption is wrong: a monkey wrench isn’t useless just because it’s sold without bolts.
I agree with the second assumption,though: a too “wide” engine, does not solve any specific task good enough, and therefore is not an advantage,therefore to have success, i think that an ideal engine must be very small and mustn’t try to solve “everything” ,but just a limited list of tasks.
I totally disagree with the last aspect : i think that writing a game and writing an engine are two totally different jobs.
It’s like saying you can’t be a mechanic if you haven’t got the driving licence.
This is obviously a wrong assumption: to be a mechanic you need certain skills and knowledge, to be a driver, you need others.
The objectives of building a game, and the objectives of building an engine (or set of instruments, if you prefer) are totally different, and i think that the only point of contact of the two environments is the game logic: that’s what a game developer should put his/her head!
I think it’s useless to waste time in common tasks like splitting the “layout” in zones, building menus, and so on: a layout is always a layout ,and the fact it’s split in several areas shouldn’t occupy more than 10 seconds of the developer time: it’s not a part of the game logic.
Every minute put in the development of not “game-related” features is taken from a game-related feature: a game developer should use his/her (usually short ) time to think about the game, and not to think about the things you need to make the game.
Just to make another example, the same goes for a menu: you can change colors, and something else, but its purpose is always the same: giving you the opportunity to select an item of a list. Why waste time on that?
I know that frameworks exists in almost every development branch, from o.s. to web applications, they exist in almost every language: c++, java, python,php ,etc.
So why in the roguelike world should be stupid ?
For the moment i don’t have enough data yet.
My research continues: my objective is to build a very unusual game, and to reach that goal i need instruments ,now they are small enough to be used almost anywhere.
If they get bigger, that would probably create some problem.
Killer Project - Roguelike game 
I don’t think it’s stupid. After all I praise libtcod (which is an unobtrusive framework/toolkit for roguelikes) and I make heavy use of the T-Engine (a specific roguelike engine). But there’s a lot of reasons why engines aren’t successful:
– Language restrictions – your Java engine is of no interest to a C# coder
– Many games are open source already, so getting access to standard algorithms isn’t hard as is
– Most developers start off with a small project, and thus have all the menu and i/o code done on a basic level pretty quickly. There’s no need for them to reinvent these for each project. Essentially each dev has a personalised engine.
– It’s a lot of work to make a complete engine, and it’s easy to lose motivation long before getting anything workable from it
– Without games that show off an engine’s potential no one will bother using your engine
– Without games to test out your engine you’ve no idea if it works or works well
– You’ll never satisfy what every dev wants
– The sort of people that obsess over making engines often aren’t interested in game design
– If you don’t know how a game is made then you don’t know what an engine needs to provide – this is way way closer linked than driver and mechanic
– Engine making is dull and hard work, with no real pay-off at the end – making games is way more satisfying
On top of that libtcod and the T-Engine fill most of the gaps in this sphere. There’s not really a niche to fill now. Outside of roguelikes there’s Unity. I’m not sure why you’d want to make an engine with so many tools already readily available.
Yes, there’s always the exception to the rule, which is DarkGod, but generally, if you build an engine to place your game on top of, then you’ll be stuck forever in engine code.
LibTCOD is great in that it allows you to get a quick start, but from there it won’t hold your hand, so you’ll end up making an engine based off of LibTCOD then… I think this is why a lot of LibTCOD projects fail, and why there’s mostly successful 7DRLs made with it.
T-Engine is a great effort and roguelike engine, and TOME4 is the proof of it’s success. But like you said in the T-Engine episode, Darren, it’s kind of hard to force the engine and scripts to behave in such a way that you get a different game that something TOME4’esque. Please correct me if I misread that, Darren.
Personally, I feel there’s a very special reason why Unity3D has got the success it’s got in the indie space. It has a very strong toolset, that’s easy to set up to interact with scripts in such a way that everything becomes very intuitive and easy to control. UDK or Torque3D, who were the two other major indie development engines doesn’t have that same ease of use… Simply put, Unity has done so many things right, it simply has to be experienced and understood.
Thus, I really feel that it’s a shame no one has made any generic LibTCOD’ish package for the Unity engine yet. I know only of:
https://github.com/boj/Roguey
But it’s problem is that it doesn’t play to the strengths of Unity3D at all, trying to implement it’s own tile-based lighting engine, etc…
If I end up making a Unity3D-only game for my 7DRL, I’ll release the scripts open source for people to check out, but I might be going with a C++ server / Unity3D client approach…
Anyway, I think the driver and mechanic argument is a very good way to put it. Coding an engine and coding a game is two very different disciplines of coding. To make a game, you really don’t need to know much coding at all, there’s even visual scripting tools out there, like Playmaker for those that just want to string together game logic. http://www.hutonggames.com/
Engine code is a different beast entirely though, with low-level coding requirements reaching into a wide problem-space. And I’ve been there and have found that fantastic and fun, but I never ever got to the making a game part when approaching a project like that… I have a ton of respect for those that start a game with the bare minimum requirements and drive forth with short tunnel vision, but I just can’t do that myself. I always end up with these great schemes of architecture that, like Darren puts it, ends up failing because I hadn’t the game development experience required to make such great schemes actually work… I didn’t see the actual problems of the game, since I was focusing on the generic engine problems…
Using Unity3D as the starting point though, you already have all the bells and whistles of a cutting edge engine. Input handling systems for all the platforms you’d ever want to support, rendering support for most systems (though you might find it hard to support those really old ones that some roguelike players might still use), and a one-click deployment scheme that gives you support for all the major platforms within PC, Consoles and Mobiles. These systems set aside though, there’s something to be said for having such a huge community of developers using the engine every day, squashing the bugs and sharing resources, and to base a game on something that is that stable, and has such a huge community of developers, comrades in arms, is a really great comfort when you suddenly find yourself knee deep in the trenches of what is game development.
First of all, thank you again for your opinions, i think there are many common factors to our points of view.
@Darren, i don’t want to make an engine, i just want to make the tools that will allow me to create this game, and possibly some other, in the future.
The main question,as i understand it, is the logic forced to the developer by the engine.
we all agree that a big engine would cause more problems than solutions:
the fact that such an engine would force the developer to follow its logic and its behavior is just an example of what that a “strong” framework cause.
another common ground is the consequence of the previous statement: a small amount of instruments gives the developer enough freedom to think about the game,and at the same time employ some time to “fix” or create small tools.
Actually more freedom than a more advanced (or just complex) instrument.
A fact that i totally didn’t notice before Darren’s comment instead is:
<>
In these days i’m downloading tons of RLs to get ideas,to experience and see different environments,game logics ,and i must say i have been VERY surprised.
I knew RLs from quite some time but actually i understood that i just scratched the surface of a totally new world for me.
And seeing different projects from the same developers i actually realized that it’s true: different games, same instruments.
So the question that crossed my mind is: is it possible that the instruments needed to create a RL are so few,and so easy to generate that’s easier to create them once,just the first time, than adopt a common “tested” solution ?
Still don’t know the answer.
For now, based on what you’re saying , my direction is shifting a little bit, instead of pointing directly to the game i want to make , i think i’ll need to create some “tech demos” or test environments ,this to achieve some result in a shorter time, to avoid the possibility that working on a “non game” could stop me.
The 7DRL challenge sounds like the perfect opportunity for you then to get started on such tech demos ;-)
I think a problem with many of the big, expansive engines is that they base any derivative games on a template project that sets up the basics, but ultimately will make every game based on it feel or look slightly the same. UDK has this, Torque3D has this, and from my impression, T-Engine has this.
Here Unity3D is different. It gives you the toolset and the bare engine, but in a new project you’ll have to start drag bundled scripts onto your empty game objects, or start writing your own. This is a testament to the component-oriented model for writing game logic.
http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/
Sadly i’m still not enough skilled: i’m having problems with libtcod on osx :| i’ll have to switch to an ubuntu box on virtualbox now …