4 ms·

I hit a similar roadblock for a long time, always spending time writing low level graphics utilities (which I do rather enjoy) but never getting around to writi

by foota 8y ago

I hit a similar roadblock for a long time, always spending time writing low level graphics utilities (which I do rather enjoy) but never getting around to writing a game. If you find yourself in a similar situation and want to get around it I would suggest trying unity, which I was hesitant to do since: 1. It felt like giving up and cheating, and 2. I don't like how unity interfaces with the developer, since I mostly wanted to implement games without using the world editor that seems to be the focus of unity. But I've enjoyed using it so far and would suggest giving it a shot.

pixelbash 8y ago
Re the second point did you manage to get around this? Played with it a bit and it felt almost like flash back in the day where you could eschew the timeline and do everything programmatically. In the end ran into a problem where I wanted to move the universe around the player and couldn’t get the particle engine to cope..
- tlarkworthy 8y ago
  You can do anything programmatically in unity. I think professionals tend towards this. You use the world editor only for artistic expression, the spatial layout and tuning etc. where previewing layout really saves time. For very specific effects like universe turning, you have to do a lot of code work in a niche area, but it's still quicker than building a particle engine from scratch. Sometimes you can cheat the effect in shaders or camera tranform manipulation. Or skip the effect altogether if the volume of custom code is not worth it and you are prioritizing shipping. Ask yourself, does it make or break your game?
  - foota 8y ago
    What in the world is universe turning?
    - tlarkworthy 8y ago
      The OP roadblock (turning the particle system).
- scraft 8y ago
  I started our my games development career as a low level programmer and moved to a lead programmer in the technology department and then founded a games studio where we wrote our own engine and released several games. My role meant I had to make the correct business decisions using my technological knowledge and as much as writing engines and technology ran through my blood, the right answer was to switch to Unity. The man cost of constantly writing all the technology we need and then maintain it was too great compared to the ever diminishing wins we got from it. One scary part of this decision was then hiring Unity programmers and initially having these new hires knowing more about Unity than I did. I needed to make calls about what is possible, time frames, performance, meeting client requirements etc without being an expert of the most important part of our development process. Luckily we made the right hires and it didn't take so long until I had been converted to the Unity mindset. Initially I would always be saying "oh well I would normally tackle this in this way" and wanted to coerce Unity to work in a familiar way. But overtime this disappeared and I became increasingly interested in working out the best way to achieve things in the "Unity way" which ultimately returns much greater dividends. The first game we released, called Bloody Zombies came out last year on Steam, Oculus, Xbox One, PS4 and Nintendo Switch. It can be played in VR (on supporting platforms) and non VR. It is multiplayer, both in the sense of multiple people on one machine (you can do things like 1 VR player and 3 TV players or 4 TV players) but also online multiplayer (where you can do one player per machine or any combinations say one tv player on one machine playing with 1 VR players and 2 tv players on another machine). VR meant we had to maintain a constant frame rate (60 or 90 depending on platforms). We used stereoscopic rendering, offloaded graphics work to a special job system. We used custom shaders (the game is like a graphical novel so outline shaded characters) we have spherical fog, lightmaps, FXAA, colour post processing etc. Online multiplayer meant a packet system, ability to establish connections, matchmake, a system for making parts of the game world communicate, handling so many error cases, etc. For variety of platforms meant lots of variety on the rendering, controller input etc. For Switch it meant the ability to play on Switches close to each other on a different protocol to online multiplayer. I shudder to think how much time and effort this would have been without Unity. I suspect we would have needed several new hires working on platform specific tech, full time network engineers, at least one full time graphics dev, at least one full time audio dev, one full time physics dev, the list goes on. Instead we had 3 programmers (which includes me where my time was heavily comprised being a founder/MD/Tech Director/coffee maker) and whilst the other programmers were very good they had both only graduated a few years prior. Did Unity solve everything? Absolutely not. We hit loads of huge problems with Unity. Without help of their engineers some problems we would never have been able to solve. We helped Unity fix lots of issues at their end. We found issues that could have been solved trivially without Unity. We felt the strain of waiting days for an answer to a mission critical Unity issue. But in the grand scheme, the pain was less than 10% of what we would have experienced doing it with our own engine. My big worry was not doing "tech" anymore, but that simply isn't true. But instead of having to write loads of architecture and code to even be able to write the "real" tech, instead you can write the more interesting stuff. For shaders you just write the shaders, not the system for passing in shader constants and setting up vertex streams. Post effects is similar. Coming from a strong engine/Tech background has been massively helpful, whilst unity trained hires are amazing it has been really useful for our studio for me to be able to get into the lower level to add feature, fix stuff, debug stuff, etc.
- foota 8y ago
  Perhaps I'm missing something here, but you should just need to move the player in the opposite direction of the world's desired movement? No game system I'm aware does it the other way around, as it requires changing all the other models transforms. But yes, I am dealing with the interface, primarily by ignoring it. I'm still trying to get down the right way to organize my code, but it's making sense.
  - gmueckl 8y ago
    Once your game world size crosses a specific threshold, you need to move the world instead of the player because numerical accuracy starts to become troublesome (most engine code runs with floats, which gives about 6 decimal digits of precision). The first engine that I am aware of that did that was that of Dungeon Siege. There's an excellent post mortem around about the challenges of this approach.

by foota 8y ago

pixelbash 8y ago

Re the second point did you manage to get around this? Played with it a bit and it felt almost like flash back in the day where you could eschew the timeline and do everything programmatically. In the end ran into a problem where I wanted to move the universe around the player and couldn’t get the particle engine to cope..

tlarkworthy 8y ago
You can do anything programmatically in unity. I think professionals tend towards this. You use the world editor only for artistic expression, the spatial layout and tuning etc. where previewing layout really saves time. For very specific effects like universe turning, you have to do a lot of code work in a niche area, but it's still quicker than building a particle engine from scratch. Sometimes you can cheat the effect in shaders or camera tranform manipulation. Or skip the effect altogether if the volume of custom code is not worth it and you are prioritizing shipping. Ask yourself, does it make or break your game?
- foota 8y ago
  What in the world is universe turning?
  - tlarkworthy 8y ago
    The OP roadblock (turning the particle system).
scraft 8y ago
I started our my games development career as a low level programmer and moved to a lead programmer in the technology department and then founded a games studio where we wrote our own engine and released several games. My role meant I had to make the correct business decisions using my technological knowledge and as much as writing engines and technology ran through my blood, the right answer was to switch to Unity. The man cost of constantly writing all the technology we need and then maintain it was too great compared to the ever diminishing wins we got from it. One scary part of this decision was then hiring Unity programmers and initially having these new hires knowing more about Unity than I did. I needed to make calls about what is possible, time frames, performance, meeting client requirements etc without being an expert of the most important part of our development process. Luckily we made the right hires and it didn't take so long until I had been converted to the Unity mindset. Initially I would always be saying "oh well I would normally tackle this in this way" and wanted to coerce Unity to work in a familiar way. But overtime this disappeared and I became increasingly interested in working out the best way to achieve things in the "Unity way" which ultimately returns much greater dividends. The first game we released, called Bloody Zombies came out last year on Steam, Oculus, Xbox One, PS4 and Nintendo Switch. It can be played in VR (on supporting platforms) and non VR. It is multiplayer, both in the sense of multiple people on one machine (you can do things like 1 VR player and 3 TV players or 4 TV players) but also online multiplayer (where you can do one player per machine or any combinations say one tv player on one machine playing with 1 VR players and 2 tv players on another machine). VR meant we had to maintain a constant frame rate (60 or 90 depending on platforms). We used stereoscopic rendering, offloaded graphics work to a special job system. We used custom shaders (the game is like a graphical novel so outline shaded characters) we have spherical fog, lightmaps, FXAA, colour post processing etc. Online multiplayer meant a packet system, ability to establish connections, matchmake, a system for making parts of the game world communicate, handling so many error cases, etc. For variety of platforms meant lots of variety on the rendering, controller input etc. For Switch it meant the ability to play on Switches close to each other on a different protocol to online multiplayer. I shudder to think how much time and effort this would have been without Unity. I suspect we would have needed several new hires working on platform specific tech, full time network engineers, at least one full time graphics dev, at least one full time audio dev, one full time physics dev, the list goes on. Instead we had 3 programmers (which includes me where my time was heavily comprised being a founder/MD/Tech Director/coffee maker) and whilst the other programmers were very good they had both only graduated a few years prior. Did Unity solve everything? Absolutely not. We hit loads of huge problems with Unity. Without help of their engineers some problems we would never have been able to solve. We helped Unity fix lots of issues at their end. We found issues that could have been solved trivially without Unity. We felt the strain of waiting days for an answer to a mission critical Unity issue. But in the grand scheme, the pain was less than 10% of what we would have experienced doing it with our own engine. My big worry was not doing "tech" anymore, but that simply isn't true. But instead of having to write loads of architecture and code to even be able to write the "real" tech, instead you can write the more interesting stuff. For shaders you just write the shaders, not the system for passing in shader constants and setting up vertex streams. Post effects is similar. Coming from a strong engine/Tech background has been massively helpful, whilst unity trained hires are amazing it has been really useful for our studio for me to be able to get into the lower level to add feature, fix stuff, debug stuff, etc.
foota 8y ago
Perhaps I'm missing something here, but you should just need to move the player in the opposite direction of the world's desired movement? No game system I'm aware does it the other way around, as it requires changing all the other models transforms. But yes, I am dealing with the interface, primarily by ignoring it. I'm still trying to get down the right way to organize my code, but it's making sense.
- gmueckl 8y ago
  Once your game world size crosses a specific threshold, you need to move the world instead of the player because numerical accuracy starts to become troublesome (most engine code runs with floats, which gives about 6 decimal digits of precision). The first engine that I am aware of that did that was that of Dungeon Siege. There's an excellent post mortem around about the challenges of this approach.