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.