Rouge Type devlog 3.0 map is mazing but arrows arn't blazing

Wanted to give a quick update, learned alot following the farming tutorial, enough to get the first room started and mess with playtesting.

(great tutorial series, rather advanced for my level but still really easy to follow)

So, essentially I have followed this two part tutorial series, and a working randomized room. What I need to figure out now is how to make the randomize controller place enemies and other objects about the room, like exits and chests.

I'm not totally clear how I can plug in more random spawns in the room rn, so before I have a working project get stuck between another rock and a hard place I'm going to work on the bow and arrow mechanics. If I get  the particle drop on the arrows and then the inventory segments of the bow mechanics done I'll either explore the tile system again and see if I can get more items to load, if not I'll look at messing with the arrow physics. I still hope to have at least a rebound effect in the first open build, also being able to recover arrows would be very cool as well. 

Pixel tutorial

My ability to draw has always been hit or miss, I had fundamental classes in high school and would occasionally doodle, but always avoided the human figure because of its difficulty. And I still find it so, probably always will. But through doodling and what I retained from the classes I've taken so far in drawing I've picked up a few hints that helped.

1. Practice/mentality, it's a duh moment but it's true. Most important though is to practice the right way. When you're just drawing things off the top of your head and you're having trouble making them look photorealistic or "life like", then I suggest trying to draw something out of a photo. This isn't tracing, this is exercising the eyes' ability to notice and the hands' ability to translate that. Drawing is 99% in the head, and 1% in the hands and eyes. If you can see it, you can draw it as you see it. Where you start doesn't dictate where you end up. The trick is to exercise that link between the hands and eye. Seriously, anyone can do it. To quote Garfield from the animated series Garfield and Friends, "it's just lines on paper." And that is unarguably all it is, just like how paintings are just paint on canvas. And it's not in any explicit way of how that paint is put on, there isn't any technique or way to move that dictates how well the lines end up looking. It's in seeing what the lines do, and recognizing what that means in relation to the piece as being presented as you work, and keeping that in mind as you work. What this means is as simple as "that line on his ear comes in too far, makes his ear look too big".  And then making the line come in a little. That is literally all drawing is. A bunch of that one, line and alteration after the other until you feel happy with it. Reason experienced artists make it look so easy is they've exercised that hand/eye/brain coordination so much they can more quickly approximate what they see in their head on paper, where with the rest of us faces start off looking vaguely potato-ish, they know how to draw the right face shape from practice. Just like those pieces you see the tourists artists do in no time at all that come out looking good, they've practiced how to make what they see so often their hands just know what to do.

Now, I like pixel art for two reasons. First because regardless of how many mistakes I make the canvas doesn't show so I always feel in control of the finished product, and secondly because there is a total abandon within having definite color and space. I can pick this or that pixel to color, but no where in-between. I have a limited pallet and can only attempt to replicate a degree of what colors exist in real life. While, say, this image

has a massive number of shades of grey and very specific locations for the white flakes in his hair, I cannot hope to perfectly replicate that, but in pixel art I can approximate it. It will never be perfect, Wittgenstain is made of smooth edges and not squares, as is the tradition of pixel art I'm only using two colors to highlight the pixelness of it.  

  

2. The flatland. (I actually meant to have more photos showing my progress before this step --will do next time-- but I got distracted. )

This second aspect to art I want to use these early saves to illustrate. Make things flat. People often think they aren't arty enough to get the angles on a room just right and make 'depth' or just can't get the proportions right to make something look... not deformed. But the fact that your eye is able to pick up that you're work isn't 'right' just yet means you have the capability to notice what is off, with is all it takes with diligence and slight alterations to make something looks right. The easiest way to approach this is to flatten things. Drawing still life or things laying around the house is really hard because as you look back and forth you wind up moving your head slightly and because of your perspective the angles on the piece change. You end up constantly altering the proportions of the piece. With practice you can learn to avoid this. But for beginners or those trying to get a bottom up refresher of their abilities(which every artist should do occasionally, imho), start drawing things from photographs. Next is to break the image down into less complex shapes and distances. 'The eye is ovalish, half way down the head, a little squared over here..' ect. This is the same for the negative space. Instead of seeing where to put that tiny ear in relation to all this white, imagine figuring how to fit this large triangle thing between the shoulder and the ear. 'Okay it comes up to a little higher then half the image, bends right below the ear here and slightly closer towards the neck down here.' Start by building your basic outline and move in. Remember to strictly avoid detail work at this point, you're getting the layout of the image. Start sharpening the edges of that layout.

3. Details. Treat every detailed spot like you approached the general layout, start with the big stuff. 'this spot is all black' 'this corner is more rounded' 'this has little hairs sticking up' and then move onto more intricate stuff.

 (As a side note somewhere in the above I said there is no direct technique that leads to how a piece turns out. I kinda lied, the grey stuff is dithering, it's a technique of spacing squares in a checkered or 'cross' pattern to replicate shading. It's a way to keep the pallet color down while simulating shading, similar to crosshatching as seen in comics/print. )

The rest is the back and forth, glance at the reference picture, make a decision how to shade/represent what is there, look at the image see what could be wrong. When you are at this point getting a pair of outside eyes can be very beneficial, also looking at your piece from different angles i.e. turning the image and canvas upside down. Replicating something upside down is a common experiment in early drawing classes and I recommend it, by having a face upside down the brain doesn't so easily recognize it as a face and allows you to more easily see it for it's angles and edges. About here a talented artist friend of mine mentioned how not only was the chin far too thin, but the neckline doesn't go in so drastically, that the whole left shoulder (in relation to viewer) was in too far. Within the next three panels I work on correcting that along with other slight alterations with the eyes and brow. Then carry on to darken the dithering on the other side of the face, make slight alterations to the hair, and work more on the eyes. Click on the first image to be able to cycle through the images without seeing the text to see the changes better side by side.

A great way to break down the shading in a piece, especially a monochromatic, is to squint at it. Or in my case take off your glasses. The details get lost but suddenly the overall shape and shading becomes more clear (in a manner of speaking). A pixel art piece of an image is in a way already a blurred/distorted version of your image, so when you squint and compare the too your eye will better see the features that translate and more importantly where they don't. Try it out: comparing the bottom two, the original image and my piece you'll notice the bottom Wittgenstein's nose is much darker, that there's less shading on his left ear, and that his chin doesn't extend quite so long. With open eyes of course his left eye needs work, it's not clear where his eyeball and eyelid start and stop as it is with the right eye.

You'll notice the comparison is far from 1-1 but it is an approximation. There are light spots I couldn't figure out how to represent near the right side of his temple that I excluded altogether. The dithering more lends itself to suggesting the details and shapes of the face then replicate them. Now the point of this exercise specifically, to attempt to approximate another image (instead of simply creating an image from imagination) is that this teaches the eye how to see in terms of simple things like lines instead of difficult things like faces, and it teaches the mind how to use your medium in approximating certain effects. When your mind and eyes think in terms of the medium you use and you will be better able to clearly imagine a creature in a way to translate it to the paper... or screen.

Until next time, thanks for your time, good luck on your art and goodnight everyone. 



YOU CAN GET THIS PROGRAM FREE UNTIL THE SECOND OF MARCH 2014!

http://www.yoyogames.com/studio/download

Typically a 35 dollar value GameMaker Studio is free to download.. Like right now. I'm no pro at GameMaker, but I've downloaded it an it's on the list of program walkthroughs I'm going to do. Get Studio now if this one catches your eye, if you're ever interested in investing in something it's always better to do it when it's cheap, and if it's free you should just do it incase, seriously. For those of you who roll there eyes at these programs and just want to get into the ground up programming world of game making, I do getting into Java and JDK eventually. Soon as I'm proficient enough with coding, but for full disclosure that really means as soon as I'm not juggling upper level courses with work.

Update on the game stuff. I'd love to say the first engine is complete, but it's not. It's simple a matter of understanding the rolls of in script functions and how they function (which is kinda funny in itself). Quality tutorials for Construct 2 are a little more difficult to find, I'll be putting up the resources I've used and a in depth of the game development soon. 

Learning Construct2- 101

Such Basic 

Now the great thing about learning coding with Construct, is that you're not really. You are, but you're not at the same time. In a pervious post I mentioned how game making programs like Game Maker, Game Salad, MMF2, and Construct 2 support this kind of psuedo-code. In Construct 2 these are called events.

^this is what they look like

The usefulness of this pseudocode is to condense the functionality of actual code into small bite sized re-arrange-able puzzle pieces. This makes the function and logic of basic computer languages much more accessible to a wider audience. It's like Duplo for programmers.

And while this looks approachable and easy as pie (and it is), but it's not really. This is a simplified translation of computer language for human peoples, but that doesn't change the fact that pseudocode is still a computer language and structured in computer logic. Which means their will be times you think you have everything set up correctly but while testing out your double jump your character floats off into the nether. Computers are like little evil minions, they'll do what you tell them to.. exactly what you tell them to, without understanding the context of what you mean by it even if you think it's perfectly simple English.

I know this sounds really obvious, maybe even patronizing, but if you're just starting out with Construct or any game making program, or you've been toying with it for a bit but still are having weird glitches where you don't know what's wrong with your code, please read the manual. (here is C2's) I'd love to say, "I can't tell you how many times I was close to finishing a project and going back to the manual saved my game." but I can't because I'm one of those stupidly stubborn learners.

I want to be able to watch someone do something, try it myself, then look at my finished product in comparison to someone doing something harder. I want to learn by my mistakes that way, to learn through hands on exploration and observation. When I got my lego sets I'd skim the instructions but always try to finish the set by using the cover and what I already understood of building. As you can imagine I'd often make small mistakes and end up having to go back and rebuild some big thing because I used some wrong brick someplace and be one square off. Bit of an awkward simile but the issue is the same, if trying to skip steps you won't really be able to manipulate the tool the way you'll need too to. I just can't stress this enough. It's not saying you won't figure out all the small stuff inevitably through other user tutorials or asking these people, but typically it'll be something basic that is in the manual if you give the manual some love.

Trying to make a small indie game title without really studying up on the tool you using is like trying to self publish a short story you wrote without really learning grammar. It's likely to not pan out for you, and if it does it would have gone so much better if you had just taken the time to sit down and do your studying. I know it's one of the tedious parts and you just want to be making your game, but I promise you the reward is by far worth the effort. You know that great first moment when you got it to make stuff move onscreen, when you got the enemy AI to respond the way you wanted, or the animations were synced with the differing inputs correctly for the first time and the small blurs onscreen just popped to life? That will be so much rewarding if you are confident in knowing how all of those small things worked out. And secondly learning the how is not really even the tedious part, the tedious part is when you have a working demo, a well polished engine and intro level.. and then realize you have to develop the entire rest of the game. All those levels and those extra inputs and balancing the enemies and complexity curve, and plot exposition. And even more tedious after that is the 97% completed -I'm-sick-of-this-project-now- final bug fixing and edits before sending your little creature out into the world. But that's for another time. First learn your program and build that sweet sweet engine. Play test frequently and never give up. Good luck with your projects and have a good afternoon fokes.

So I'm making these things again.

So after not really being able to wrap my mind around code. I opted to step it back and start simple. Something I typically try but end up trying to sneak in more features then a program is flexible enough for. And by that I typically mean doing so meant a more code heavy revise than I could handle.. But I think I've found the right thing. And I think this might be the hardest thing for starting up designers (or those of us that have never finished a project on our own), you need to find tools that are simple enough for you to wrap your mind around using them to create your idea, and the tool has to look simple enough and be the least amount of threatening on approach that you don't feel intimidated and overwhelmed when learning.

I found Ags.

And I was draw to ags initially the way I am typically drawn to something.. it was free. Spending the time to download and drudge through the tutorials is some of the best time I've spent. And I say that as a poor, currently under-slept, not quite starving college student. It's break right now for Christ sakes and I can't get myself to sleep in. I'm super excited to have one of my old designs not only off the back-burner (as I now have tools to slowly coax pages of scribbles into sweet digital life), but not just off the back-burner, but to see the tools at my disposal and realize how very doable this vision is. Often with a design orientation, you get an idea for something --and any good designer will tell you, it's not the thing that matters it's the manner in which it works, that makes a truly good design-- and when you don't have any training or understand the vocabulary of how your pen works(coding; in a manner of speaking) then you have the assumption your grand idea isn't possible and is too complex mechanically. And that's what I had thought for the longest time with many of my designs, so what did I do. I focused on the gameplay, the input output relations with the player and the essentials of what really made something. Because if I could figure that, and break a game down to it's smallest components, and then possibly get myself to the point of building those components, then I could design a project solely around that singular component, and then with time build on new features learn and work up to an engine that I could use to build the stories I wanted to.

Once to build a metroid-ish/brawl platformer I started the designs for five separate titles that slowly scaled back the functions of the game until the one I started working on was literally two frogs that could either step forward or backward and were fencing with their tongues. Like a dive kick game, but it's step forward or step backward kick. Attacking while stepping forward made a simple straightforward thrust. A backward step with a attack would make a sideways slash that could parry a hit. That was it. You would go forward in an attack or move back to defend. 

And really, I'll probably end up using that same strategy to make my final products, lord knows it'd help fill out the empty file designated for finished products.

Any finished product is a trophy in itself

But my point is, it's nice to know that the set of stairs that lead to your dream projects aren't always as massive as you think. Dream accomplishments aren't nearly as impossible as we think, the tasks are actually very human and legitimately possible.

And, my goal on this blog now.. along with using it to help keep me honest and frequent with my internship writing. Is to show off how possible these dream projects are. I've always been a massive fan of Wolfire Games' marketing strategy of showing start to finish because I know how much that meant to me when I was first thinking of game design. That sudden realization that follows being introduced to your deepest dream activity as a realistic profession, "Crap.. this could be what I do. Even if I need to do a second job, I could be doing this. I could be making those kinda things." That realization that game design and creation wasn't... it wasn't something so out of reach, not a "I could never do that.." situation. And when I first saw those games being made, when I followed the squares on screen betas turn to polished alpha releases, all of that just got me so excited. I spent.. well I haven't stopped thinking about games. Not just as a retreat, or pastime like they were before, but as my worlds. Instead of retreating into a book or movie or game like it was a favored place to be comfortable and be myself in, I started retreating into these as if they were close friends that whispered hints and tricks about how to excite the audience, make them laugh, or make them care. My notebooks at school actually started being used.

BACK ON TRACK

So, soon as I pull together the braincells to figure out fraps.. (probably lost half the audience, I swear I'm not completely incompetent), I'll record myself working on this project. Possibly do a tutorial session about everything that goes wrong and how to trouble-spot where you're going wrong.. because I think I've run into almost all of the most basic ones and in trying to find what's wrong realized there isn't a single person on the internet who was simple enough to make the same ignorant mistakes I've made. Thus far I've figured all the problems I've run into by myself (I'm very proud). There will undoubtedly be more in the future. But for now I'm going to upload and dictate my design process, both selections from my notebook on how I'm mapping and keeping track of the perspectives. And mentions of what I learn, as I learn the AGS editor and coding tips and hints.

-My first error, which was one of the most frustrating, was the room I had created was unable to load the background image I had drawn for it. Which was frustrating because I'd go back and forth between the general settings and the image I had made because they were the same size, pixel for pixel; and the computer told me they weren't. The issue had been, of course, the room actually wasn't the same size as the general setting, this was because after I had made the first room I changed the general setting size. This was because I made the room, checked the size, looked at my image editor and realized I wanted it bigger. The rooms are built off the general settings but once built isn't linked to those general settings anymore. The resolution does not bend back and forth to my will in these separate rooms. So basically all I did was delete the room, remake it, and the image worked. That took me two days to figure out. I want you to see me in all my pathetic glory so when I have something to show and you're first reaction is "meh, alright.. that's kinda neat." You'll see how far I've come.

-And here's my coup de gras, or at least I hope it's the most facepalm I get learning this... Facepalm.. Facepalm Games.. that's what I should call my youtube development videos! You see you have to find a way to make it fun, you even have to make losing fun, with my history of game making, this is going to be a whole lot of fun.

My coup de gras was I couldn't get the inbuilt editor to draw walkable areas. I'd select every tool in the little bar, draw rectangles, draw line tool, draw pen tool, and all those other things.. I don't know what do.. But anytime I'd try to draw on the page it'd tell me that I couldn't do that, that I had the eraser selected. And I'd get very upset because I didn't. And it was saying crap about a properties plane, and I couldn't find what they were talking about. It made me very upset, but I had seen the light at the end of the tunnel.. this was possible and this design has been brewing in my head for almost two years, the functions I thought I couldn't do and the art-style had been brewing for four years, and that functionality was literally a number of months of work away. It was possible, I was just being ignorant, and I'd make it work. Enter roughly four days of doing almost nothing but fart around on my computer trying different things on the editor and having five tabs open looking through basic tutorials later I realized I had the properties of the room set on Walkable Area 0... as in no walkable area at all. Meaning I wasn't drawing.. which would automatically set the pen to a function that wouldn't work. 

  

No matter what you start learning, you will always start off making mistakes you will laugh at in the future. So enjoy it, realizing painful ignorance is the universe's way of making learning fun.

My next hurdle.. along with everything coding. Is to find a good paint program to get the kind of pixel art I'm looking for. So far I'm using Sketchbook Express 2011, and with some farting about I might be able to get the precision stuff that I want but right now the settings are giving a difficult to control --as it's designed for tablet and pen(a set i don't really have)-- and faded soft brush effect in the lines. And.. well I'm looking for more pixel accurate hard color effect. Plus this isn't a program everyone can download. So I've downloaded and will come up with a review for PixelStudio next post along with more on the Island.

Goodnight everyone, good luck with your projects.