Programming for PlayStation: How to develop tools for narrative
Guillermo Izard, Principal Tools Programmer at PlayStation London Studio, shares his philosophy on narrative tool programming and development.
Do you mind sharing your name and last position?
GI: I am Guillermo Izard, Principal Tools Programmer at PlayStation London Studio. I am an industry veteran with almost two decades of experience as a game developer and have released a lot of games during this time. I have been with PlayStation for more than ten years.
At London Studio we use our own in-house proprietary game engine. I have been heavily involved with our Game Editor, very similar feature-wise with Unreal or Unity. Also, as part of my job, I usually have to evaluate and investigate 3rd party tools and solutions for our projects, as was the case most recently when I had to investigate solutions for the narrative design team at our studio.
What are the common features that narrative designers ask for in a tool?
GI: As with any front-facing software, UX and stability are very important. Having a clean and intuitive interface that is easy to use and does what it says on the tin is of critical importance.
Specifically, narrative designers might need to implement into the game the following series of elements:
Ideally, they should be empowered to implement all these elements themselves with little or no help from the engineering team so that they can iterate continuously and improve all aspects of the story and gameplay. Fast iteration is the key to making an excellent game.
Do you think Arcweave fulfils these needs? Where does it have gaps?
GI: Without a doubt, Arcweave does have these features. However, finding gaps is more difficult. Usually you find gaps by working on a project from beginning to end, and because of that reason, gaps may vary project to project.
How important is developing narrative tools which are non-programmer friendly? Do writers need a deep knowledge of programming?
GI: In my opinion, it is very important to remove artificial barriers to entry for every kind of tool and software. So, even though having a deep knowledge of programming will always be an asset, it shouldn't be a requirement. Of course, it all depends on the level of control you want to have over the game.
However, for the majority of cases, the kind of control and branching logic that narrative designers demand is possible to be expressed by visual tools and/or simple scripting statements that everybody can learn. So, designers can focus on doing what they do best and not get tangled in the technical side of things, fighting problems that shouldn't be their concern.
Do you look for tools to fulfil a specific niche (e.g. narrative), or do you value tools which have multidisciplinary support?
GI: Tools with a clear focus on what problem they are trying to solve are usually the best ones but it is absolutely critical that they can be integrated with other tools or platforms as easily as possible. Ideally they can be used in a stand-alone or library/API format so that they can be embedded into other software in case you want a more homogenous UI.
"Tools with a clear focus on what problem they are trying to solve are usually the best ones." Are there any tools that come to mind as a good example?
GI: Tools, like any software, are initially written with a clear philosophy about how they solve a problem, at least initially. But, over time they might suffer from feature creep, usually coming from growing requirements from users or customers, or just wanting to make the product more "complete" or "feature rich".
Through this process , it is sometimes the case that the software becomes bloated, the UX suffers, and the philosophy and initial simplicity gets lost. I've seen so many cases of this playing out. I don't want to give names but examples of bug tracking software or video editing tools come to mind.
You mentioned the importance of integration. Why is it so crucial in a tool?
GI: Integration is absolutely critical. No matter how much the users might love the tool, if the integration of their work in the game and the rest of pipeline (localisation, production, etc.) fails, then the whole thing is worthless. Also, you want to see that the team behind the tool thinks about the back-end side of things and not only the front-end.
Recommended by LinkedIn
Are there any major differences between developing tools for indie/AA and developing tools for AAA?
GI: Not really. With a larger budget you might go the extra mile in terms of polish, whereas in the other case you will have to go for a more "no frills" approach. But the principles of decision-making are still the same: have the best interest of the user in mind and make the most of the resources you have.
When performing cost-benefit analysis, what are the key considerations when evaluating a tool?
GI: Firstly, you have to evaluate what the cost is of not having a tool at all. What would the workflow be in that case? Would the designer have to write code? Would the designer have to send the written design to the coder and then wait for them to implement it and evaluate if everything is correct? That is a very inefficient way of working. It might have no cost in terms of money but it does have a massive cost in terms of time and opportunity.
The second alternative would be to build your own tool. In this case, you would have to consider both your engineering and opportunity costs. Sometimes this option can be the best if your requirements or "problem space" is very unique and not well served by a 3rd party solution. In general, game developers have to carefully choose their battles if they want to be successful; they have to focus on the area where they think they have an edge.
What advice would you give to smaller developers for identifying value in tools?
GI: You need to carefully consider the alternatives and choose your battles wisely. Smaller developers need to be even more focused on how they spend their time. Consider if it is worth it to invest money in software that makes your team more productive and saves you time and headaches.
What areas in making a game are best for outsourcing tools and which are better to try and DIY in-engine?
GI: It is difficult to generalise. Potentially any area can benefit from creating your own tool or licensing a 3rd party one; it all depends on the specific requirements of your project, skillset, and timeframe. As mentioned before, it is all about what areas you think your studio or team has an edge in, where there is an opportunity to stand apart from the rest.
How do you take into account the preferences of designers?
GI: Some designers are more comfortable with visual tools and are happy to manipulate graphs and nodes and wires and all sorts of rich media. However, there are also others who might find that distracting and prefer the "text editor experience", finding that environment more productive. There is not a right or wrong approach there.
Often, you will even find that the same designer might prefer being able to choose what approach to use depending on the task at hand. For example, they might find that a branching tool like Arcweave is a really useful representation for the narrative of a game, but they then prefer to resort to a text document when they are thinking about the sequential logic of events.
As a developer, I always try to involve as many stakeholders as possible in these conversations in order to have a wide view of the different preferences and —when possible— cater to all audiences. Even if you are resource limited and can’t provide a perfect solution, you should always listen to all perspectives and try to come up with a tool that helps unlock productivity for everyone.
How far did you get in your investigation of tools? Are there any findings you can share?
GI: After a comparative analysis, I started working on a test project where you try to mock up a series of scenarios, user stories and such, that you might encounter during development. At this stage you try to involve as many stakeholders as possible to gather their feedback. During that process, you try your best to de-risk the production by addressing concerns or raising new ones that will require further investigation.
A common concern in narrative is deciding what the "source of truth" is between assets and their stages (text, voice-overs, textures, localisation, performance) and how to sync all the inter-related data to make sure there are not parts that get stale and become a production nightmare.
What are the strengths and weaknesses of a cloud-based/API tool versus stand-alone?
GI: The pros are that it is accessible from everywhere as long as you have a connection to the internet. Also, you usually you get a REST/API which is very easy to interface with. The cons are that it is obviously not accessible without internet, so if someone is disconnected, they can’t do any work. Also, there are potential security concerns which AAA companies are very strict about, such as potential leaks. Another issue is with not owning the data — what happens if the server gets shut down, etc.
Finally, do you have any advice for programmers who want to get started in the games industry?
GI: Build a portfolio of interesting projects as a showcase of your skills, ideally with video, screenshots, and code available. Passion for games is great but passion for gaming alone will not cut it. We want to see a passion for creating games, which is a different skillset. We usually want to see people have learnt game engines like Unity , Unreal Engine , Godot Engine , there are a lot of options.
For gameplay programmers, I would look for a small but complete game with polished mechanics. For other tech roles, I'd look for projects that showcase that specific field in more detail (i.e Graphics, AI, Multiplayer). At the same time, it’s normal for a young person to not know what specialisation they want to go into; no matter what, they should make sure their projects showcase passion and skills. I think the most important thing is just having something in your portfolio to showcase.
Thank you to Guillermo Izard for taking the time to answer all of our questions and for his insight. Following the unfortunate closure of PlayStation London Studio , where Guillermo had been working for almost 14 years, he is available to new work opportunities within or outside of the games industry. Please do not hesitate to connect with him if you would like to get in contact.