What you are about to read is my thesis for the Master II in Design and Management of Interactive Engineering at Gobelins, Paris, in 2021. It was originally written in French and was translated into English in 2023.
This essay is aimed at both developers and designers, as its goal is to bring the discussion about their workflows. Therefore, I tried popularize technical terms to the maximum.

Abstract

As a Front-End developer in a Web agency, and also keen on developing video games on Unity, it was only natural that my thesis focuses on these two universes. Or more precisely, on a comparison between these two topics.

Over time, I realized that workflows in the Web industry are not as fluid as those in video games. So I wonder : Why tools and workflows in the Web industry are broken, and how to fix them?

If one day you have to collaborate with developers to create an interactive experience (Web, application, video game or software), this thesis is for you. I discuss workflows and tools that a developer can set up to communicate and collaborate with people of different expertise in the most efficient way.

Through this thesis, I present a state of play of the Web industry, its legacies, its issues and its new tools. I also tackle the topic of the mystification of the developer profession, and how it represents a stumbling block in this big question, and how the video game industry has managed to solve it. Then, it would be interesting to think about how to implement these solutions in the Web, and how this could impact the current tools and issues.

Introduction

I have been developing video games with the Unity Game Engine for 7 years now. In addition to small personal projects, I have been working on the game A Cairn Tale, my first commercial project since 2019.

Over the years I fell in love with Unity.

You might think it's only because I'm passionate about creating video games, but it's not just that. There is something special with this software, or any game engines in general.

Game engines make it possible to create complex things  easily and quickly, and with relatively little knowledge. It is possible to build full blown prototypes in a few hours. For example during Game Jams, a sort of development marathon where participants must create a game with a given theme in a limited time, 48h or 72h in general.

I did a work-study program in a web agency for 3 years as a fullstack developer. I worked on a wide range of projects: mobile applications, showcase sites, e-commerce sites...
It was a good experience, but unlike when I’m using Unity, I get frustrated quickly when doing web development, even when it comes to creatively stimulating projects.

It’s not really the projects that generate this frustration, but rather how to make them. I actually feel like I'm wasting a lot of time: I often find myself repeating the same tasks, going back and forth with the design team a lot, often for little details. Also, I often fight against the tools and how they work. This loss of time added to the limitations of the tools means that I find myself not being able to go further creatively speaking.

This frustration actually stems from a workflow problem.

What is a Workflow? According to the Wikipedia definition, ”a workflow or operational flow, is the representation of a series of tasks or operations carried out by a person, a group of people, an organization, etc.”

Therefore, I will try to understand how production tools help to set up workflows and understand why the workflows that game engines allow are more efficient. Which leads me to ask myself this question: Why are web tools and workflows broken, and how can we fix them?

In this thesis, I will first try to understand what is not working in the web industry today and why. Secondly, we will try to understand why it is necessary to understand the developer's job to create tools that improve the workflow. Following this, I will study how workflows are articulated in video games with the help of two interviews with professionals in this industry: Florine Fouquart and Chloé Vigneau. Finally, I will reflect on how similar philosophies could be applied in the web industry.

The state of  Web

The Legacy of Print

Originally, the Web, created at the European Center for Nuclear Research (CERN) in 1991 by Tim Berners-Lee, was a simple document exchange tool designed to simplify communication between the various scientists of the complex. We find this notion of document everywhere in the current Web, in particular in its technical functioning: for example, the structure of a Web page is based on the Document Object Model (DOM).

Tim berners-lee - creator of the World Wide Web

In parallel, the Web design - today, we prefer the term UX/UI design - is historically based on Print design, i.e. the design of documents to be printed (posters, flyers, covers, etc.). This origin goes back to first web agencies, which were former agencies of print advertising. For example: Publicis is the 3rd group communications company and the world leader in digital communications in terms of revenue. It was created in 1926, and was at the time an advertising agency. It made a shift to digital quite early, in the 90s, and gained its leading position by buying many agencies in the 2000s.

In order for Print designers to adapt quickly to new web media, the logic of Print has been projected on web design. This is why we find similar jargon between the two domains: we talk about pages, margins, typography, etc. As a result, many web designers still have a Print-oriented logic, when they work and create for screens.

However, in the early 2010s, the Web underwent a profound evolution with the arrival of smartphones, and the rise of responsive design, sites now having to adapt to different media with radically different screen sizes. Over the years, web technologies have improved and allowed browsers to do much more than just display a document:

• In 2011, the arrival of WebGL made it possible to implement 3D experiences directly in the browser.
• In 2013, Electron enabled the creation of desktop applications that work outside of web browsers, while using the same technologies. Discord, Spotify, Figma, Slack are among these new hybrid applications.
• In 2014, HTML5 is officially finalized, the new version embeds, among other things, new features allowing media playback directly in the browser without using Flash.
• Continuously, the CSS used for the layout has evolved to allow the creation of responsive sites. Especially with the Flex-Box and CSS-Grid features.

Today, the Web is interactive and dynamic, its technologies are used everywhere and can run complex applications. Therefore, we can no longer really speak only of documents.

The Web even tends to replace the Operating systems (Windows, macOS, Linux) in their roles as application and file managers. Indeed, with Cloud Technology, it is now possible to archive your files, and to perform the majority of tasks that required installing software on the computer before. For example with Google Workspace (Google Drive, Gmail, Google Docs, Google Sheets).
Google fully adheres to this philosophy, with its range of Chromebook computers, where the browser completely replaces the graphical interface of the operating system.

As one might suspect, this evolution had an impact on the tools used.

Current tools

Originally, few things was necessary to build a web page: you had to create templates with markup languages HTML for structure and CSS for the layout, some programming with Javascript to add basic interactions, and optionally a Back-End language like PHP to connect this page to a database.

With the appearance of Node.js and the front-end frameworks like React, JavaScript has become the main language in the web. So much so that today, it is possible to create a site only in JavaScript.

Having a single language used throughout the production pipeline has the advantage of standardizing the skills of developers and simplify the communication between the different teams. Moreover, JavaScript is relatively easy to learn, so it is easy to train new developers, or former PHP developers for example. This language is extremely versatile and can adapt to many situations, which makes it an excellent communication tool between development teams.

However, using JavaScript everywhere comes at a cost.

First of all, Javascript is considered by many developers to be a bad programming language, because it has many technical flaws due to a use that completely exceeds what was intended when it was designed. In particular, an exhaustive list of its inconsistencies can be found on wtfjs.com. 

But I'm not going to talk about it more in this writing, because I'm going to talk about problems which are related to the pipeline that surrounds this technology, rather than the technology itself.

Among developers who worked on web projects before the democratization of “All-Terrain Javascript", I heard several times some of them complaining about the complexity and the instability of the current production workflow. In order to use JavaScript anywhere in a web project, you need a multitude of interdependent packages.

The term “package” is used to describe computer code that has been made public. A package can contain one or more code files. In general, it allows you to add functionality to an application. (Here, a website)

To manage these different packages, we need a multitude of tools. You have to install them with the package manager Node Package Module (NPM).

When you install a package, other packages necessary for its operation are also installed, w

e then speak about dependencies. Thereby, we quickly find ourselves with hundreds of modules installed on a project. We do not know the origin of these modules, and in general only a tiny part is used directly. We must pay attention to the compatibility, to the updates of this package which are maintained independently of each other.

For information, NPM surpassed 1 million available packages in 2019.

You must also use a bundler like Webpack to compile all these packages and generate a compatible and optimized version of the website for all browsers. All these tools do not have a Graphical Interface. Everything is executed using command lines and by writing config files, which you have to remember or look for them on the Internet.

Therefore, it may take almost half a day to set up and configure a web project at present. In the days of HTML/CSS, this only took a few minutes.

The problem doesn't just stop with developer tools. On the web, the designers produce graphical interface models that will be integrated by the development Team. This means that a model will be copied over and translated to code by an integrator or front developer. If we had to draw a parallel with the Print, the developer replaces printing machines.

Designers have graphic tools to make models. As we saw above, these tools take up the Print Logic, although the end products are web and digital products.

In terms of use, their ergonomics are well thought out to facilitate the work of designers. For the developers on the other hand, who must also use these tools to integrate the models, we meet many limitations. In particular, the layout information cannot be easily obtained in CSS code. Some solutions have been proposed to overcome this problem, but they themselves have their own limitations.

For example, for the design tool Sketch, one of the most popular on the market, we went so far as to create another tool: Zepline. Coupled with Sketch, it allows the user to extract the CSS from the models. This additional tool - just like sketch by the way - both require a paid license, and are not cross-platform. For the many developers who work on Windows or Linux, they find themselves forced to adapt to a new OS, just to be able to consult the mockups.

Some designers, still attached to their Print habit, use software from this field such as Photoshop or Illustrator, while these tools are very deprecated in the eyes of the UX/UI community. According to the annual UX/UI Tools Survey, they were the 4th and 5th respectively in the ranking of the most popular tools for interface design in 2020.

Other tools try to make efforts. Figma offers to inspect the CSS code of an element directly in the software. It is also cross-platform and can be used free of charge. Adobe XD software also offers HTML/CSS exports that can be used as a basis for a developer.

However, as the integration of the models is done with different technologies, by different people, there will inevitably be some losses of information during the communication and the difference between the model and the final rendering can be large. This loss of precision can lead to disappointment for designers, and can drastically increase the number of returns requiring small changes (color, typography, spacing, etc.), thus generating a significant waste of time and energy.

“You are never better served than by yourself.” - Charles Guillaume Etienne

Design systems & Website builders

In an attempt to solve these problems, new tools have appeared.

One of these tools is the Design System. This is a graphic and ergonomic charter that serves as a guideline for the different professions. It takes the form of a library of reusable components which will be used to compose the screens of a site or an application.

This is a step in the right direction. This is a workflow improvement, because it allows designers to better structure models, increase the speed of designing them, and maintain consistency on projects with a large number of screens.

This facilitates the work of the developer by directly presenting the information he needs (color, dimensions, typographic rule). Nevertheless, the majority of these Design Systems are implemented in graphic design tools, so the work of the developer does not change: he must always copy the model provided by the designer.

In conclusion, Design Systems simplify above all the work of designers, but not really the developers' one.

A track that seems even more interesting is the no-code development tool Webflow, selling itself as "The future of Web design". It is a mix between a CMS and a graphic design tool, allowing to develop sites with complex animations using a graphical interface.

In this way, we build the site by assembling blocks with drag & drops directly on the page, and we can configure the visual rendering of these blocks easily in the interface.

Contrary to what their marketing may claim, using Webflow without any knowledge of web development is very difficult, because the block system is based on the same logic as classic Web development and must respect the same constraints as HTML/CSS code. This can be confusing for a designer coming from Print.

By itself, Webflow does not really solve the problem raised above, because it does not really help developers by simplifying their tools, he seeks to replace  them with a paid service.

Webflow

In the Web, in fact, each time something does not work, we add a new additional tool in the workflow rather than iterating on existing tools to improve them. We even completely disrupt the workflow by removing all the tools to replace them with something else

Conclusion

As we have seen, having too many tools coming from different sources and without common integration can lead to a loss of control.
The risk is to do the equivalent of a Stack Overflow error:

“In computing, a stack overflow is a bug caused by a process which, while writing to a stack, writes outside the space allocated to the stack , thus overwriting information necessary for the process.” - Wikipedia

More this complexity increases, the more communication becomes difficult and confusing, and the less the different professions of a project understand what the others are doing, especially what the developers are doing.

Demystifing the developer

Following the problems mentioned above, we can see that as a developer, we work within a Black Box. That is to say that beyond a certain complexity inherent in the job, few people have access to the internal workings of the job, and we tend to represent the developer as a Wizard. In the same way, we used to call "sorcery" the scientific concepts that we do not didn't understand yet.

However, it is by stopping to qualify these concepts as magic and being afraid of them, and by seeking instead to try to understand them that we have been able to revolutionize science, discovery and industry. So I will try to demystify the developer profession.

Like that of a designer, the job of a developer consists of solve problems. The difference is that once the solution has been found to this problem, they must write a way to automate this solution. The latter should be transmitted to other developers, but also be able to be proofread by themself, and potentially executed by a computer.

To do this, they describe very precisely how this solution works using a programming language, or code.

The code is therefore a communication tool, the main objective of which is to be read in order to understand how to solve a computer problem.

Our job is to communicate, but people don't understand us.

As highlighted above, the profession of developer has almost a mystical dimension, and it is felt by many as too complex to understand.

This lack of understanding creates a scission between the developers and the rest of the team, which ends up being felt in the workflows and the tools that shape them.

Therefore, it seems necessary to demystify computer science in order to better integrate developers into the workflows and regain control over our tools. Starting with the concept of abstraction which is, in my opinion, the key to getting there.

The concept of abstraction in computing

It is almost impossible to read and understand the entire operation of a computer and to read the millions of lines of code that compose it. Fortunately, computer science is governed by this central concept: the abstraction.

The abstraction is defined as an intellectual operation which consists in isolating by thought, one of the characteristics of a thing and considering it independently of the other characteristics of the object.

In computer science, a program is a set of instructions (= algorithms) and data. This program is itself a set of subprograms which depend on each other within a dependency tree. Each program is implemented in such a way that one only needs an abstract knowledge of how its dependencies work, as well as an abstract

 knowledge of how that program is going to be used by other programs.

This principle is applied to all scales, whether it’s an interaction between software and the operating system, or the use of a function to perform a mathematical calculation. Each program is structured with multiple layers of abstraction which allow the collaboration between developers with different specializations and skills. Thereby, they allow the realization of very complex programs.

For example, the open source operating system Linux has about 29.7 million lines of code. The Mozilla Firefox web browser has 21 million lines. Fortunately for web developers, to create a web page all you need to do is to use the documentation. The latter explains how to use the functions (= programs) of the browser or operating systems, without having to consult a single line of their source code.

How to write a program

In order to see how these layers of abstraction are used concretely when writing a program, we will focus on the three types of languages ​​involved:

• Natural languages: These are the languages ​​used by humans in a classic way, to communicate and think. They are simply French, English, Spanish…
• Programming languages: These are conventional notations used to describe algorithms and to produce computer programs that apply them. Contrary to popular belief, they are designed to be read by human beings, and are unreadable by a computer without additional processing. Noteworthy examples include: C, C++, C#, Javascript, Python...
• Machine language: These are sequences of instructions coded in binary (1 and 0) intended for the processor of the computer. This language is incomprehensible without translation for a human being, that is why we use programming languages ​​which will be translated into machine language by programs called compilers and interpreters.

If we look, these three types of languages ​​are in fact three layers of abstraction. One can read each layer independently and understand a sufficient part of the operation of the program without having to be aware of the operation of the layers above and below. In summary :

• Natural languages: The general idea of ​​the software
• Programming languages: How the software is described in detail
• Machine language: How the software is executed precisely by the computer

Programming Paradigms

Depending on their complexity and size, programs can be difficult to understand. This is why developers may choose to write technical documentations, in textual format or in diagrams format (UML). The goal is to make it easier to get an overview on how a program works.

In addition to documentation, programming paradigms represent a more elegant alternative and/or complementary solution.

If programming languages ​​are the syntax and grammar used to describe a program, the paradigms are the figure of speech. Those are the analogies that simplify the overall understanding of the program.

For example, the object-oriented programming (OOP) paradigm makes it possible to build a program as a set of concrete objects: a car will be made up of tires, steering wheel, headlights, doors... with their own respective functions and properties. Another example of a paradigm is functional programming, which describes a program as a series of nested mathematical operations.

Therefore, Paradigms are an additional abstraction layer which slips between natural languages ​​and programming languages, and makes it possible to model the program, in order to make its understanding less abstract.

Paradigms are a good way to understand how a program works, but are only understood by those who can read code.
So, how can non-developers be helped to understand the program?

The End-User Development

Henry Liberman and his colleagues define the End-User Development (EUD) in their article End User Development : an emerging paradigm, as a set of methods, techniques, and tools that enable end users of software, who are not professional developers, at any given time to create, modify, and extend a software artifact.

The objective of End-User Development is to be able to integrate people without development skills, and who cannot train for lack of time or motivation,  in the production workflow.

The promise is to set up a concrete environment, which allows the rapid appropriation of the tools by the end-users, who will be able to directly integrate their functionalities into the program.

Like the programming paradigms, it’s an additional abstraction layer which makes it easier to understand the program. But in the case of the EUD, the analogy set up by the paradigm is represented in the functioning of a tool.

This tool is therefore a popularization of the programming language. Popularization is defined as the fact of adapting technical and scientific knowledge to make it accessible to a non-specialist reader.

This popularization allows the user to manipulate programming concepts but without actually writing a line of code. Thus, non-programmers can become developers.

An example of very popular EUD software is Microsoft Excel, with approximately 800 million users worldwide. Indeed, it allows you to create complex functions directly in the software with the macro configuration tools and by only using the software interface. These macros are normally written in the Visual Basic programming language.

One industry has gone further by basing its entire production chain on this logic: the video games industry.

The EUD in video games

A complex industry

The video game industry, like the Web, has undergone in thirty years a spectacular growth.
An illustration of this evolution: The precursor game of the FPS genre, DOOM, was released in 1993. It was developed by the seven employees of the ID Software studio in a year and a half. Twenty-seven years later, DOOM Eternal, the fifth installment in the series, was released after four years in development. It will have required approximately 200 additional employees. There are also some graphical improvements...

Doom (1993) - Doom Eternal (2020) - id Software

Video games have grown to be  the most profitable entertainment industry with more than $165 billion in revenue in 2020. In comparison, cinema generated $96.8 billion in 2018.

It is also one of the most expensive and complex media to achieve. For example, Grand Theft Auto V, released in 2013, is one of the most expensive games of all time, has an estimated production budget of $135 millions (excluding marketing), for development time of about 5 years and a team of more than 1000 employees. Trivia : For a 2023 update, it was recently revealed that The Last of US II and Horizon: Forbiden West, have production budget over $200 million each, obliterating the Rockstar Games record.

But, whatever the size of the team or the allocated budget, the production of a video game requires the collaboration of all multimedia disciplines : design, animation, programing, 2D graphics, 3D modeling, etc.

To meet the challenges of developing a video game, tools and pipelines (= workflow) have been created to be able to create these interactive universes. The video game industry has implemented a system called The Art Pipeline. The idea is to create an environment of interconnected tools making it possible to convey fluid and iterative way, step by step, a game asset (for example a 3D model) from its design phase to its final version integrated into the game.

Game Engines

At the heart of this pipeline is the Game Engine. It is intended to be potentially used by all the trades involved in the design of the game, and not only by the developers. Since the asset routing tools are directly connected to the Game Engine, it acts like a big hub.  Concretely, the engine is a development environment embedding a set of components and tools that implement the generic features necessary for the realization of a game, such as: the rendering engine, the physics engine, the management of the import of assets, or the management of user inputs.

This allows the teams to work directly on the creation of essential elements for the identity of their game like gameplay and art direction, without wasting time reinventing necessary generic features.

Modern Game Engines like Unreal Engine and Unity combine a multitude of tools for different trades. These are End-User Development tools for creating an abstraction on the operation of the engine, too complex to be understood by people without knowledge of computer engineering. The goal is to allow the designers and artists to integrate and directly manipulate the final rendering of textures, 3D models, animations and even gameplay.

Therefore, the engineers are relieved of the integration work, which is simplified, and can concentrate on developing and improving the functioning of the game engine.

Integrator artists

Thanks to this pipeline in the video game industry, integrators are in fact the designers and  the artists. For example, the profession of Level Designer corresponds completely to the profession of integrator/designer. The role of the level designer is, as his name suggests, to build game levels. To do this, he uses tools directly included in the engine to do “Greyboxing”, that is creates a playable model of the level from simple geometric shapes completely devoid of graphic elements. After him an Environment Artist will add a coat of paint by adding 3D assets, textures etc. We could compare these two stages to the User-Experience (UX) and User-Interface (UI) parts in the context of web development.

Valorant - Split Map Level Design & Environment Art - Credit: @RiotPHRISK

Obviously, in the reality of the profession, the integration of tools into the game engine is not not always so smooth. But the philosophy used to create this development environment and the workflows that it allows remain very interesting.

Case Study: Nodal Programming

To better understand the pipeline of a game engine, we are going to look at EUD tools that compose it: nodal programming, oriented for design teams / artists.

Nodal programming (aka Visual scripting) constitutes a typology of tools allowing to generate code in a programming language. It is a specific paradigm, operating from visual interfaces, say nodal: the instructions of the code are represented by boxes called nodes, interconnected by links.

This type of tool is very common in the world of video games. We note for example the Shader Graph of Unity, the BluePrints of Unreal Engine, or the software Houdini.

Unity - Shader Graph

Limitations

To become aware of the challenges and potential limitations around nodal programming, or more broadly the pipeline, I interviewed to people from the video game industry: Florine Fouquart (aka Flopine), Technical Artist from DONTNOD Entertainment, et Chloe Vigneau, digital project manager and serious game designer at Copotato.

Florine says about node programming within Unreal Engine:

“Often, what is put in place upstream for [the functioning of nodal programming], that is to say the part that is hidden from the use of a non-initiated, it’s dantean. And I have a problem with that.”

The idea is that, in order to guarantee an ease of use of an EUD tool, we are obliged to build  an even more complex program for developers. For example, within the framework of nodal programming, it is necessary to: program the interface, implement each basic functionality of the language (= mathematical operations), create simplified versions of the complex operations (functions), and finally create a compiler or an interpreter which will be able to transcribe the program created by the EUD tool into a programming language.

Another problem noted by Florine:

“If we often let artists fiddle with Shader Graphs because it looks easy, I think we'd end up with Shader Graphs that have double the instructions and don't really run in real time.”

In fact, since it is only an automated transcription, we end up with a very long code and totally not optimized. Despite their accessibility, EUD tools cannot not replace the role of a developer 100%, who will know how to make good technical choices about the performances and the readability of the code, and therefore its durability.

Chloé Vigneau also confirms this idea:

“Companies that sell "game factories" have a product logic, so they will try to develop all the projects sold on their tools. But sometimes you have to take more time on the game design to choose the right tool that will meet the need.

The "game factories" are generally created to allow very profitable games to be made, because there is no developer to pay. But in the context of an ambitious project with a complex game design, the tool does not do everything and certainly does not replace the skills and vision of a developer.”

Chloé also testifies of a bad experience, where she and her colleagues had to throw away an entire project that had been designed in nodal programming:

“The gap between the tool and the game engine was too big for improvements to be developed within the timeframe of the project. And especially it was not the goal of the company which develops this software. The lead dev preferred to rebuild [entirely] the game directly under Unity rather than spending the same time improving the tool to allow me to resume the development.”

In summary, the problem was that the teams tried to do everything with a tool that was not unforeseen for this use. The scope of this tool should have been better assessed before designing the program. This scope can only be properly assessed by a developer and in general, if one tries to use more than features that were initially implemented in the EUD tool, it can be very expensive and long to modify it. We therefore sometimes prefer the versatility of real code.

The Technical Artists

The game industry's response to its problems is the Technical Artist profession.

Florine Fouquart explains her missions to us:

“We are led to do R&D (research and development) on various subjects that affect the production pipeline of a video game. But our main role is to act as an interface between artists and Engine Programmers. On the one hand, we give artists everything they need to apply the Art Direction, to make these tools simplify their life, and on the other hand to simplify the life of the engine by paying attention to quality in technical terms and in terms of performance for the machine. Fulfilling both an artistic quality and a technical quality.”

Technical Artists are “Technical facilitators” of the production pipeline. They have very diverse areas of expertise and action. In this case, Florine Fouquart is a Technical Artist specialized in the visual rendering of 3D models, but there are also people specialized in particle effects, animation, etc.

So it's a transdisciplinary job at the junction between the development and design teams. We note that in general, these are people who have had a mixed career: some of them were designers who decided at some point to automate their tasks, or vice versa, developers who wanted to create the assets they used to integrate.

In conclusion, this is a designer/artist who knows how to code.

Can we use the same workflows ?

Game engines, due to their great flexibility and ability to prototype  and produce quickly, start to be used in other industries. This is particularly the case for the film and animation industry. Disney used Unreal Engine 4 to achieve some special effects for its Star Wars: The Mandalorian series. The company had also made Baymax Dreams, an animated series entirely made with Unity.

Making of the The Mandalorian - ILM

One could therefore wonder if workflows with tools similar to the field of video games would be applicable to web development.

Adobe Flash

As such, there have already been tools allowing a similar operation in the past. This is particularly the case of Adobe Flash, which is no longer used today.

Adobe Flash was “a software allowing the manipulation of vector graphics, raster images and ActionScript scripts in order to create multimedia content (animations, videos, games, applications...) intended for publication on the Internet.” - Wikipedia

It was an environment composed of many tools shared between designers and developers, allowing a very powerful abstraction. Therefore, it can easily be compared to some kind of game engine that is very easy to use and deploy. He was also a major pillar in the advent of the music scene. Indie video games : Indeed, many creators of independent video games are former “Flashers”. Some of the most influential players in the industry declare that they would surely not be where they are today without Flash, such as Edmund McMillen (Super Meat Boy, The Binding of Isaac) or Maddy Thorson, whose game Celeste won the Best Independent Game and the Games for Impact Award in 2018.

On the web side, the FWA (Favorite Web Awards) site has been recognizing the most innovative sites on the web every day since 2000, and a huge portion of those sites were Flash sites. They say in an article in memory of the software:

“FWA... for many years some thought this stood for Flash Web Awards. Even though it didn't, for over 10 years FWA Site of the Day winners were almost always Flash sites, around 99%. Thus, you could understand the F could mean Flash.”

We can understand via this trait of humor that Flash was also a huge innovation engine for the web, which is also confirmed by many members of the industry as can be seen in this post:
https://thefwa.com/article/the-industry-thoughts-on-flash

The motion designer and former Flasheur Alexandre Soubrier (Moon Palace) regrets:

“There was no place for fluid animation at the time, apart from GIFs which had to be very light and color-limited. So this software was a small window for huge creativeness."

“Flash was too good for prototyping. Currently it is very difficult to achieve the quality of what Flash did before in terms of animations on the Web. The level of creativity on the web has gone down.”

Alexandre Soubrier explains that the specific programming language of Flash, Action Script, was a very simple language use and learning. Which meant that even as a designer, without knowledge of computer programming, it was possible to create a complete website.
So we find, in a way, the principles of the EUD.

However, this will not prevent the official end of Flash support on December 31, 2020, after almost ten years of agony.

The reasons for the death of the software come from the fact that it did not know how to adapt to the evolution of the web in the early 2010s, with the arrival of Responsive Design and new devices (Smartphone, tablets). In addition, major security flaws were found at the end of the 2000s. But above all, Apple played a major role in the end of Flash by disabling its support on its various devices from 2011, in particular on the iPhone. .

I can therefore conclude, by simplifying, that a video game engine allowed the Web to become what it is today. The arrival of HTML5 and its technological improvements far surpassed Flash on its weaknesses. However, HTML5 did not fill the hole left by the greatest strength of the software : its tools and their accessibility. Everyone watched Flash slowly die without wondering what good things could have been saved.

Can we use the current game industry tools?

Since we can consider Adobe Flash as a kind of game engine, could we not use the current game engines to develop websites?

Unity and Unreal Engine have features to export projects to HTML5. But these engines pose several problems:

• These built-in tools are too specialized for video games and are not suitable for traditional web development. Among other things, the functionalities specially dedicated to the interface creation, which are verybelow the power of HTML & CSS technologies.
• Exports are in Webassembly, an experimental feature that helps support high performance in a web browser, but does not necessarily have the same support on all browsers. We immediately think of Internet Explorer… Moreover, the use of Web Assembly for simple interfaces seems excessive.
• Integration into a page is done with a player that runs the site/game, instead of using native web technologies.So we have the same problems as with Adobe Flash: Loading, responsiveness, potential security vulnerabilities, etc.

So, It is necessary to create an engine from the ground-up, optimized for the creation of interfaces and compatibility on all browsers, and which will use native Web technologies: HTML5, CSS3 and Javascript. 

Betraying the essence of the Web

Most major web technologies are Open Source, or at least in part. This means that one can access and use the source code of a technology, language, etc.

This is the case of languages ​​such as HTML, CSS and Javascript, but also web browsers such as Mozilla Firefox, Chromium which serve as the basis for Google Chrome, Microsoft Edge or Opera. We find the same logic for libraries and frameworks like React, Vue.js and others.

This allows developers to actively participate in improvement of these technologies by fixing bugs, or by adding functionalities directly in the code. This Open Source community is very active and offers a large amount of tools of various sizes for free.

However, as we have seen previously with NPM, having a development of uncontrolled tools without quality control can be a problem, especially when the size of the projects increases and then requires the use of many functionalities of different sources.

To create a tool the size of a game engine, which would then have all of these features in one place, will require a lot of coordination and maintenance. It therefore seems essential that a large organisation unique - like a company - controls the development of this tool. The latter would then surely be paying, but above all non Open Source.

Would this not endanger the principles of the Web, based on open technologies and on exchanges between the different members of the community?

In themselves, current Web tools may be open source, but they are already controlled by large corporations like Google with Chromium, Facebook with React, Amazon with AWS. Designer tools are simply not open source at all, and are almost systematically license based.

On the other hand, Unity for example, is not an open source game engine, but the software remains free to a fairly large extent, and still has a community very active and which helps to improve the tool, by adding functionalities using plugins (free or paid). Some of these tools were even bought back then officially integrated in the engine.

The best open source tools  in the video game industry, such as Blender or Godot, appeared in response to the tools developed by private companies that existed before them: Maya and Unity. It is still possible to create tools of this scale in Open Source, but their existence seems to be conditioned by the competition already present on the market.

Just because you're creating a new development environment doesn't mean you should stop people from using existing open source environments.

The objective of creating an engine would not be to replace existing tools, but to offer one alternative. The idea is not to remove the current Open Source tools. Freedom or comfort, it's a choice to make and it doesn't really matter as long as you can change your mind when you want.

We saw previously that if we can have the tool, and therefore have the workflow, what about the people?

Questioning the profession of Creative Developer

The currently existing position, which comes closest to the hybrid profession of Technical Artist in the world of video games (Developer-Designer) is what is may be called a Creative Developer.

A trendy term whose definition is quite vague.

There is often confusion as to what characterizes its missions. If we search for Creative Developer job offers on LinkedIn, for example, we find advanced interface development missions, that is to say with advanced animations, 3D, interactive experiences. However, the missions are similar to a front-end integrator, but more advanced than most websites, using additional technologies to the classic HTML/CSS/JS trio.

“Creative developer” is actually a nice word for “immersive site integrator”.

I think Creative Developers should tend to become the equivalent of Technical Artists for the Web, which is truly missing. Moreover, as we saw in the first part of this writing, the problems of integration do not only concern immersive sites, but all types of projects. Thus, this double-profile of tool creators should not exist only in this specific context. In this configuration, it’s the UX/UI designers who become integrators.

What then becomes of the Front end developers ?

Our job as a developer is to design solutions to automate systems. So if we fear that our job is automated, it is because we have not understood where our place is: Integration is not automation, but something that will and eventually needs to be automated. It is then up to us to be proactive in order to target professions where we do what is the basis of a developer: solving problems. We are software designers before being programmers.

Conclusion

To summarize what we saw above, the Web industry lacks industrialization. Current workflows are completely alienated by the legacy of the Print, and do not seem adapted to the new challenges brought by the previous decade and the new one. From my personal point of view, this raises several worries about the sustainability of the industry.

In itself, as a developer, it's normal to use bits of tape to complete a project on time. But building an industry with tape can become problematic, and it might be time to ask questions before the technical debt becomes too heavy.

On the one hand, I think that it is important to look back, and to reestablish Flash's Honor. I think we don't talk about it enough, even though its legacy is very important. Moreover, as we are not interested in it, we do not ask ourselves questions about what is missing in the current Web.

HTML5 is arguably better than Flash, but the tools are inaccessible to non-developers. We need an HTML5 editor, Open Source, which centralizes tools and trades thanks to a complete interface, similar to Flash or a game engine like Unity. This tool must obviously be adapted to the size and complexity of web projects.

As a developer, I think my place would be more useful to create tools, rather than being a designer's tool myself. In addition to all the benefits that have been raised, I think this place would be more rewarding on a personal level.

Unfortunately, as we have seen, the creation and maintenance of a tool of this magnitude must be in the hands of a large organization.And I'm afraid that the industry is likely to change until GAFAM or big startups create these tools themselves.

However, this does not prevent you from trying to improve your workflows and your tools on these principles, and above all from sharing them.

Endnotes

As I have not found any real solutions, here are some personal recommendations:

To start, if you are a UX/UI Designer and you have the time: learn the basics of HTML & CSS. By understanding how language rules work, you will be able to design responsive interfaces more easily and therefore obtain integrations that are more faithful to your initial intentions. It will therefore be easier for you to negotiate complex renderings, while reducing the back and forth between the design and development teams.

Use Figma, it's free (or almost, and I adobe will not ruin it), cross-platform, you can access the CSS code easily. But above all stop using Sketch, please, in addition to the flaws highlighted above, it's the only reason why I have to have a Mac...

Then, for all those who are interested in it, regardless of their profile, you can try Webflow for free to get an idea. As we saw earlier, I'm not a fan of their Business Model and their marketing, but this editor is the closest thing to an engine for making websites. Other alternatives are beginning to appear, such as EditorX, hoping an open-source equivalent will arrive soon.

Follow the development of the JS Svelte framework. It has an ultra simple syntax, very close to native Web technologies (HTML, CSS, JS). It has many pre-integrated features (store management, animations, etc.), rather than relying on the installation of third-party libraries. Thus, it is relatively easy to learn. It may still be a little young to use in production, but it's still a solution to keep an eye on.

If you use Design Systems, you can set up Storybook, a collaboration tool between designer and developer that centralizes the design system and its own integration. It is compatible with the majority of Front Frameworks, including Svelte. If you have designers on your team who know how to integrate HTML/CSS, they can directly create their components in Storybook in a neutral development environment, and developers can reuse them directly in their application.

If you're doing interactive experiments with WebGL, take a look at A-Frame, a Three.js-derived framework for making web apps in AR, VR, and 3D. It has a visual scene editor and is based on an Entity Component system, like Unity. I have not been able to test it, the approach seems very interesting to me.

Thanks for reading.

Thanks

I would like to thank everyone who contributed to the writing of this thesis.

Chloé Vigneau, my tutor who advised me throughout the writing of this thesis and whom I was able to interview on the issues surrounding her job as a designer of serious games.

Florine Fouquart who agreed to answer my interview about her career and her job as a technical artist.

Louis-Jean Teitelbaum, the pedagogical coordinator of the DMII2 training, who set up an environment conducive to the writing of this dissertation and who knew how to re-motivate the troops when necessary.

Rémy Bonté-Duval with whom I spent hours discussing our respective memory topics and hurting our brains.

Sources

 The sources were proofread and verified on 02/02/2021

1.  Mattias Petter Johansson, UML, Cucumber and modeling reality, 2017
2. Guillaume Loup, Sébastien George, Iza Marfisi-Schottman, Audrey Serna. A Visual Programming Tool to Design Mixed and Virtual Reality Interactions. International Journal of Virtual Reality, IPI Press, 2018, 18 (02), pp.19-29. ffhal-01900503f
3. Shivam, Programming Paradigms, 2020
4. Kevin Lozano, Webflow from a developer perspective, 2020
5. Margaret M. Burnett and Christopher Scaffidi, The Encyclopedia of Human-Computer Interaction, 2nd Ed, Interaction Design Foundation, Chapter 10 - End-User Development
6. Alexandre Soubrier, The best prototyping tool. Ever. , 2015
7. Rob Ford, The Industry - Thoughts on Flash, The FWA, 2011
8. Rob Ford, Flash is dead - Long Live Flash, The FWA, 2014
9. Henry Lieberman, Fabio Paternó, Markus Klann, et Volker Wulf, End User Developement  : An Emerging Paradigm, 2006 
10. Taylor Palmer, 2020 Survey Tools Survey Results, Uxtools.co, 2020
11. Chris' Klippel, Here is the evolution of the video game industry between 1970 and 2020, Presse Citron, 2020
12. Ben reeves, How Flash Games Changed Video Game History, Gameinformer, 2018

Annexes

All the interview are translated from french

Excerpts from the interview with Florine Fouquart

Can you introduce yourself?

My name is Florine Fouquard. I studied general 3D where I learned to do modeling, texturing, etc. But also code, including PYTHON, C++ and C# on Unity. When I left school, I was a bit of a freelancer.

I did some VR stuff on Unity and small prototyping projects, so I did a lot of C# and also shaders on Unity, so I kinda got into that language there and then I was during a year and a half Python developer on Maya and Blender in a render farm box where I was somewhat in charge of my own pole.

It's true that I didn't necessarily need to communicate a lot with artists or anything. The artists were our clients and so all I had to provide them in terms of communication was help. It was customer service, in the sense that sometimes he would send a render to us. Of the 150 machines, only 50 managed to render correctly. And most of the time, I had to figure out if the fault was on the client side or not.

[...] I had this task to explain to him where that blocked. It is also that, reassures the customer, to know what happened. But suddenly, if I didn't necessarily have to talk to him about code, I had to talk to him about the technique inherent in the rendering engine he was using. It was pre-calculated, it wasn't a video game.

When you say technical what exactly are you talking about?

For example, I had to explain why such and such a machine had taken a long time. Well, it's because he returned that bucket. And on this bucket there is where you have your glass material with 15 light bounces in your root pass. Do you see stuff, stuff a bit like that? [...] But suddenly, I did not go into the details of the code except with one of my colleagues who was quite good in architecture. We had a bit of discussion about how to properly organize object programming, whether the plugin is maintainable or things like that. But just. But he was someone who knew what he was talking about.

What did you do after this experience?

Then I was a professor in college, so I had to give lessons to people in computer programming. C# programming lessons on Unity to people who had never written a single line of code. That was quite a challenge that I didn't necessarily take up very well. The first time, I think I took it a little violently, but at the same time, my very first coding lessons were C. That dated back eight years ago already.

I made them exercises that were a little too complicated. In fact, I started with an idea. Surely a bit silly. I don't know, but from then on, of the two somewhat complicated exercises that forced them to search the Internet, to copy and paste code on the Internet without understanding it and the course after, it was good. Bah, suddenly, you did not understand what you did. Well, I will explain to you what you have done because in the professional world. Of course you can copy copy paste code on Stack Overflow, but you have to understand to be able to directly to your hierarchy.

[...] When I returned to Paris and got the job at DONTNOD as a technical artist, I was also contacted by another school called Georges Méliès. And they have a video game section which is quite recent. I was asked once again to do an introduction to programming, so there I was given a bit more freedom. And as I had already broken my teeth a little the first time, I made them leave on Processing and suddenly, on a visual application a bit generative art which is very quickly visible. And we started extremely slowly. I think, and it's a little better structured, so I think it went well.

Do you think that these difficulties come from the fact that non-developers are not used like developers to looking for answers in documentation, on the internet, etc?

Yes, I'll join you on the side. So, not except if there are really upheavals in the way objects are produced in modeling, for example, from one software to another. Once you're there practiced, this time, it's rare that you still need to go see a tutorial after 5 years of experience or stuff like that, while a programming language is constantly evolving. And it's capable of doing so many things at once. That when you go to look into a problem, you are not going to use the same resources as when you come across another. You can very well look into a problem for 2 years and 2 years after needing to go and see another part of C++. Then even C++, me, I learned that last year, there are a number of versions. It's scary, what.

As a technical artist, what exactly do you do? What's your typical day like?

So, a typical day, there really isn't one in the life of a technical artist, because it's very cross-disciplinary.

And so, suddenly, we are led to do application R&D. We're going to say about different subjects that affect the production pipeline of a video game, but our main role is to act as the interface between the artists and the Engine programmers in order, on the one hand, to give the artists all the necessary for them to apply the D.A. And at the same time that these tools simplify their life, but also simplify the life of the engine by paying attention to quality in technical terms and in terms of performance for the machine. Fulfill both artistic quality and technical quality.

What are the interactions you have with your colleagues?

There is this confidence that you have to succeed in building to correctly define your position within the project to know when you are called upon. There's also this thing of succeeding in understanding artists' requests because sometimes they'll come up with solutions without completely talking about the problem, whereas it's up to the cards to know which solution to apply, to which problem. Often the problem is a bit technical. So sometimes they will come. They will say to you: "Ah, we would like to do this, this, this, this". It seems to come out of nowhere, but for them it makes a lot of sense. But it's just that they thought of a solution, so they tell you the solution they thought of rather than the problem, whereas that is the problem. It is easier to adjust than the solutions it offers. So there is also enough communication to make it explicit. On the Engine side, there are few negotiations, sometimes because they are very busy people. So to say yes to them, but that, for artists, is essential. Yes, but there, the performances are too bad, but at the same time, it improves phew.

So you make tools?

If we can consider the materials as tools, yes. To my great regret I made them, in shader graph, I would clearly prefer to code them.

Why do you prefer to code? What are your arguments for and against visual scripting?

For the Shader Graph? Inevitably, the argument that I have in mind first and foremost is accessibility. It's very accessible, I think for accessibility, it's great. There is a system that is still quite easy to understand. But suddenly, we always come back to the same problem as when we want to make it easy to use. It's that we made it complicated behind. I don't know if it's very clear, but basically, when we, when we, when we want a user friendly design. Often, what is put in place upstream for that is to say the part that is hidden from the use of a non-initiated, it’s dantean. And I have a problem with that. In the sense that if we often let the artists tamper with the shader graphs because it looks easy, I think we would end up with shader graphs that have double the instructions and that would not really run in real time. Because, casually, after a while, a shader, you have to think about it. It doesn't just have to make the coffee (it has to be well done). I must not have useless operations that are done at runtime and above all, after a while, there is a mathematical logic to have when doing shader. There are mathematical ways of doing things that are more optimized than what an artist might come up with just having fun connecting boxes together. And afterwards, it's very. It's probably very personal too because I have a practice of writing code. So obviously I have another point of view on the matter. But don't know, me, when I do a Shedleur. Make a Fract of an absolute value of a sine of , well it's a line whereas in nodal it's 5 different nodes.

Interview with Chloé Vigneau

Can you explain what your job is in a few words?

Difficult in a few words ;)

I created my own agency in which I occupy the functions of "digital project manager" and "serious game designer". So I do management on website / application creation projects and also I design and produce serious games (from game design to development).

I am also a teacher in serious game design in several universities and in video game creation in high schools.

And I'm doing a thesis on the creation of a video game engine dedicated to schools with the École de Polytechnique.

What is your relationship to visual scripting and similar tools?

In my job as a digital project manager, I use wireflow type tools in addition to my functional specifications document to communicate with my technical teams.

In my serious game design job, I use visual scripting tools to produce educational games for my clients. For standard projects, I don't need developers thanks to the use of these tools.

In my classes, I use tools to introduce students to programming (game engine in visual scripting, nodal tool).

And I intend to use this type of tool to prototype for my thesis

Can you tell a bad experience on a project?

One of my bad experiences is a big project managed for an automotive client. The objective of the project was to create an educational game to train the group's employees in the principle of business management. I had to create a management game pushed on a visual scripting tool (at the time I was an employee, I didn't have the choice of the production tool). The game design of this game included complex notions: time management, inventory management, management of modes of transport, animation of graphic assets, problem of balancing difficulty, etc. In short, all the elements of a "real" video game.

After 3 months of development on the visual scripting tool I managed to implement the design system but I encountered 3 problems:

• management of asset animations
• UI management
• the real-time calculation limits of the tool: the design system being very complex, I was starting to have too many variables to modify in the back office of the tool, therefore permanent crashes

After 3 months of development, I asked for an opinion from the lead developer of the tool who advised me to abandon the development of the project and go back to a game engine. So we redid everything under Unity.

Result: 3 months of wasted time and budget, an awareness of the limits of the visual scripting tool which caused a big shock internally in the company, an enormous risk of "throwing everything and redo" in view of the project deadlines.

It is therefore a "failure" for the visual scripting tool in this context because we all realized that it did not replace a real game engine and that we had to "choose the right tool for the right project"

How do you think you could have avoided this situation?

Companies that sell "game factories" have a product logic so they will try to develop all the projects sold on their tools. But sometimes you have to take more time when designing the game design to choose the right tool that will meet the need. The "game factories" are generally created to allow very profitable games to be made because without a developer. But in the context of an ambitious project with a complex game design, the tool does not do everything and certainly does not replace the skills and vision of a developer.

Do you think the tool could have been improved to avoid this situation?

The gap between the tool and the game engine was too great for improvements to be developed over the time of the project. And especially it was not the objective of the company which develops this software. The lead dev also preferred to recode the game directly under Unity rather than spend the same time improving the tool to allow me to resume my development.

What do you find good in visual scripting?

I find that visual scripting (or no code or game factories, in short all these terms) is a very good springboard for introducing young people and adults to the profession of programming. This allows for example to understand concepts such as variables, loops, conditions, etc. without having to learn to code first. So in a pedagogical context it's perfect.

In a professional context, I use it to prototype and therefore facilitate communication with my technical teams or to produce simple projects myself (and there are many of them). This allows me to mobilize my developers only on complex projects that require superior development logic