8 ms·

Pretty amazing what kind of skills game development required back then. One side of me is happy that we have all these great tools today, the other is sad becau

by kayoone 11y ago

Pretty amazing what kind of skills game development required back then. One side of me is happy that we have all these great tools today, the other is sad because you hardly use this low level stuff in todays software development world. We are solving different problems today, but the level of software development skills required for a game that today could be done by a single person in Unity in a few weeks is quite impressive.

fsloth 11y ago
" the other is sad because you hardly use this low level stuff in todays software development world." I don't think there is a dichtomy. It's always about smartly leveraging available resources. The problem with modern development perhaps is then that there are these tempting high level orthodoxies that often obscure the core matter at hand. Ie. focusing on some pointless candied abstract object interface rather than focusing design efforts on data flow and the datastructures and algorithms used. The need for low level optimization has most definetly not vanished. When program data fits into local ram the bottleneck moves into cache optimization.
- feld 11y ago
  Please write this post. I love my pebble time (but really you guys need to fix some stuff in the new OS)
  - fsloth 11y ago
    Uh, sorry, did you accidentally reply to wrong message?
    - feld 11y ago
      appears so. sorry!
pjmlp 11y ago
Just try to code for mobile or embedded platforms. Yeah they might get bigger storage every year, but the reason why Google, Apple and Microsoft do talks about package size on their developer conferences is that size is number one reason for people to avoid installing apps, or to chose which one to remove. Also given how the app life cycle works on mobile platforms, big apps are being killed all the time they go into background.
- codesushi42 11y ago
  Not so sure about this. Most mobile games are developed with Unity. And what appear to be the cutting edge titles are usually using the Unreal engine. There's not much "to the metal" coding going on. Besides, most mobile games are being played by the casual crowd. Games don't need graphics that push hardware limits to sell.
  - pjmlp 11y ago
    > Most mobile games are developed with Unity. And what appear to be the cutting edge titles are usually using the Unreal engine. Any source by mobile OS that you can point to? I am quite sure there are other contenders like home grown engines, LibGDX, Marmalade, Cocos (all variants), SDL, MonoGame, DirectXTK, Project Anarchy , Apple own Scenekit and SpriteKit,... > Besides, most mobile games are being played by the casual crowd. Games don't need graphics that push hardware limits to sell. Why do you think then all major OS vendors are teaching the devs how to reduce their packages sizes? I can happily post the links of such presentations, just need to hunt them down again. Game logic + Assets + Engine Something got to give if one is required to push the size down.
    - codesushi42 11y ago
      > I am quite sure there are other contenders like home grown engines, LibGDX, Marmalade, Cocos (all variants), SDL, MonoGame, DirectXTK, Project Anarchy , Apple own Scenekit and SpriteKit,... It doesn't matter how many frameworks are out there. If you hang around the game dev scene long enough, you'll see that most small devs are using Unity, and if not that, Cocos2DX. Just head over to Gamasutra, /r/gamedev, or browse Steam & itch.io and see the # of cross platform mobile ports. Talk to devs, they are using Unity. > Why do you think then all major OS vendors are teaching the devs how to reduce their packages sizes? Reducing package size isn't really comparable to writing portions of your game in assembler. I don't consider that low level coding or pushing hardware limits.
javajosh 11y ago
There are some abstractions, like TCP sockets, that I don't think anyone would leave behind. But language abstractions like "classes" or even "functions" are certainly worth digging into. (The new lambda feature in Java 8 is an interesting case - you don't have to get into C to see the complexity there, but rather the bytecode, which is a kind of abstract sort of assembly.) I'm not terribly familiar with the scene, but there are a variety of competitions for fun and art that operate within highly constrained environments. The demoscene[0], and computer golf[1], come to mind (although ironically computer golf is in some sense has to be very high level). There's also the security scene, which is quite bit-fiddly. It's also the case that Go and particularly Rust are quite low-level system languages at their heart, so are presumably amenable to running in constrained environments. [0] https://en.wikipedia.org/wiki/Demoscene https://en.wikipedia.org/wiki/Demoscene [1] E.g. Rhoscript http://rhoscript.com/ http://rhoscript.com/
- kozak 11y ago
  Can you suggest some explanation of the lambda feature in byte code?
  - javajosh 11y ago
    Sure - read this gist from the bottom up: https://gist.github.com/javajosh/55339742aad2f1a1b881 https://gist.github.com/javajosh/55339742aad2f1a1b881 Be sure also to check out Brian Goetz's excellent "Lambdas under the covers" talk, linked in the gist.
banachtarski 11y ago
Making an (state of the art) engine is no easier. Making a game is only easier because the engines are more available now than they were in the past.
NickPollard 11y ago
A good portion of this stuff does still go on in Games Development. I don't work in games any more, but on the last title I worked on (Forza Horizon, Xbox 360), one of my colleagues engaged in a very similar exercise in order to allow data for the open world to be streamed in quick enough to deal with car (travelling at potentially 150+mph) to drive through the world without having to wait for loads, whilst streaming direct from the DVD (we weren't allowed to install to the HDD). Given that the world was open and you could drive in pretty much any direction, trying to pre-load the right tiles of the world was difficult, and seek times made it tough to bring stuff in if it wasn't all packed together. However we were almost at the limit of DVD capacity so we couldn't do much duplication of assets to lower the amount of seeking required. My colleague wrote a system that took about 8 hours overnight (running on a grid) to compute a best attempt at some kind of optimized packing. It did work though!
- agumonkey 11y ago
  Very creative. I love this kind of stories. The first interactive display, made by Sutherland IIRC, had no framebuffer (irrealistic price at that time) so the team had to stream everything to fit into the small buffer they could get. As I understand it, everything was lazy and in sync with the screen 'machinery' so there was no delay even with limited memory capacity. It felt like hardware haskell.
- Cthulhu_ 11y ago
  I was amazed myself that you can drive around at high speed through a busy city in GTA 3 on the PS3 without any noticable stutter and hardly any popups - good work there, too.
fra 11y ago
Some day I will write a blog post about the tricks we have to pull off to fit all code & assets - or get animations running at 30FPS - on Pebble. Trust me when I say this: low level development is alive and well at hardware companies.
- fragmede 11y ago
  Why wait? Blog posts serve as great marketing these days, from showing off your engineering team's technical prowess, to recruiting others who hope to participate in some really advanced problem solving. The press also helps maintain your existence in people's minds. With Google entering the market with Android Wear, and of course Apple's entry; a couple of 'this is how cool a Pebble watch is inside' would do well to not let us forget you exist!
- kayoone 11y ago
  Yeah sure, not saying it's non existent, just a lot less common. A blog post about that would certainly be very interesting :)
- vvanders 11y ago
  Yup, you see quite a few people from game dev make the transition to the embedded space when they decide that working 100hr weeks isn't their idea of fun.
- Serow225 11y ago
  Subscribed! :)
- feld 11y ago
  Please write this post. I love my pebble time (but really you guys need to fix some stuff in the new OS)
- akhilcacharya 11y ago
  I talked to a Pebble firmware engineer at Bitcamp who told me about the hoops they had to go through. Really neat stuff.
Qantourisc 11y ago
The amount of unoptimized crap they generate in a few weeks (in some cases) is quite depressive too I'm afraid. Game developers are wasting more and more CPU cycles, this of course reduces development cost. But it would be nice if they put some effort in making things run fast. And this doesn't only count for games!
- golergka 11y ago
  Making things fast is more important than making them run fast. And it's not about the cost — it's about iterations for the sake of game design.
pbo 11y ago
There is a tremendous number of hardware products and industrial systems where the processing is performed on small and cheap components (microcontrollers, digital signal processors). Of course there exist very complex components in the category of microcontrollers, some of them even offer enough resources to run Linux, but if you stick to the $1-$5 range the specs are very limited. Here are two examples, the first one costs around $3 and the second one is less than $1. http://www.ti.com/product/tms320f28027 http://www.ti.com/product/tms320f28027 http://www.atmel.com/devices/attiny85.aspx http://www.atmel.com/devices/attiny85.aspx I develop on such platforms and even though there is an interesting challenge in programming these tiny processors and optimizing CPU cycles and memory usage all the time, in the long run it becomes quite strenuous because there is only low-level stuff and I miss the expressiveness and flexibility of more abstract languages.
shultays 11y ago
I feel a little sad every time someone says "We have much higher CPU power/memory now, those things are unnecessary". Maybe they are right but I feel like this is not the path we should take
- JustSomeNobody 11y ago
  100% agree. And this goes for everything from server side, to games, to mobile to client side web. Some of my favorite web sites have gone from a 1-2 second load time to well over 6 seconds. And then they're sluggish after they load. It's sad.
  - kuschku 11y ago
    You even see this with Google. A typical Google search from 2009: "Meaning of Life: Approximately 72,000,000 Results (0,00000042 Seconds)" A typical Google search today: "Meaning of Life: Approximately 364,000,000 Results (0,62 Seconds)"
- Cthulhu_ 11y ago
  It's not, but what is true is that people can focus more on features than on hacks to squeeze the maximum performance out of their system of choice.
- jimmaswell 11y ago
  If we're free to not waste time on tons of little performance hacks anymore, why do them anyway?
kamaal 11y ago
>>the other is sad because you hardly use this low level stuff in todays software development world. During my engineering days(Circa 2005) I programmed in 8085 and our professor would give us all kinds of crazy assignments and small projects. That was the first taste of any genuine programming challenge I faced in my life. Immediately post that, programming in C felt a little boring. Recently I worked on a embedded systems project for which I relived these kind of days. I had to invent all kinds crazy tricks to work around with resource constraints. Your true creativity skills are kindled when your resources are constrained in all manners. Time or other wise. Unfortunately you can't academically recreate the same experience.
jeremiep 11y ago
We also have pretty amazing hardware today that is surprisingly underused most of the time. I've seen many Unity projects with the worst code you could imagine still run close to 60 FPS when shipped. Having an easy entry point means you're also going to get a lot of mediocre programmers using it. They seem productive in the first few weeks of the project but then quickly slow down halt once they start changing the design and end up with massive overtime hours while trying to debug and optimize the resulting mess. Its made even worse with managers trying pseudo-agile-learned-in-a-two-day-masterclass adding even more procedures and overhead. So yeah, you can make games today with less development talent than yesterday, it's still going to cost you more than having skilled software engineers and the resulting product will be a fraction of its potential.
- ivraatiems 11y ago
  > I've seen many Unity projects with the worst code you could imagine still run close to 60 FPS when shipped. On the other hand, a lot of the worst Unity dreck is horribly unoptimized and runs incredibly poorly, despite graphical simplicity and no real visual effects. If you tool around on Steam or YouTube you can find tons of examples - look up, for instance, Jim Sterling's "Squirty Play" series. Not every bad game on there has issues, but many do. [1] https://www.youtube.com/playlist?list=PLlRceUcRZcK0zAt8sV33ZsMCVlOgWjVoy https://www.youtube.com/playlist?list=PLlRceUcRZcK0zAt8sV33Z...

by kayoone 11y ago

fsloth 11y ago

" the other is sad because you hardly use this low level stuff in todays software development world." I don't think there is a dichtomy. It's always about smartly leveraging available resources. The problem with modern development perhaps is then that there are these tempting high level orthodoxies that often obscure the core matter at hand. Ie. focusing on some pointless candied abstract object interface rather than focusing design efforts on data flow and the datastructures and algorithms used. The need for low level optimization has most definetly not vanished. When program data fits into local ram the bottleneck moves into cache optimization.

feld 11y ago
Please write this post. I love my pebble time (but really you guys need to fix some stuff in the new OS)
- fsloth 11y ago
  Uh, sorry, did you accidentally reply to wrong message?
  - feld 11y ago
    appears so. sorry!

pjmlp 11y ago

Just try to code for mobile or embedded platforms. Yeah they might get bigger storage every year, but the reason why Google, Apple and Microsoft do talks about package size on their developer conferences is that size is number one reason for people to avoid installing apps, or to chose which one to remove. Also given how the app life cycle works on mobile platforms, big apps are being killed all the time they go into background.

codesushi42 11y ago
Not so sure about this. Most mobile games are developed with Unity. And what appear to be the cutting edge titles are usually using the Unreal engine. There's not much "to the metal" coding going on. Besides, most mobile games are being played by the casual crowd. Games don't need graphics that push hardware limits to sell.
- pjmlp 11y ago
  > Most mobile games are developed with Unity. And what appear to be the cutting edge titles are usually using the Unreal engine. Any source by mobile OS that you can point to? I am quite sure there are other contenders like home grown engines, LibGDX, Marmalade, Cocos (all variants), SDL, MonoGame, DirectXTK, Project Anarchy , Apple own Scenekit and SpriteKit,... > Besides, most mobile games are being played by the casual crowd. Games don't need graphics that push hardware limits to sell. Why do you think then all major OS vendors are teaching the devs how to reduce their packages sizes? I can happily post the links of such presentations, just need to hunt them down again. Game logic + Assets + Engine Something got to give if one is required to push the size down.
  - codesushi42 11y ago
    > I am quite sure there are other contenders like home grown engines, LibGDX, Marmalade, Cocos (all variants), SDL, MonoGame, DirectXTK, Project Anarchy , Apple own Scenekit and SpriteKit,... It doesn't matter how many frameworks are out there. If you hang around the game dev scene long enough, you'll see that most small devs are using Unity, and if not that, Cocos2DX. Just head over to Gamasutra, /r/gamedev, or browse Steam & itch.io and see the # of cross platform mobile ports. Talk to devs, they are using Unity. > Why do you think then all major OS vendors are teaching the devs how to reduce their packages sizes? Reducing package size isn't really comparable to writing portions of your game in assembler. I don't consider that low level coding or pushing hardware limits.

javajosh 11y ago

There are some abstractions, like TCP sockets, that I don't think anyone would leave behind. But language abstractions like "classes" or even "functions" are certainly worth digging into. (The new lambda feature in Java 8 is an interesting case - you don't have to get into C to see the complexity there, but rather the bytecode, which is a kind of abstract sort of assembly.) I'm not terribly familiar with the scene, but there are a variety of competitions for fun and art that operate within highly constrained environments. The demoscene[0], and computer golf[1], come to mind (although ironically computer golf is in some sense has to be very high level). There's also the security scene, which is quite bit-fiddly. It's also the case that Go and particularly Rust are quite low-level system languages at their heart, so are presumably amenable to running in constrained environments. [0] https://en.wikipedia.org/wiki/Demoscene https://en.wikipedia.org/wiki/Demoscene [1] E.g. Rhoscript http://rhoscript.com/ http://rhoscript.com/

kozak 11y ago
Can you suggest some explanation of the lambda feature in byte code?
- javajosh 11y ago
  Sure - read this gist from the bottom up: https://gist.github.com/javajosh/55339742aad2f1a1b881 https://gist.github.com/javajosh/55339742aad2f1a1b881 Be sure also to check out Brian Goetz's excellent "Lambdas under the covers" talk, linked in the gist.

banachtarski 11y ago

Making an (state of the art) engine is no easier. Making a game is only easier because the engines are more available now than they were in the past.

NickPollard 11y ago

A good portion of this stuff does still go on in Games Development. I don't work in games any more, but on the last title I worked on (Forza Horizon, Xbox 360), one of my colleagues engaged in a very similar exercise in order to allow data for the open world to be streamed in quick enough to deal with car (travelling at potentially 150+mph) to drive through the world without having to wait for loads, whilst streaming direct from the DVD (we weren't allowed to install to the HDD). Given that the world was open and you could drive in pretty much any direction, trying to pre-load the right tiles of the world was difficult, and seek times made it tough to bring stuff in if it wasn't all packed together. However we were almost at the limit of DVD capacity so we couldn't do much duplication of assets to lower the amount of seeking required. My colleague wrote a system that took about 8 hours overnight (running on a grid) to compute a best attempt at some kind of optimized packing. It did work though!

agumonkey 11y ago
Very creative. I love this kind of stories. The first interactive display, made by Sutherland IIRC, had no framebuffer (irrealistic price at that time) so the team had to stream everything to fit into the small buffer they could get. As I understand it, everything was lazy and in sync with the screen 'machinery' so there was no delay even with limited memory capacity. It felt like hardware haskell.
Cthulhu_ 11y ago
I was amazed myself that you can drive around at high speed through a busy city in GTA 3 on the PS3 without any noticable stutter and hardly any popups - good work there, too.

fra 11y ago

Some day I will write a blog post about the tricks we have to pull off to fit all code & assets - or get animations running at 30FPS - on Pebble. Trust me when I say this: low level development is alive and well at hardware companies.

fragmede 11y ago
Why wait? Blog posts serve as great marketing these days, from showing off your engineering team's technical prowess, to recruiting others who hope to participate in some really advanced problem solving. The press also helps maintain your existence in people's minds. With Google entering the market with Android Wear, and of course Apple's entry; a couple of 'this is how cool a Pebble watch is inside' would do well to not let us forget you exist!
kayoone 11y ago
Yeah sure, not saying it's non existent, just a lot less common. A blog post about that would certainly be very interesting :)
vvanders 11y ago
Yup, you see quite a few people from game dev make the transition to the embedded space when they decide that working 100hr weeks isn't their idea of fun.
Serow225 11y ago
Subscribed! :)
feld 11y ago
Please write this post. I love my pebble time (but really you guys need to fix some stuff in the new OS)
akhilcacharya 11y ago
I talked to a Pebble firmware engineer at Bitcamp who told me about the hoops they had to go through. Really neat stuff.

Qantourisc 11y ago

The amount of unoptimized crap they generate in a few weeks (in some cases) is quite depressive too I'm afraid. Game developers are wasting more and more CPU cycles, this of course reduces development cost. But it would be nice if they put some effort in making things run fast. And this doesn't only count for games!

golergka 11y ago
Making things fast is more important than making them run fast. And it's not about the cost — it's about iterations for the sake of game design.

pbo 11y ago

There is a tremendous number of hardware products and industrial systems where the processing is performed on small and cheap components (microcontrollers, digital signal processors). Of course there exist very complex components in the category of microcontrollers, some of them even offer enough resources to run Linux, but if you stick to the $1-$5 range the specs are very limited. Here are two examples, the first one costs around $3 and the second one is less than $1. http://www.ti.com/product/tms320f28027 http://www.ti.com/product/tms320f28027 http://www.atmel.com/devices/attiny85.aspx http://www.atmel.com/devices/attiny85.aspx I develop on such platforms and even though there is an interesting challenge in programming these tiny processors and optimizing CPU cycles and memory usage all the time, in the long run it becomes quite strenuous because there is only low-level stuff and I miss the expressiveness and flexibility of more abstract languages.

shultays 11y ago

I feel a little sad every time someone says "We have much higher CPU power/memory now, those things are unnecessary". Maybe they are right but I feel like this is not the path we should take

JustSomeNobody 11y ago
100% agree. And this goes for everything from server side, to games, to mobile to client side web. Some of my favorite web sites have gone from a 1-2 second load time to well over 6 seconds. And then they're sluggish after they load. It's sad.
- kuschku 11y ago
  You even see this with Google. A typical Google search from 2009: "Meaning of Life: Approximately 72,000,000 Results (0,00000042 Seconds)" A typical Google search today: "Meaning of Life: Approximately 364,000,000 Results (0,62 Seconds)"
Cthulhu_ 11y ago
It's not, but what is true is that people can focus more on features than on hacks to squeeze the maximum performance out of their system of choice.
jimmaswell 11y ago
If we're free to not waste time on tons of little performance hacks anymore, why do them anyway?

kamaal 11y ago

>>the other is sad because you hardly use this low level stuff in todays software development world. During my engineering days(Circa 2005) I programmed in 8085 and our professor would give us all kinds of crazy assignments and small projects. That was the first taste of any genuine programming challenge I faced in my life. Immediately post that, programming in C felt a little boring. Recently I worked on a embedded systems project for which I relived these kind of days. I had to invent all kinds crazy tricks to work around with resource constraints. Your true creativity skills are kindled when your resources are constrained in all manners. Time or other wise. Unfortunately you can't academically recreate the same experience.

jeremiep 11y ago

We also have pretty amazing hardware today that is surprisingly underused most of the time. I've seen many Unity projects with the worst code you could imagine still run close to 60 FPS when shipped. Having an easy entry point means you're also going to get a lot of mediocre programmers using it. They seem productive in the first few weeks of the project but then quickly slow down halt once they start changing the design and end up with massive overtime hours while trying to debug and optimize the resulting mess. Its made even worse with managers trying pseudo-agile-learned-in-a-two-day-masterclass adding even more procedures and overhead. So yeah, you can make games today with less development talent than yesterday, it's still going to cost you more than having skilled software engineers and the resulting product will be a fraction of its potential.

ivraatiems 11y ago
> I've seen many Unity projects with the worst code you could imagine still run close to 60 FPS when shipped. On the other hand, a lot of the worst Unity dreck is horribly unoptimized and runs incredibly poorly, despite graphical simplicity and no real visual effects. If you tool around on Steam or YouTube you can find tons of examples - look up, for instance, Jim Sterling's "Squirty Play" series. Not every bad game on there has issues, but many do. [1] https://www.youtube.com/playlist?list=PLlRceUcRZcK0zAt8sV33ZsMCVlOgWjVoy https://www.youtube.com/playlist?list=PLlRceUcRZcK0zAt8sV33Z...