* First we pick a nice API, let's see, yeah SDL with OpenGL is a good choice
* Let's create a full screen surface and set the happy little flags to make it a double buffer
* Let's just write some happy little class wrappers for our main game components. There we are.
* We start with a happy little box twirling around. Just gently use the OpenGL API and map the textures so that they fit. A happy little light lives in the upper right corner. Now lets add some other boxes over there.
* Ever so softly write some game logic. If you're feeling adventurous, try using multiple threads, but don't forget to use some locks.
* To finish it all up, we just plug in the user input. How wonderful!
See you next time when we write an operating system!
I thought this was going to be a snarky response at first - "I'm a programmer so I can't do art; as an artist can you do programming?!" - but I was wrong.
I'd love for there to be a Bob Ross style course on game programming, his soothing voice combined with his rose-tinted vision of everything would be awesome. Happy little clouds
It's meant to be a little snarky - from a macro level everything looks simple if you just segment it into ten steps. The problem is that each steps contains many many details and years of experience and hard work that can't even be verbalized properly.
Try and read the earlier post. I think they do explain the approach a lot better. I don't intend to make you into the next daVinci but enable my readers to create decent game art or at the very least better looking place holder art for their games.
> It's meant to be a little snarky - from a macro level everything looks simple if you just segment it into ten steps. The problem is that each steps contains many many details and years of experience and hard work that can't even be verbalized properly.
What part of the tutorials did you find hard to follow?
Yes it's hard to verbalize the "why?"'s of the choices made in the tutorial, but that's why you just have to plonk down with Inkscape and recreate what's in the tutorial. That's not too hard, is it? To manipulate the spheres and boxes so they appear like in the tutorials, a programmer isn't daunted by an unknown GUI, are they?
The only way to learn it is by experience, actually doing the exercises. You can't explain the "why?" beforehand, but as you simply follow the steps, you will encounter the same states/stages as the original artist/author did, and the choices they made will become obvious only after you experienced them from that point of view. (you can't use words to teach that kind of understanding)
FTR, I did do a number of the tutorials a while back already. But then, I already knew how to draw. Except on paper and in raster-based image editors. Working with vectors in Inkscape was a new and very fun experience. Plus it turns out to be super-useful for taking PDFs apart!
Also the workflow from the tuts was something I might not have trivially figured out myself: Find an existing object whose shape has the qualities you need (or a circle or box if needed), duplicate it, tweak it, get to know the deformation effects, set operations, etc, whatever you have to do to have to tweak as little actual vector nodes as possible. But to do this, you need a type of 2D spatial insight, and you can only train and practice it, nobody can explain it until you got your hands dirty a bit.
But a programmer should be able to do that. It is however a terribly frightening step for a programmer to take: "Okay, I'm doing this, but I don't know WHY ..."
I totally get that, I feel the same way and hate it when a coding tutorial does it. But for drawing it's different, it's more like those "VIM kata's" that were posted a while back on HN. Ok they too explained the "why?", but the main intent was to train that muscle memory. And fortunately it turns out you don't even need much muscle memory to make cool things with vector drawings (unlike, say, pencil-and-paper drawings) which is why they're particularly good for people that can't really draw freehand.
That said, of course there are certain parts of drawing/art that can be taught with words and explanations. But they are advanced topics like perspective or colour theory.
That may be one thing where I can imagine somebody with no graphical experience to (possibly) go wrong with these tutorials: they will probably pick awful colour combinations at first. Also they may not understand when it's a good idea to add a black border around something for good contrast (in cartoony drawings), fortunately the author does (IIRC) point out this trick. But it's the same as for shadows or any other type of drawing "trick", you just gotta wonder "why doesn't my image look quite as good as this other one?" and then look very hard what's the difference. And the nice thing about vectors is that unlike paper drawing, you can actually go back and insert those shadow or outline shapes between the layers of your image, so you can just keep non-destructively playing around until you get the exact result you intend. That's a lot harder with Photoshop or GIMP, not only will you be cruising through the undo-history, when your inspiration can effortlessly draw freehand sketch lines that take you minutes to make look acceptable, it becomes very frustrating (that's why you want to practice that on paper first, and then buy a drawing tablet :) ). With vector-drawing it's more like cutting paper shapes and arranging them (like Southpark :) ), except that in this case, doing it on the computer is actually easier than messing around with scissors and glue.
I don't think you got the idea right. I am not trying to teach programmers to repaint the mona lisa. I am just providing a different approach and tutorials on how to use inkscape to create game assets that are good enough to be used in games. If you would have taken the time to read the first posts of my blog you would have realized that.
This wasn't meant to be an attack, I've really enjoyed the tutorial and will definitively look at it if I was to do some art.
I was just making a little fun about how the non-threatening language can make the reader feel stupid if he chooses to misunderstand it. No offense intended.
If you copy what he's doing in those tutorials, you will learn something. If you just copy someone's code by typing, you will not. That's the difference.
Or are you saying you can't even follow the exact steps in that tutorial to result at a very similar image?
If you just read the tutorial, you won't learn much about drawing. He could explain all the choices he made, and you may feel better about knowing that, but the end-result will be initially about just as wonky as it would otherwise have been.
Thanks for the great comment... I couldn't have said it better myself... The tutorials are written to follow, play and then create your own variations of what you just learned.
Well, thank you for the great tutorials :) I played with Inkscape before, but before these tuts I never managed to actually produce something useful with it.
Only a week later I was making things like this: http://i.imgur.com/iluDL.jpg [1] -- I know it's nothing like your tutorials and they were indeed also partly done in GIMP, but Inkscape was incredibly useful for quickly trying out different styles when masking out the fore- and backgrounds. I only had a rough idea what I was going for at first, and trying out different variations of shading was a much quicker process than it would have been with just GIMP. Also, combining several (linear/radial) gradients so they fill the background just right like that, I wouldn't even have attempted in GIMP (and instead end up with something that only looks sorta right).
BTW do you happen to know what is the best format to save in, so that somebody with Adobe Illustrator can easily use it? A friend of mine who was doing the lettering (not shown) had some issues loading them so I ended up sending him huge rendered PNG images (which worked, but I hate it how any semi-serious graphics design project can turn into tens of megabytes just so you don't have pixels on A2 :) ). OTOH, I don't think he tried very hard, next time I'll make sure he has Inkscape installed so he can do the conversions himself.
[1] these are partial images used as posters for a party tomorrow, and yes I am aware that the maya calendar thing is a few weeks later.
When you look at arts explained in the tutorial, objects are getting their shape from simple square, rectangles & circles. It is easy to comprehend.
In your case, even not many programmers would understand whats SDL.
Why shouldn't be writing C++ game programming or operating system, easy to comprehend for Artists?. If we had made writing OS easy for Artists, OS landscape would be much different than whats today.
I have found Inkscape to be quite an under-appreciated tool. It is much easier to learn than Illustrator for a beginner, quite light on systems resources and has great keyboard shortcuts.
Earlier when there was a logo to be designed I used to use GIMP. But I find Inkscape's text handling to be much superior (especially with manual kerning) and flexible. In fact, I do most of my website mockups with Inkscape these days.
It's also just damned useful. You can open up PDFs and grab diagrams out of research papers. You can re-save PDFs after converting all the text to paths, to avoid font embedding problems. You can manipulate the saved files with d3.js.
It's very quickly become one of my favorite tools.
One thing that I would really love in tutorials like this is why certain decisions are made. I am a terrible artist, but I would like to learn how to draw something that doesn't make people want to puke, if for no other reason than to give a real artists a starting point, but this tutorial doesn't help.
Even at the first step, it says 'Lets start building the body with 3 rectangles'. But if I started with a blank page, and though 'How am I going to draw a helicopter', my first thought wouldn't be draw three random rectangles and start from there. Learning tools is important, but I want a tutorial that shows me how to break complex objects into manageable parts.
I highly recommend reading this blog from the very beginning. He starts out REALLY simple and gently leads up to the more advanced stuff like helicopters. It's given me enough confidence to do some of my own stuff and I'm getting better.
Also, once you've followed the blog, try copying from other people like Angry Birds to see if you can recreate it. It's surprising how many game assets start to look like collections of simple objects whereas before you thought "how did they do that? They must be just brilliant."
I haven't read the book yet, but it's on my Amazon wishlist because it's supposed to teach you exactly this. The descriptions on the site and on Amazon don't give much insight, but you can find the introduction and first chapter on Google Books to get an idea of what it's all about.
Pretty sure this was first introduced to me on HN, so others can probably expound further.
I own this book, it is not the right book for learning how to illustrate.
Don't get me wrong, "Drawing on the Right Side of the Brain" is a decent book. If you follow it, in a few short drawing sessions it will lift you from a person who can't draw at all to a person who is a novice at life drawing with some impressive looking portraiture. You will be amazed at your own progress at life drawing. You however will not progress much further than a novice.
For drawing game assets and other types of illustrations, you need to learn to draw from your imagination. This is a very different skill from drawing from life and a skill that "Drawing on the Right Side of the Brain" will not teach you. I can't make recommendations of books myself, but I can suggest looking at this [1] thread over at cgsociety.
I just went through this process myself. Drawing from your imagination takes taking the rules that a book like "Drawing from the right side of your brain" shows you and basically practicing. For example, once you learn how to draw the basic human face you can take the memory you have of drawing that face and tweak it a bit. You tweak it until you have something more monstrous, like an ogre for example.
That is why most of the stuff that we see drawn from a persons imagination still has very recognizable human components to it. It takes a lot of practice but books these and other lessons you will find are meant to be a building block so that you can draw from your imagination.
The problem the way I see it is frustration and lack of satisfying results. Most programmers I have come across in my 20+ years of making game art have tried art (even just place holder art) and have scribbled but were not happy with the results and couldn't see any progress in their art.
Drawing is a lot harder than 'building' objects from simpler shapes in vector design program. It's more like playing with lego brick rather than try and convert a 3D object you see into a 2D drawing on a piece of paper. I find the 'just take pencil and paper and draw' advice not very helpful for people struggling to draw a stick figure. Usually the road to successful and rewarding results is very steep and long when you learn to draw. Placing a few shapes on the screen and playing around with those, can create results a lot faster and that's the goal of my blog. I don't have any intentions of teaching people to draw like the old masters or be the next comic book superstar. It's just about quick and easy ways to create visually pleasing art assets by people who normally shy away from anything artistic.
It doesn't matter that the right brain/left brain thing is a complete myth. This book really works! Don't focus on the book's title so much, it's really all about looking at the world in a different way, and the "right brain" part is just the catch to make you pick the book up.
I realize how wishy-washy this sounds, but artists really do look at things very differently than scribblers do when they're drawing, and it makes ALL the difference.
Drawing on the Right Side of the Brain teaches the fundamental concepts of drawing that applies to anything you'll ever draw, and it really just can't be ignored if you want to be able to draw anything without taking classes.
Basically, there's a reason this book keeps coming up in discussions about learning to draw, and it doesn't have anything to do with neural theories.
Do a few of those tuts before you start saying that :) This isn't the same as learning how to code, that you have to understand every step along the way. You need practice, and you can actually just copy what he's showing, and by doing you will learn how these drawings come apart as objects.
And as a quick answer to your question: in most of the tuts you always start out with either a rectangle or an ellipse. In fact, what he always does is he picks the object that looks most like the shape he wants to draw. It's either a primitive like the rect or ellipse, but other times he duplicates already existing objects. But it's just shape matching, afaik there's one where he clones the nose to shape into an arm :) The point is you can add and delete nodes using the pen tool, so you can tweak the shape entirely, but it helps if you got somethat to start with that already has the right basic shape.
You cannot expect to have prescription on how to do art.
It's about stepping back after you're done and saying "this sucks" and improving on that.
Sure, there's methods and best practices, but they're not nearly as relevant as quality of your judgement on your work, developed through practice and exposition and, in part, inherited.
You just answered your own question. Look at the thing you want to draw, and break it down into main mass components. Base this on the connection points, or major angle changes where the components connect. So for a car, you could start with 5 random rectangles: The hood, windshield, the body, rear window and the trunk. All the same size to start because you only want to break it down where there is an angle change.
If you want to learn this, then take a look at human figure studies. They will show you the exact same concept, but with ovals. Draw 30,000, and I guarantee that your 30,001st won't make somebody puke.
When sketching objects you should be thinking in terms of cubes, cylinders or ellipsoids, not rectangles or ovals. Thinking in 3D makes it much easier to get perspective and shading right.
So your advice to a guy who is brand new to art, and self admittedly can't draw, is to jump right in to volume and focal points because it makes the easy task of shading even more easy?
Being able to draw basic geometric figures in 3D space is the fundamental skill. Drawing a cylinder instead of a circle is not that much harder, but it sets you in a totally different mindset.
Thanks for posting the link to the beginnings.... This is where people interested in trying out inkscape and game art creation should start. The helicopter is the most complex and daunting project on my blog so far.
Being a little disillusioned with Adobe tools, and assembling a game dev enviroment on Linux, I am trying to setup some of my game art workflow using Gimp/Inkscape/Blender/other.
What I'm hoping to acchieve is have a bunch of scripts in Python (as all those listed apps are conveniently scripted with it) to speed up the asset generation, and possibly explore some of the design aspects achievable through procedural methods, as designers using Adobe tools do have a slight tendency to be uniform in their output.
I use Inkscape as my primary means of collecting games resources and assembling them into a re-distributable package. I have my own build system that takes general Inkscape(SVG) objects, parses the namespace/hierarchy as described (Hint: CTRL-SHIFT-X .. drag the XML Editor to a second monitor..) and outputs a package tree that deposits directly into res/ &etc.
Paired with MOAI, I'm having a wonderful time handling the game asset pipeline in a structured manner.
The SVG DOM makes for a very vibrant playground when you want to automate things, and getting it all packed down to a .PNG tilemap can be done with very, very little script code ..
I've always found Photoshop difficult to draw in, and haven't really enjoyed drawing on a computer since Deluxe Paint. However, Inkscape (a program that I've not seen before) looks great, and I will be trying out the tutorial. Thanks.
I'm also tempted to say we should all post our helicopter drawings!
Same here with Deluxe Paint, though having used Inkscape they are of course nothing alike.
Vector graphics is well and fine for some things, and Inkscape is a great app for that, but personally I like the pixels... Grafx2 is another alternative if you liked Deluxe Paint.
I really miss the simple elegance in Deluxe Paint (of course I can run it in UAE, but
I recently went through about 30+ packages in the Android market trying to find a tolerable paint app for Android, and they all failed spectacularly when I compared them to my minimum "equivalence with Deluxe Paint" metric (proper zoom being the biggest one, which is a bizarre thing to do badly on a platform where most users will have tiny screens), but it's the same on Linux. GrafX2 is reasonably close in terms of functionality but the UI is very cluttered.
To be fair, comparison between Inkscape and Photoshop is not really an appropriate one, as one is a raster and other vector based tool. It's usually Gimp vs Photoshop and Inkscape vs Illustrator.
Thanks for the mention of my blog on the Hacker News. I just which there would have been a link to the earlier posts. The post got harder and more complex (with the helicopter pushing the limits of what could be considered easy to follow art tutorials for beginners).
As an engineer I find CorelDRAW far more useful (and usable?) than Photoshop and Illustrator sometimes. I do use Photoshop for quite a bit of work. However, CorelDRAW makes some things that require jumping through hoops in Photoshop really easy. It's almost like a melding of a technical drafting and an artist's illustration tool.
It can, for example, ingest AutoCAD geometry and use it for further illustration. Since I've been using AutoCAD for a long, long time this aspect of it comes with no effort.
In the case of the OP's example, I'd probably find a 2D or 3D model of a helicopter for either ACAD or SolidWorks; load into the appropriate tool; edit, stylize, simplify; export as a flat 2D DXF and then import into CorelDRAW. From there you can manipulate further, stroke, fill, shade, etc. Do it all in layers and then output whatever it is you might need.
Maybe this can be done in Photoshop, I don't know. It seems that I am always Googling for how to do the simplest things in PS. Yes, of course, I don't use it enough. That said, things like having to jump through hoops to draw a stroked circumference drives me up a wall sometimes. In a program like CorelDRAW it's just a matter of drawing a circle without fill, which makes far more sense to me than having to draw a path and then stroking it.
I've done some pretty interesting graphics in CorelDRAW for such projects as photorealistic renderings of product models that are not only interesting graphically but also dimensionally accurate because of the link to the underlying CAD data.
For a lot of the work I do on the web and iOS apps Photoshop can be simpler to wrestle with.
I guess you didn't bother reading but just looked at the colourful pictures. The tutorial is more advanced and earlier post make it easier to follow... but the feedback I get shows that people can follow the ideas and create their game assets in this manner.
If you want to learn how to draw, besides the basic drawing courses or books, another good idea is to learn about Photography when it comes lighting and composition. I know a lot of people on this site have DSLR cameras so learning how to use those properly would be a great step. Photography lessons are great in helping to learn how to see the world correctly. A lot of what you will learn will be transferable when it comes to learning how to draw.
I'm a proto-geek who kind of taught himself to be more artistic. Let me share a few tips:
- Learning to draw is not actually so much about drawing, but learning how to see. Light is complicated and humans like to abstract, especially geeks, so when we look around, we rarely actually see what's there. When you look at e.g. a shiny teakettle, you need to see the specific reflections in the metal, rather than just parsing it into "shiny bowl". When you look at faces, you need to learn to spot the shadows and the curves from various angles, e.g. a face in profile vs a face head on. Even simple objects can be deceptive, e.g. put a box on a surface, and it will create a subtle border of shadow around its base due to indirect light bounces. I found drawing from photographs was best for learning this, as it's pre-flattened into 2D. Also, there is a reason that artists study the anatomy of skeletons and musculature to draw nudes.
- To make matters worse, our eyes and brains suffer from various optical illusions. This means that you should not strive something that is right, but something that looks right. For example, horizontally aligning an asymmetrical shape... sometimes it just looks more balanced slightly off-center. Or go into Inkscape and type the text "XOXOXO". Zoom in, and you can tell that 1) the X' diagonals don't meet at a central point and 2) the O sticks out a bit below and above the X. Both are there to 'fix' optical illusions. Also, because of the difference between left brain and right brain, often it helps to flip your image horizontally midway to see all the flaws.
- When it comes to design (rather than just art), the motto is "it is perfect not when there is nothing more to add, but when there is nothing left to take away". This can make it hard to see why a design is good. The best way I've found is to try and copy an existing design, but only by studying it once at the start. When you're done, you can compare with the original, and suddenly all the artists' specific choices will stand out. Doing this to CSS Zen Garden designs taught me web design.
Is it worth it, though? Some people just don't have eye for it.
I've tried to train a musician for almost a year. He had the best of intentions, as did I, all with ample practice. In the end we gave up, he just couldn't hear when he's wrong. It's easier with programming - something just doesn't work as expected. Art does not work like that.
I refuse to believe in such an argument that some people just can't do something.
Some people just need _more_ time to get around the art way of thinking. In the case of music it maybe has to do with lack of early (as a child) exposure to more intricate music forms.
More complex programming also involves the grasp of a not evident way of thinking, so carrying on with your argument some people just can't understand why it doesn't work as expected.
Actually, I see your point at my faulty analogy with programming - conceded - but it's just what illustrates even more so my argument - some people just don't have mental capacity to do complex programming, and no matter how many hours they throw on it, it will still elude them.
You have a point that some people don't have the talent to decompose objects from their mind'e eye into basic shapes. I would argue that some forms of drawing are based more on practical skill sets, which can be learned, as opposed to the ability to detect the pitch released from a musical instrument. (I make that claim as a guitarist myself)
Trying to improve your drawing ability is worth the time and effort spent. I have been working on improving my artistic lens for the past month. Am I yet at the skill level I want to be? No. Have I sacrificed a lot of time? No.
I sit down once a day whenever I can find 10 minutes, set a timer, and sketch whatever comes to mind. On busy days I skip this practice, but always make it up in the following days.
You can see the progress in this imgur album: http://imgur.com/a/GTF6w#0 . These are by no means exact representations of the image in my mind at the time. On the other hand, they are quickly getting closer to my imagination everyday.
You should consider working with just paper instead of a some crappier digital painting program. You need to learn your fundamentals first & use a much better program.
Don't give me crap for recommending Photoshop because I use it and think it's bloody amazing with the things it can do.
I seriously recommend you pickup a trial of Photoshop and go through these,
- Learn some fundamentals anyway you can (huge number of tutorials for nearly anything online)
- http://www.wacom.asia/au
:: If you're doing digital, get a tablet from these guys. Go bamboo if you're not rich.
- http://www.ctrlpaint.com/
:: This site teaches you a fair bit about Photoshop and drawing in general.
- http://theroundtablet.com/
:: Awesome for tablet owners and if you want to tutorials from professionals. Also has some nice brushes from well known artists.
- http://www.thegnomonworkshop.com/
:: These folks are legendary. They're all over the industry & have some of the best teachers on the web. They cost a bit but it's worth it. Seriously recommended.
When I first got into programming it took me months to truly understand the purposes of methods/functions. I picked up on pointers quicker than I picked up on functions. This was a little over 15 years ago. I could write them out but I could not understand why they were needed. I can admit it now but it was embarrassing then. I know the problem now was because I was teaching myself and really had no exposure to the concept until that point. I was really bad at math in high school.
That is the same thing with learning an artistic endeavor. There are going to be even seemingly simple parts that some people struggle with. It takes time to break through that wall but it will be broken at some point. Sometimes you just have to advance past that lesson and come back to it. Maybe then the person will be able to understand why they were having problems.
True. Though, some people may seem hopeless, I've seen wonders by having people critique each others' work.
Developing a critical vocabulary is probably one of the most important things an aspiring artist (or even someone who wants to contribute) can develop.
It seems that you're talking about two different things. On the one hand drawing a technically competent picture and on the other producing interesting and 'good' art. While I agree that everybody can probably find mediums in which they feel comfortable and can grow within those mediums into competent artists, I'm still not convinced everybody can master the largely technical skill of drawing. Many good artists aren't very good at drawing.
As mainstream art and design in particular goes, I'd agree completely. Loads of feedback from beholders is what has made me much better designer, probably by orders of magnitutde, if such numerical property could be applied.
So how do you explain people like me who can differentiate "OMG the design is so 1995" vs "This pastel-colored theme looks rad!" but sucks when tasked to design it himself (end up with 1995 design).
You learn how to differentiate between good and bad much faster than you learn how to create good. Which can be super discouraging because it means that at first all it feels like is that you just keep realizing how bad you are and how much further you have to go.
Perhaps you were an incompatible teacher? It happens all the time. One size does not fit all when it comes to teaching which is why we're so hit an' miss these days.
I once took an IQ test (complicated reasons) that contained a visual acuity/processing test. My visual processing skills came in at the third percentile. 97% of the population has more brain ability to draw/"see" than me.
Strangely enough, I'm not blind or anything, I just tend to miss a few subtle facial cues or miss the paper I left on the desk, things like that. And I can't really draw worth a damn without employing a whole lot of technical practice.
* First we pick a nice API, let's see, yeah SDL with OpenGL is a good choice
* Let's create a full screen surface and set the happy little flags to make it a double buffer
* Let's just write some happy little class wrappers for our main game components. There we are.
* We start with a happy little box twirling around. Just gently use the OpenGL API and map the textures so that they fit. A happy little light lives in the upper right corner. Now lets add some other boxes over there.
* Ever so softly write some game logic. If you're feeling adventurous, try using multiple threads, but don't forget to use some locks.
* To finish it all up, we just plug in the user input. How wonderful!
See you next time when we write an operating system!