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.