This is neat and I always find myself coming back to these sort of topics year after year, learning stuff I’ll never actually use, about how to make a video game. I bet there’s a lot of people here like me who got into programming as a teenager because they wanted to recreate their favorite 2D video games, ending up having a useful career skill instead and almost no video games to show for it for lack of time. The issue was only made worse when the industry went toward much more math heavy 3D games which has logic my mind just can’t wrap its head around. Maybe that explains why Kickstarter and Steam saw a ton of retro 2D games in the past few years... some people just went for it.
> Maybe that explains why Kickstarter and Steam saw a ton of retro 2D games in the past few years
I actually think (as someone with gamedev experience) that the explanation has to do with the difficulty of creating art assets for 3d games rather than complex math (as other users have pointed out, current widely used engines take care of mostly).
Indeed, even indie games that are made in 3d generally take a low poly style as they are easier to make (and obviously easier to achieve performant results).
> the difficulty of creating art assets for 3d games
As somebody who is a hobbyist at best, this is my biggest sticking point. Anybody can learn to slam together some pixel art in Paint, and even doing more advanced work in Photoshop is not out of reach with a little time and practice. But learning a 3D modeling tool is orders of magnitude harder - I've made a couple runs at Blender and older versions of 3D Max, and there's just so much to making meshes that look decent, and then you have to skin them. And then there is the question of adding animations. My hat is off to people who have developed those skills.
My only hope is that technology to make this process easier will advance. I've seen some demos of people using their phone cameras to scan real objects and generate 3D models, but even if that worked perfectly, it appears to me that there would be a lot of work to process that into passable 3D art assets.
I think the difficulty in 3D polygon modelling is partially a tooling problem, and also a learning curve problem. The usual workflows I've seen/used that didn't involve sculpting (which requires being good at that too) all involve blocking out the model in several steps and applying semi-irreversible transformations, making it really hard to go back and fix a dumb mistake. Some editors like Blender are also notorious for having completely impenetreble interfaces, and even 3ds max and similar probably aren't too straightforward either. Ontop of all that, you're required to know a ton of technical details (skinning, normal smoothing, etc) that aren't explained properly for modellers anywhere I know of (building an engine/renderer is a fairly direct way to pick up that knowledge though).
3D sculpting and CAD modelling are entirely different beasts however (I've never actually seen CAD tools involved in a game asset workflow, but it could be done and would be fairly useful for inorganic assets). Sculpting is dead simple in principle, in the same sense that drawing is; meaning you don't need to worry about the tools in the same way. CAD is a different beast, but still works on some pretty simple principles (constraint-driven CSG).
I think the only real "hard" part right now is getting low-poly versions of assets that can be used inside of your engine. Making the high-poly assets might require more actual work (and 3D scanning could help there), but it's nonetheless fairly straightforward.
edit: "low-poly" here meaning "reasonable number of polygons", not visibly low-poly.
I'm from an art background - and honestly, I couldn't disagree more.
The reason why most people are bad at 3d modeling is that most people are bad at art. Reproducing shapes from real life to any medium, if it's charcoal, or clay, or 3d, is very difficult. People who are good at it typically spent tens of thousands of hours practicing.
Part of what you learn in this practice is patience. Part of what you learn is a good eye. However, unless you're fundamentally allergic to tech - tools like Blender are simply way faster and more powerful than any other medium.
Consider an 'art' skill like making woodcuts. There's no 'undo'. Mistakes are very easy to make, and often involve stabbing yourself through the web of your thumb with a chisel. It takes days of painful, physically tiring work, that is very bad for your hands, to simply make the lines. It's like that because real material processes don't care about user-friendliness.
For me, learning Blender as an interface was enjoyable because I could see how much easier it was going to make my life. It's neither large, nor unduly complicated - I'd consider it similar to learning vim, or photoshop. The real problems - the hard problems, are art problems.
VR might make waves here (and there are some interesting VR demos out there) though that's a long way out. Creating 3D structures on a 2D surface is always going to be a fundamentally difficult problem.
It isn’t just that it is more difficult, it takes much longer to produce a final art asset. If you are doing a 3D game you won’t be able to get away with one artist, you’ll need a team.
A good pixel or 2D artist may have more skill in many dimensions than an average 3D artist, but given the fidelity of what is being created they will be able to produce more in a given set of time. Ideally, as an independent game developer you want to have one artist. You can do that if you choose 2D.
"My only hope is that technology to make this process easier will advance."
If you just want to source art assets using 'standard' definitions used in CG and games you
a. Subcontract them
b. Purchase them from some store or source free ones
c. Use generator programs like Poser
and any combination of those.
If you want to learn modeling and art in general,you learn modeling. The trick is it's partly art, so unlike, say, woodworking, the number of free parameters to master is quite large.
To my understand, some 3D artists are currently building things using VR to create the rough mesh layout, and fine tuning it after in a program like blender
There's also modelmakers that scan real objects as well too
Have you tried Unity or Unreal? I think they're relatively easy for a programmer to get into, and they are great fun to tinker with as well as enormously powerful.
Yep. Started teaching Unity to my kids. I have neither the imagination nor the patience and time I had when I was their ages and wanted to make video games. Figured it’d be a better use of time to give them the tools and time and opportunity to try their hand at it. They’ve made some cool small things in it so far.
32 here and I don’t think it’s going to happen for me and probably not my kids either realistically. But at least I got decent career skills out of it. So that’s how I’m trying to look at it.
Before I developed a serious rendering engine, I'd read Advanced Animation & Rendering Techniques by Watt & Watt [1], cover to cover, a dozen times. It's pretty dated now, but at the time I first acquired it (90s) it was the most comprehensive overview of rendering I knew of. I'd also read Real Time Rendering, and Math for 3D by Lengyel, which are both on this list. For really proper collision, Real-Time Collision Detection (on the list) was absolutely invaluable, but I didn't get to that until a few years later. Around that time, I also read the excellent architecture book Game Engine Architecture [2] which I don't see here. It's well written, does things in the right order, and it's very comprehensive.
If you're interested in rendering, more in general, there's Principles of Digital Image Synthesis by Glassner. This is probably the only book(s) I can point out as a standing example out of all I've learned from during the studies in the field. Lots of nice material now out there, of course, but this one is at the core of everything. It wasn't maybe suitable for realtime rendering, but as tech advances - we're getting there. It's even available now online: http://www.realtimerendering.com/Principles_of_Digital_Image... (and damnit I paid a bit over $200 back in the day)
Out of all of them Realtime Collision Detection stands out. It's basically datastructures for real-time spatial data. Every chapter of that book is gold.
I just looked if there was a newer version of it. There doesn't seem to be, but Christer Ericson does still have a dedicated page for the book. The errata section[0] is surprisingly small given that it is 632 pages. I thought this snippet was interesting:
> All illustrations in the book were redrawn from my original illustrations. Unfortunately, the company in charge of redrawing the illustrations mangled almost all of the illustrations doing so (right angles became accute or obtuse, etc). I thought I had caught all their errors before the book went to print but sadly it seems I missed a few.
Tangent: his 2003 presentation on memory optimisation[1] is also still a very interesting read, especially the last section on aliasing. I wonder how much of those comments still apply to modern languages (or C and C++ compilers, for that matter).
Pure gold, indeed. It is a very important reference book (can be found in Amazon both new and used), not only for collision detection, but also for space partition, geometry, code optimization, etc. Also, the author has an amazing blog in the web page of the book:
I used to consider 3d graphics something that's cool but non-essential to learn, but lately, getting into computer vision and robotics, I've found that much of 3d graphics overlaps / are a prerequisite. It's fun that these topics are becoming more widely relevant as more jobs open up in computer vision and robotics.
Certainly a lot of overlap with robotics, since articulated models in a game are like virtual robots, complete with real-time requirements. (But no actuators, thankfully.)
Michael Abrash's Black Book is a very enjoyable read. The material is oriented towards a much lower level than people are working with today, but there's some great information in there. I feel that it does a good job of teaching one how to think about approaching a problem; not just DOS graphics techniques
The Black Book is a classic. Obviously, much of the material is dated, but Abrash is a great writer. IIRC, there's some tidbits in there about Carmack's approach to getting BSP into Quake...or maybe that was Masters of Doom.
I know this author means well, but even for a game dev 'veteran' like myself, all this reading seems quite daunting. Can't imagine what a junior aspiring game dev thinks.
How much value is there in reading without completing exercises? I find that, for myself, knowledge gained through hands-off reading is very shallow and difficult to apply. On the other hand knowledge I've applied hands on has been vastly valuable. One recent example that springs to mind is kmv data sketches. I understood their theory and the algorithm's details but the (simple) concept and it's cases of applicability did not really click for me until I wrote one for use in an application on someone else's recommendation. I spent the next week gushing about my revelation, to my colleagues' annoyance.
The things I read without doing exercises gives shallow knowledge indeed, but that shallow knowledge lets me know what I must learn about later when I need it. Also shallow knowledge is easier to obtain, so I can spend time on getting shallow knowledge that would not have been time I could use for real learning because there the limit to how much real learning can be absorbed during say a day is lower than the amount of time available in a day IMO.
One of the ways we count distinct elements in an unknown amount of data--probabilistically! You may have heard of Bloom filters and the like, and this is a similar family of algorithms.
I came to the conclusion that I need to learn blender as well, and spent about 2 weeks using it, but man, it is such a frustrating (yet powerful) tool, somewhat like Apples Interface Builder :)
It’s just not how I would like to work. I want more control via a super smooth interactive text-based interface; that interface should integrate seamlessly with a visual direct manipulation interface.
The interface improvements that have been made since then have been amazing for discoverability and they have kept (most of) the old keyboard shortcuts too. This is not a bad thing at all, but it does mean that there are tutorials which still make it seem like Blender requires just knowing and memorising loads of keyboard shortcuts.
When learning Blender, the space bar is definitely your friend these days.
I am pretty sure I have not learnt it deeply enough! I am also pretty sure that what I want does not exist yet, so it would not make sense to get deeper into Blender.
I used the Python API of Blender in a project with a friend of mine once to define the objects and the scene we were making and to provide parameters for the placement of said objects. It was an okay-ish but not great experience.
The API did not feel totally Pythonic, and it did not feel like it was intended for direct use. It felt more like it was meant for plumbing and plugins, not for creating and controlling a specific scene.
For those who are interested in 2D game development, the Phaser JavaScript framework just released version 3.0 which had the support of a Mozilla Grant.
Can anyone recommend a project-based book for learning OpenGL? There have always seemed to be a lot more books in this style for DirectX, for some reason, but when it comes to OpenGL, the references are always the manuals, whether that be the red, orange, or blue books. I've used the Nehe tutorials in the past, but they are severely dated the last time I checked.
Had Apple not adopted OpenGL and GL ES as a means to save 3D R&D and make their shinny new OS attractive to UNIX devs (they were researching Quickdraw 3D initially), OpenGL would be history concernig 3D game APIs.
