I have to say I get quite jealous everytime I read on the forums those of you bragging about having coded drivers or even compression algorithms in their Commodore 64 or Amiga or having been part of a demo scene. As someone born in the 90s and who has only used Windows, it has always felt like a locked box.
So what should someone who wants to learn those ‘tricks’ those of you oldies gained in the days when finding a way for corrupting your file system was more entertaining than surfing the internets?
In short words: what’s the modern equivalent activity for those ‘breaking my computer is fun’ days?
I’m not dense enough to not notice Unity is the one actually making the games for me, not me.
I disagree. You’re definitely making the games. Unity makes it faster and easier, but you’re still the one doing the making.
Heck, if you look up the definition of “game” you’ll quickly realise that Unity can not make that for you. It gives you tools to easily make simple simulated worlds. The rest is entirely up to you.
Anyway, sounds to me like you’re interested in how computers actually work. That’s what those “tricks” are about, and those stories come from learning those “tricks” back in the days where there weren’t so many safeguards. So, my honest suggestion would be to start learning computer science - at least the parts about how computers and operating systems work.
Don’t think of modern technology as making it harder to break your computer. Instead, think of it has giving you even more fun and complicated ways to break your computer. People still write drivers and machine level code today if that’s what you’re interested in, and the demo scene is still doing its thing. You can even download a free Commodore 64 emulator and write a compression algorithm with it to assuage your jealousy. Though, I have a feeling once you’ve been staring at that sweet two-tone bordered blue screen for a few hours, you’d find it’s not quite as glamorous as you imagine…
Old people also tell stories about the times they walked to school for ten miles in the snow, uphill both ways. Nostalgia is nice and all, but it comes as a result of age. Regardless of what you do.
I mean, do you really want to go back to travelling at the speed of a horse?
If its low level code you want, there are still plenty of applications for this. Most processes on machines don’t have the power to run a full blown OS. And of course, someone still has to build OS systems.
I understand what you mean, I too feel the same way. But I think angrypenguin is on to it. Its computer science. A lot of foreign schools have computer science classes, but mine never did (or any worth while computer classes for that matter), so I skipped a lot of fundamentals before I started using Unity, and the further I went on the more I realized I’m missing something, something obvious to other people, that’s making some other things obvious to them but complicated to understand for me. And I’m assuming its stuff you normally learn in computer science classes, or alike.
Or I’m just stupid. But my mother says I’m not, and that I’m a very special boy.
I think the benefit of Unity is that: I don’t have to know how the hardware of my Computer/Phone/WebGL/console works. I just need to take care how my games work. But if you want, you can build your own game engine in C++, althought it’s stupid to re-invent wheel
In the old days the internets was much less entertaining, monkeying with the os and hacking stuff together was far more exciting. Ya gets your kicks where you can. Even porn was barely worth the effort. 30 minutes to just to see 16 bit boobies? Time was better spent trying to find where dad hid his playboys. Slow internet was actually a benefit.
Like @angrypenguin said… you ARE the one making the game. However, I think there is a difference between relying on GUI tools and pre-built systems and doing it yourself. If you can get the results you are looking for from the GUI tools then awesome… use them. I think sooner or later though you will hit a wall and if you do not have any of the fundamentals down it will be a time when you either need to learn them or your project ends.
The equivalent style in Unity would be not using the Animator and doing it yourself. Not using the physics system for collisions and interactions and doing it yourself. Not using PlayMaker and instead designing and coding your own system. Learning about data types, data structures and common algorithms. It is a longer road but in the end you will be much better “armed” to handle any issues you run into and the boundaries of what you can accomplish will be greater.
However, I do take advantage of a lot of already made things. Unity’s Sprite Slicer (confusingly named Sprite Editor which it is not in the traditonal sense), using the Scene Editor to populate image references for my animation tables and sound FX references for my sound tables. I also purchased SpriteTile instead of creating my own Tile Map Editor and Tile Map Engine. If there was more quality stuff I’d use it but most of the stuff I have tried out is either limited in some way, erratic or just a bloated workflow.
TLDR: if you are able to make the games you want using the normal Unity workflow without understanding much of what is going on behind the scenes then use that approach. If it works there is no need to change. If you often find yourself struggling trying to get something to just work then you might benefit from diving into a lower level approach. Rely on Overlap or Casts to detect collisions, animate in code using tables, build your own AI instead of using a GUI State Table Designer and so forth.
If you want good ol’ technological fun where sometimes programming a basic task ended up corrupting files or breaking your machine, you could always pick up C programming.
You can get a segmentation fault in seconds, just declare a pointer and then use it without allocating any memory!
I think there are just different things that appeal to different people. I prefer designing my own solutions and coding them over using a GUI… by far. For me GUIs are inefficient. They are slow and generally too limited. Coding is fast and there is no predefined tunnel to limit you. GUIs are good for end users. Things like option screens and such. But even in the world of users (business software users) most prefer keyboard over mouse because it is just so much faster.
It is funny really we make GUI forms here for our products but nearly all of our users demand keyboard control for everything. Tabbing, shortcuts and so forth. If they never had to use a mouse they would be happiest I think. I see the GUI stuff in game dev the same way in most cases. Clicking on a dropdown list box here, a NumericUpDown control over here and so forth it looks good and controls user input which is great but it is slow and limiting at the same time compared to just keying in the values. And things requiring click here to add a node, click here to rename it, click here to enter a value etc there is just no comparison between that and just coding it up.
As one of the older members who will occasionally talk about the good old days of TRS-80s, Commodore 64s, and so on, I can honestly say you did not miss much. The reason we were doing hardcore low level things was because we had to. If we wanted to make a game, we literally had to manage each pixel ourselves. We often spent more time doing boring tedious things than we did building actual gameplay. Today, you can grab Unity and build a fun game without needing to first figure out a bunch of tedious low level stuff. That is a good thing. Unity won’t make a game for you, but it will let you focus on making a game instead of building an engine first.
If you want to get an idea what our “good old days” was like, set up a really low end computer with a build of Linux and disable the GUI. For example, grab a Raspberry Pi. Build a few simple applications in C. It will still be a thousand times more exciting than what we could do with computers back in the day. For example, you will be using flash storage instead of a leaderless cassette tape, and you will be able to do graphics at resolutions and color depths we could have only dreamed of all those years ago. But it will still be a useful experience if you want to step outside of your Windows centric comfort zone. It is probably the closest modern experience that feels like those good old days.
Some of the good old days stuff was admittedly stupid. For example, a lot of computers back then centered around letting users play around with programming in Basic. That seemed fine since Basic was easy to learn. However, most of us outgrew Basic pretty quickly. If you wanted to do anything more advanced in Basic, you often had to use the POKE command to write directly to specific memory addresses. For the Apple II, I wrote several programs that played music, and the entire programs were pages of POKE commands. It is the only practical way to do it back then. The problem with POKE commands was that it made it really unreadable. I could come back to my own code in a month and not be able to figure out what it did and how I made it work.
And of course, the GOTO command got a lot of action back then as well. It made for a real mess. That is why I mentioned using C above. C is awesome. Basic is stupid. In some ways, Basic may actually teach people how to be worse programmers.
See? It is things like this I am talking about. Got any resource that expands on this?
Last week I was prototyping a game where I practically got everything running properly fully based on manual transforms because I somehow can’t get out of my head the idea that PhysX starts getting bugged at high speeds while transforms don’t.
But then I hit that wall you mentioned: “How am I going to detect collisions If I am not using the physics system”.
And that’s where I realized the engine had been doing all the work for me and that maybe all I know in Unity does not translate to other engines. (I thought about placing 4 empty transforms to simulate a box collider, but would you say that’s a legit approach or a hack?)
And so I made this thread to learn where exactly I can learn at least the basic ideas of the tricks you can possibly implement.
And so when I read things like
I go “the Windows calculator I made in C# back at uni ain’t got nothing on this!”
When I said don’t rely on the physics for collision detection and interaction I meant don’t just add rigidbodies and rely on collision event callbacks and letting rigidbodies control the reaction when two objects collide. The automatic interaction such as sliding around each other etc. Of course, use it if it is working fine for your needs. Otherwise drop down to a lower level and use the Overlap or Casting methods to check for collisions then code up the reactions as you see fit. The physics system is always running as far as I know but all of my GOs for example do not have rigidbodies. It is most likely breaking Unity conventions but then I never asked for the physics system to begin with. If there was an option Disable Physics I would do that.
I talked to a guy the other day who said he had always wanted to learn assembly, and that he was going to try. There’s always someone out there, I guess.
It’s used a lot with embedded hardware that uses 8-bit CPUs. Modern desktop CPUs are vastly more complex, and you’d need a lot of in-depth knowledge to out-optimize a compiler.
I remember doing graphics by planning them all out on graph paper and then doing the math to build the values. Ugh. While I don’t miss those days, I am glad I have them under my belt. It is valuable to understand what is going on under the hood, even if you don’t have to open that hood anymore. I can do more in goofing around in Unity for an hour than I could in weeks of concentrated effort back in the day.
The only downside (well maybe upside), is that the old way didn’t really allow you to get caught up in the refactoring/over tweaking/direction change that is too easy to get into with modern tools. You had to plan and then build, it wasn’t practical to be vague or experimental. Having had to work that way, makes it more easy for me to execute to completion, because that was the only way to work back in the day.
