EnglishGermanFrenchRussianItalianSpanishChineseBrazilianJapaneseKorean
Developed by    
EGOSOFT GmbH Logo

Official EGOSOFT Facebook Page!Official EGOSOFT Twitter - Follow us!Official EGOSOFT Youtube ChannelOfficial EGOSOFT Twitch Channel
logout
0
Notícias
Atual
Arquivo
2026 Julho
2026 Junho
2026 Mai
2026 Abril
2026 Março
2026 Fevereiro
2026 Janeiro
2025 Dezembro
2025 Novembro
2025 Outubro
2025 Setembro
2025 Agosto
2025 Julho
Jogos
Comunidade
Suporte
Downloads
Empresa
Loja


Buy X-Series online
13.Jul.26 Interview with Matthias: 18 Years of X  (2 Comentários)
In our latest episode of Inside Egosoft, Joey sits down with Matthias, one of Egosoft's longest-serving developers, to discuss almost two decades of working on the X Universe.


Though his title could be described as “gameplay programmer,” Matthias' efforts reach far beyond that role. In this conversation, we discuss topics ranging from AI flight systems and X4's design philosophy to the evolution of the game's 3D map, resource simulation, and plenty more.

Below are some highlights from our chat. You can tune in to listen to the conversation on all major Podcast platforms. Keep an eye out for another episode later this month!

Listen to the Inside Egosoft Podcast:
  • YouTube
  • Amazon
  • PocketCasts
  • iHeartRadio
  • Wearing Many Hats

    Joey: You're generally described as a gameplay programmer, but I think people hear that and picture someone working in one very specific area. How would you describe your role in a way that better reflects what you actually do?

    Matthias: To be honest, I'm not even sure that "gameplay programmer" really encompasses what I do. It's the label that fits best, but I do a lot of things that aren't strictly gameplay.

    I often oversee design implementation, so it's useful to have a broad overview of the gameplay systems and to have worked on many of them. But I also spend a lot of time on lower-level supporting systems that players might never directly notice.

    Joey: You've touched on AI, physics, the map system and so many other areas over the years. How did your role expand into all those different systems?

    Matthias: It happened very gradually. I didn't join Egosoft thinking, "I want to work on everything."

    When I started more than eighteen years ago, I had just come out of university. I didn't even have a programming degree—I studied physics. That involved a little programming, but it's nothing like game development. The two are so different that they're barely comparable.

    I joined as an intern, and in the beginning I was really trying to figure out what I was actually good at and where I could contribute. I was interested in a lot of different areas, so whenever someone asked, "Would you like to work on this?" I usually said yes. Quite often I even volunteered myself. If something sounded interesting, I'd ask if I could try working on it.

    Over time, that naturally led to me becoming involved in more and more parts of the game.

    Realism in Gameplay

    Joey: You mentioned studying physics. Does understanding real-world physics ever make it frustrating to work on a game where things obviously have to behave differently?

    Matthias: Laughs. Yes, absolutely. There are plenty of things in X4 that are completely unrealistic, but we do them intentionally because otherwise you'd practically need a degree in physics just to fly a spaceship.

    Our flight model, for example, behaves much more like flying an airplane than flying a real spacecraft. We have top speeds, ships bank into turns—it isn't realistic spaceflight at all. But that's simply what this kind of game is. Even people who really enjoy realistic physics generally accept that compromise.

    There are a few games that go much further with realism and do it very well, like Kerbal Space Program. But realism is the entire focus of that game.

    Variety Keeps Things Interesting

    Joey: You've worked across so many different systems over the years. Is that something you've naturally been pulled toward, or do you actively enjoy having that much variety instead of specializing in one area?

    Matthias: I really enjoy the variety. Not only do I like working on different gameplay systems, I also enjoy switching between completely different kinds of work. Programming is still what I spend more than ninety percent of my time doing, but I'm also regularly involved in game design discussions, helping shape ideas before they're implemented.

    I've done a little writing in the past as well—not a huge amount—but enough to really enjoy it. I even ended up doing a small amount of voice acting once.

    Joey: Really?

    Matthias: It was kind of a funny story. While we were working on the Timelines DLC, there was a character who had become trapped aboard an alien ship and had a few desperate voice lines. At the end of development, I happened to catch a really bad cold. I was called and asked if I'd be willing to record the lines because my voice already sounded rough enough for the character. The idea was that we’d process the recordings afterwards. I recorded four or five lines with my cold, and... they ended up using them exactly as they were.

    So now I'm Kyle Brennan. In German.

    "All Games Are Impossible"

    Joey: From the outside, X4 almost feels impossible to make. I honestly don't know how you all manage it sometimes.

    Matthias: Laughs. Low-key, all games are impossible to make. I've talked to enough developers that you eventually realise every game has its own impossible problems. You look at another game and think, "I'd love to work on something simple like that." Then you meet those developers, they explain what's happening under the hood, and suddenly you realise they have an entirely different set of incredibly difficult problems. Developers always fill the complexity up to their capacity. Even if we were making a much simpler game, we'd simply put our effort into different areas.

    Building X4's 3D Map

    Joey: You've also written a lot of the code behind X4's 3D map. When you first started working on it, what were your core goals? Were there any design pillars you kept coming back to?

    Matthias: The map actually dates back to the development of X Rebirth. Early in development, we had a much more abstract navigation map. It was essentially a collection of nodes connected by lines, almost like looking at a subway map. You could see which highway connected to which zone, but it wasn't really a representation of the universe itself. It worked, but it wasn't especially intuitive to navigate, and every time something changed in the game world, someone had to manually update that representation.

    So we started asking ourselves whether there might be a more dynamic solution. During one meeting, I suggested that instead of creating a separate map, we simply render the actual game world as a miniature hologram. I was picturing something similar to the tactical displays in Battlestar Galactica—a holographic representation of space that reflected the universe itself. Most people were fairly skeptical. The response was essentially, "I don't think that's going to work." So I went home that evening and decided to try it anyway. Within about an hour, I had a prototype running. I could already see my current sector, the highways, stations, and ships moving around in real time. From there, the idea gradually evolved into the map players know today.

    Originally, it wasn't the fully interactive 3D interface we have now. At the time, we still hadn't solved how players would comfortably interact with something like that from inside a cockpit. The biggest evolution came with X4, where we introduced seamless zooming. Instead of jumping between separate map layers, you can smoothly zoom from a single station all the way out to the entire universe and back again without changing modes. Early on, we also decided to represent sectors as hexagons. They're futuristic. Science fiction likes hexagons. So... we used hexagons.

    Designing for Readability

    Joey: Earlier, we talked about readability in relation to ship movement. The map feels like another place where that balance becomes important. It needs to accurately represent the simulation, but it also has to remain understandable for the player. How do you balance those goals?

    Matthias: Mostly through constant iteration. We build something, test it, figure out what works and what doesn't, then adjust it. We're still doing that today. Sometimes we'll discover that once you zoom out far enough, there's simply too much information being displayed. Not only does that become visually overwhelming, it can even begin affecting performance. So we'll ask ourselves whether ship icons should start fading out slightly earlier, or whether certain information only needs to appear at closer zoom levels.

    Generally, we've tended to err on the side of showing players more information rather than less. Interestingly, whenever we've reduced visual clutter at particular zoom levels, we've almost never received negative feedback. Most of those changes simply make the map easier to read.

    A Living Economy

    Joey: By the time this episode goes live, 9.00 should be live, so we can probably talk about some of the new systems. One of the biggest changes, at least from my perspective, is the overhaul to resource distribution and depletion. What prompted that?

    Matthias: Recently we've placed an even greater emphasis on performance, memory usage, and save-game size than we already had before. This new resource system had actually been proposed several years ago, primarily because it opened up some interesting game design opportunities. But alongside those design improvements, it also brought a significant technical advantage. The amount of resource data we now need to store in save files is dramatically smaller.

    In some long-running saves under the previous system, the resource data alone could account for roughly twenty percent of the entire save file. That's a huge amount of data. Reducing that has made a very noticeable difference.

    Creating Stories Through Simulation

    Joey: Resources are really the foundation of X4's entire economy. Where do you even begin when redesigning something that fundamental?

    Matthias: Laughs. Very carefully. The first step is always deciding what your design goals actually are. One of the things I've wanted for quite a long time is to create natural peaks and valleys within the mining economy.

    Those fluctuations can then ripple outward through the rest of the game's economic simulation. That's interesting because fluctuations create opportunities. If supply and demand remain perfectly stable, prices eventually settle around an average value and trade becomes predictable. There's very little room for players to recognize an opportunity and capitalize on it, but if resources fluctuate naturally, the economy begins creating those opportunities on its own.

    Of course, there's another side to that: we still need to make sure the economy remains healthy overall. The universe can't simply run out of resources. Factions still need enough materials over time to keep building ships and maintaining their economies. So it's always about finding the balance between meaningful fluctuations and long-term stability. Another important goal was rewarding players who actively explore. Someone who's willing to manually prospect for resources should be able to find richer deposits—or rarer materials like Nividium—and gain an advantage from doing so.

    Creating Timelines

    Joey: You also played a major role in creating Timelines. How did that project originally come about?

    Matthias: I was actually the person who first pitched the idea. Interestingly enough, the inspiration came from a science-fiction novel called The Gone World. It's a time-travel story about an approaching apocalypse. I really enjoyed it, although I wouldn't exactly call it cheerful. It's a very dark book.

    If you've read it, you'll probably recognize a few ideas that eventually found their way into Timelines—things like traveling to speculative futures and bringing people back from those futures. The original concept was quite different, though. Initially I imagined it as a standalone game built using a relatively small number of new assets. The focus would've been on replayable scenarios with modifiers. For example, you might replay a mission, but instead of fighting Xenon, you're suddenly fighting Kha'ak.Things like that.

    When I pitched the concept to Bernd, however, he was looking for a new DLC for X4 rather than a separate game. So we reworked the idea considerably. Many of the core concepts survived, but they were reshaped to fit naturally within X4 itself.

    Engineering and Design

    Joey: You've spent a lot of your career solving technical problems, but Timelines also put you into a much more creative role. Does your approach change between programming and designing?

    Matthias: Very much so. Programming usually starts with a technical plan, although sometimes I just start building something and figure it out as I go.

    Design is much more iterative. The spacesuit scenarios, for example, started as simple grey-box levels where I was just experimenting. What feels fun? What kinds of movement stay interesting? Other scenarios, like Flight of the Dragonfyre, started almost like writing a screenplay. I laid out the sequence of events first, built a rough mission structure, then gradually filled in the dialogue and gameplay over time.

    Guiding the Bigger Picture

    Joey: Working across so many different gameplay systems, has that naturally led you into more of a creative leadership role?

    Matthias: I don't know if I'd say it naturally pulls you in that direction, but working across so many different systems does give you a very broad understanding of how everything fits together.

    I'm only a real expert in a handful of those systems, but I've worked closely enough with all of them to understand what's technically possible and how different features interact. That means even when I'm not the person implementing a feature, I can often help shape the direction it's taking. Someone might come up with a really good idea that simply isn't feasible in the way they're imagining it.

    Instead of saying, "That can't be done," I can usually suggest another approach that achieves the same goal while fitting within the realities of the engine.

    Creativity Through Constraints

    Joey: Back when I was a reporter, one topic that came up surprisingly often was the idea that technical constraints can actually make people more creative. I saw exactly the same thing during my years producing music. Having limitations often forces you to come up with ideas you never would have considered otherwise.

    Matthias: Absolutely. It's the blank-canvas problem. If you sit someone down and simply tell them, "Write a story," it's surprisingly difficult to even begin. But if you tell them, "Write a story about a cat attending a Victorian ball," suddenly ideas start appearing immediately.

    Constraints give creativity direction. That was actually one of the things I really enjoyed about Timelines. Because each scenario is completely self-contained, we don't have to worry about the long-term health of the sandbox simulation. Nothing that happens inside a scenario carries permanent consequences into the wider universe. That freedom actually opened up a lot of possibilities. We could build situations that would never make sense inside the persistent sandbox while still creating interesting gameplay.

    Joey: It really lets you step away from worrying about the broader simulation and instead focus on creating a memorable experience. In the sandbox, you're always thinking about how one change might ripple throughout the entire universe. Inside Timelines, you can simply ask, "What's the most interesting scenario we can build?"

    Matthias: Exactly. Otherwise you'll carefully script a showcase battle …and then a Xenon fleet suddenly wanders through and destroys everything. Sometimes that's exactly what the sandbox does.

    Looking Back at Old Code

    Joey: You've now worked on the X series for nearly two decades. Do you ever revisit something you wrote years ago and immediately wonder why you did it that way?

    Matthias: Laughs. Only on days that end in "Y." It happens constantly. There's a quote I once heard—I don't remember the exact wording—but it was something like: "If you don't look at your old code and cringe, you haven't grown enough as a programmer."

    I think that's true, and it doesn't only apply to programming. It applies to design as well. I regularly look back at something I wrote years ago and think, "What was I even thinking?" Then I check the version history ...and of course it was me.

    Joey: I think that's true of almost any creative skill. If you never look back at your old work and see room for improvement, you're probably not progressing very much.

    Matthias: Exactly. Although it does lead to one of the most satisfying experiences a programmer can have: Deleting old, terrible code.

    Looking Ahead

    Joey: Looking ahead, are there any systems you're especially excited to continue developing?

    Matthias: We haven't spent much time on it recently, but I think there's still a lot of potential in the mass traffic system.

    Those little civilian ships flying around stations are mostly decorative at the moment. As long as they work and don't look obviously broken, they generally aren't a high priority, but I think improving that system could do a great deal for immersion.

    Having those ships behave more naturally—doing more than simply following predefined paths—would make stations feel much more alive.

    Joey: I'm a big fan of the mass traffic ships. I always enjoy seeing as many of them as possible around stations.

    Matthias: Me too. They're also important for communicating scale. You need something small to truly appreciate something large. If you only see a station by itself, your brain has very little sense of how enormous it actually is. But when you see tiny civilian ships moving around it, suddenly you have a familiar point of reference. Your brain immediately understands just how massive that station really is.

    One Feature That Feels Like His Own

    Joey: Is there one feature in X4 that feels unmistakably yours?

    Matthias: Probably spacesuit gameplay. I've always loved the contrast between the enormous scale of stations and capital ships and then suddenly experiencing everything from a human perspective.

    One of my favourite games is Hardspace: Shipbreaker. I'd love to do even more close-up spacesuit gameplay in X4 in the future.

    Joey: I actually have 100% completion in Hardspace: Shipbreaker.

    Matthias: Laughs. Me too. It's such a good game.

    Final Thoughts

    Joey: Before we wrap up, is there anything you'd like to leave listeners with?

    Matthias: Play more space games. They're good, in my opinion.

    Joey: Laughs. I think they're alright.
    posted by Gregory
    01.Jul.26 Próximas alterações nos requisitos mínimos de sistema para X4: Foundations  (0 Comentários)
    À medida que continuamos a desenvolver e expandir X4: Foundations, estamos constantemente buscando maneiras de aprimorar o motor gráfico proprietário do jogo e seu desempenho geral. Para continuar expandindo os limites do que nosso motor gráfico pode fazer, estamos nos preparando para atualizar nossa API gráfica para Vulkan 1.4 como parte de uma futura atualização. Nosso plano é fazer isso na próxima grande atualização após a versão 9.00.


    Devido a esse necessário avanço tecnológico, em breve atualizaremos os requisitos mínimos de GPU para X4: Foundations.

    Por que estamos fazendo essa mudança?
    A transição para o Vulkan 1.4 representa um marco técnico significativo para nós. Como somos uma equipe pequena, dividir nossos recursos entre o suporte para hardwares antigos e o desenvolvimento moderno tornou-se um grande fardo; continuar dando suporte a hardwares antigos exige que mantenhamos mais códigos e isso limita os recursos gráficos que podemos utilizar. Ao otimizar nosso motor gráfico para esse novo padrão, podemos trabalhar com mais eficiência e continuar a entregar melhorias técnicas para o jogo. Em outras palavras, migrar exclusivamente para o Vulkan 1.4 nos permite focar 100% no futuro do X4!

    Os novos requisitos mínimos de GPU
    Quando esta atualização planejada for lançada, os novos requisitos mínimos de placa de vídeo para executar a versão mais recente de X4: Foundations serão:

    NVIDIA GTX 1060 ou AMD RX 5300 ou equivalente (Vulkan 1.4 Support required)

    Com base nos dados recentes da Pesquisa de Hardware da Steam, estamos confiantes de que essa mudança afetará apenas uma pequena fração de nossos jogadores ativos.

    E se meu computador não atender aos novos requisitos?
    Primeiro e mais importante: se você estiver jogando em um hardware mais antigo, não perderá o acesso ao jogo. Sabemos que alguns de vocês têm explorado o universo X em hardware mais antigo e queremos garantir que possam continuar jogando. Continuaremos a fornecer acesso às versões antigas do X4 por meio do sistema de ramificação "Versões e Betas de Jogos" da Steam, como já fazemos há algum tempo.

    Como acessar uma versão antiga:
  • Clique com o botão direito do mouse em X4: Foundations na sua Biblioteca da Steam.
  • Selecione Propriedades e, em seguida, navegue até a guia Versões e Betas do Jogo.
  • Selecione a versão antiga desejada no menu suspenso.
  • A Steam fará o download da versão selecionada e você poderá jogar normalmente.
  • Após a conclusão, a Steam exibirá a versão selecionada do jogo ao lado do botão "Jogar", bem como ao lado do título "X4: Foundations" na sua lista de jogos, no lado esquerdo do cliente Steam.

    Esperamos que este aviso prévio lhe dê bastante tempo para se preparar. Somos imensamente gratos pelo seu apoio contínuo ao X4: Foundations ao longo dos anos e estamos ansiosos para mostrar o que esta nova base técnica nos permitirá fazer no futuro.
    posted by Gregory
    Community
    Users: 381159
    Logged in: 12
    Foto Mais Recente
    Foto Mais Recente
    X4: Foundations
    Details ORDER NOW Details
    X Rebirth
    Details ORDER NOW Details

    [ Disclaimer / Impressum ] | [ Privacy Policy / Datenschutz ]
    Copyright © EGOSOFT 1990-2026