Hi, my name is Gustavo Totoy, I am a gameplay programmer and I was going to tell you what kind of methodologies guide the programming of To Leave. Basically some ideas related to OOP,
component-based programming, generic programming, among other things. However, this week I read an interview with Niklaus Wirth (The creator of Pascal programming language) in the book “The Dawn of Software Engineering” by Edgar G. Daylight and some ideas about the environment of Game Development Technologies came to me. Those ideas are exposed here, so I will leave programming methodologies for my next post.
Wirth is known by his work as programming languages designer, he is the creator of EULER, ALGOL-W, Pascal, Modula and Oberon. Besides designing languages with more formal tools than those used in his time, he also reinforced good programming practices with them, as Structured Programming (which Dijkstra promoted) is reinforced in Pascal. Wirth as an engineer liked to always take in account efficiency and industry needs while designing and implementing his projects; and as a professor he knew simplicity is a key concept to convey ideas, and that he needed all the experience acquired through programming (compilers and operating systems) to teach.
Probably last paragraph is a very limited description of who Niklaus Wirth is, but I think an introduction was needed. One of the things that struck me in the interview was his opinion regarding the relationship between industry and academia. The book’s author mentions that during 1940s and 1950s computers were being built at universities. Later the manufacturing moved entirely to the industry. He also mentions that during the 1950s and 1960s many new programming languages were designed by academics and then the industry chose his favorite languages (C, C++, Java), making the academia stop creating languages because the academia should offer products industry can use, i.e. software written in his favorite languages. Wirth mentions several examples like C & C++ from AT&T, C# from Microsoft and Go from Google and is concerned about user community inertia and that first established thing is difficult to remove. He also mentions that if something would be able to establish itself in the medium, it should offer a big difference so that change can occur and that sometimes you have to start from scratch to produce innovation. So the academia should continue with the research and not take for granted design issues such as programming languages, computer architecture, operating systems, etc. Particularly he mentioned that if there is a future in designing new languages, these are languages for particular application areas.
Returning to videogames, it is known that video game development studios create their own technologies that increasingly make major advances in the area. It can be seen in the games that have come out recently, e.g. “The Last of Us” of Naughty Dog. The technological level is amazing, the obtained graphics, the scripting language design, the game engine architecture, map editors and other programs used in the development. The concern is that these private engines are developed for games with profitable purposes, so they cannot spend years researching and choosing general, elegant, efficient, simple and easy to use solutions, but what sometimes guides the development is to have something running on the target platform so the engineers have to sacrifice some of the above characteristics to get faster results. If current results are amazing, can you imagine what can be achieved if all of the above features weren’t necessarily sacrificed?
Besides private engines, there are general purpose and commercial engines like Unity which offers an easy learning curve and little friction to start. But having a Fat API is one of the tool’s weaknesses. By Fat I mean that, it’s like too much functionality have been added without rethinking the general concepts and abstractions. Therefore the overall API does not feel like a whole. Most likely the people of Unity have the knowledge and had thought about how to make a better tool. Nevertheless, it seems to suffer from the user community inertia. That is, all Unity users like upward compatibility and automatic project conversion with every new version of the engine; if Unity tries to remove the upward compatibility to provide a better tool, the users will want the best tool that Unity can develop as long as it provides the upward compatibility too. Can you see the problem here?
Another concern is that current solutions may encourage developers to think that the best scripting languages for games, the best architecture of engines, the best map editors, and the best architectures of consoles have already been developed and not continue to innovate and to search for new solutions to these problems.
To finish my remarks, I would like to say that it would be great if academia would do research on the various topics that involve game development technologies, so that it could provide new and better alternatives to industry. After all the academia could start from scratch and start looking different places for better solutions that sometimes the industry is not allowed to. Furthermore, these advances would be more available than private technologies and have a stronger foundation than some currently existing free tools.