Friday, February 21, 2014

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. 

Thursday, February 20, 2014

THIEF - Launch Trailer Thoughts/ Discussion on Stealth





In all honesty small response bits aren't my thing, but I figure as my commentary on design and production come from my personal experience with games I enjoy and making games I'd enjoy I thought it'd be good to include that other end of the spectrum. Traditionally indie development blogs showcase the creator's specific thoughts or commentary on whatever aspect of game creation they're currently working on, but they can also showcase examples of successful handle..ings of whichever specific content. The thief series is one of those good examples in a number of different design aspects. One of my personal favorite where it shines is "How to deal with open world without having the npc's become background fodder." or a little more face value "How to make engaging stealth." We're going to look at the latter for now.



One of my favorite aspects the stealth game -especially one of the former Theif series-  provides is this sort of player distinguished challenge. In stealth games the player has the option to wait and avoid detection, even if combat is imbalanced or the ai is boring, the ability to wait completely changes the dynamics of the player within the game environment. In the first Halo, on the snowy level there's a room right before the bridge where most of the enemies are asleep(I'm siting this from memory if details are off I apologize). Now, while most of the Grunts are asleep there are two patrolling Elites that upon spotting you will yell, fire their guns, and wake up the rest of the enemies in the room. Halo does not have refined stealth mechanics, it is not considered a stealth game; but as ai is triggered of line of sight, there is a crouch that aids avoiding being spotted, and gunfire triggers enemy agro, the game sets up scenarios that enable stealth gameplay. You could argue that every shooter has this and yet we don't consider every shooter to be a stealth game.. And I agree with you, the focus of using Halo is to break down stealth into it's fundamental concept without any refined polished mechanics so we can focus on the dynamics that occur in gameplay.



The first thing to note about this dynamic that results in a game being labeled a "stealth game" or having "stealth elements", is entirely dependent on the level design. Someone could just as easily take a Mario platformer -or any platformer- and design the level layout and the enemy placement to completely change the way the mechanics are used and turn it into a stealth game. This brings us back to the waiting element. The ability to avoid detection in itself is considered the most important element, the make-or-break, feature that decides the classification of a stealth game, but in truth it is only a half. When creating "stealth" mechanics the ability to avoid detection is only as good as the manner the game's layout presents waiting. These two elements are often treated as the same and in an aspect cannot be separated, but to better diagnosis the success of a games "stealth" they must be understood independently and viewed side by side. Like the chocolate chips, and the cookie, experienced as one and the same, but very different.



The quality of stealth in a game is understood to be predicated by the strength of the game narrative of why the character must hide, the exact context of why the player is avoiding detection. This brings an investigation of the game's specific fail state. In our Halo example the failstate is clear, you've woken up all the grunts and now you have to chase them around to kill them where before they were lined up on the floor for you, obviously as well there were less enemies previously so there is the threat of death with a harder difficulty setting. In the long run, that extra work of crouching and moving around the room to avoid the Elite's notice, and sneak up behind them, then sneak around taking out the sleeping Grunts, to accomplish that takes loads more time and energy with a minimal internal reward (having not spent those bullets). In many of these instances the player is purposefully setting the bar much higher then necessary with no tangible in game reward, without any provocation from the game. When you walk out of that room there aren't any gamer achievements that pop up for "no shots fired" or "silent death", the challenge is presented the moment the player sees the sleeping Grunt and the patrolling Elite. The layout provided a kind of telescoped game condition, yes the immediate game is to kill all the enemies and survive, but now can you do it without anyone noticing? Mechanically it's just another shooter but the game play allows for conditions to be set on-top of that, it's the level design and monsters that can then add stealth elements. Again, not the fact that you can avoid detection alone, but the manner in which you wait while avoiding detection. Look at Grand Theft Auto, there are no instances where anyone would confuse it with a stealth game, even though the notoriety bar is by definition a stealth element. If viewed with that feature alone it could be said GTA is a stealth game about hiding in plain sight, but we don't consider it a stealth game. Probably because if we're on a empty rooftop then fire off a sniper round toward a playground two miles away and take out someone the police are still on your case in five seconds. I mean really, Oswald got more time then that; there was no way they could respond that quickly. The line of sight is completely bogus, where I should have been able to hide on the rooftop without notice, the cops should have logically been running around the streets and alleys looking for a shooter for a set of time. But that didn't happen, the manner of waiting and ability to hide are not set in a way that allows "stealth" gameplay.



Even more misguided on this manner (in my opinion) is the Assassin's Creed series. This is more to a broken sense of failstate then anything but in this case the open world doesn't help. To be clear, I have a love hate relationship with this series; I love half the things the games do, I love the subject matter, I hate half of everything they do and the way the do half the things I love. Example, why be able to pick up and carry weapons without being able to unlock them, or at least sell them at the stores to then turn around and unlock them, and on that note why the hell is there even money when the stupid homestead is going to be making it rain a third through the game? If the player never worries about their in game coin purse going empty then money has no worth and basically no point. While we're no the topic, if the player can kill people -especially the heavies- quicker and more efficiently unarmed then actually armed with all the big expensive weapons, then what is the point of buying the weapons or even having them? Yes the combat alone is fun, but by making the unarmed option more viable the game undermines the entire point. And if you can stake up bodies and bodies of enemies without much hassle, what is the point of hiding? Now there can be instances where patrol routes and hay stakes are cleverly placed, but often times there the reason for not being spotted isn't a manner of avoiding fights, it's just this is what you've been told to do. If you get spotted it'll just give you a failstate and start you over. This feels less like the "stealth" dynamic and more "wait until they've lined up with spot a to press x" which functions more quick time event then.. well stealth. Just.. just don't get me started on that series.

Thief does it right, they focus the environment and interactions around their stealth mechanics. Where sight and sound play key roles in coming into and avoiding challenging combat the player abilities are all based around manipulating the environments visibility or sound, the objectives are set up for multiple entrances and the ai designed provide a multitude of approaches. In an article (in GameInformer I believe) a designer commenting on the Thief series said they figured the best way to present a realistic challenge to a burglar was to have a "simulated environment", everyone is just going about their business. If they find someone knocked out and mugged in the street they'll get the law. If they find a door closed when they had left it open they'll open it and look through the room. If the light in a room goes out they'll become more aware and look around and listen to see if anyone is there. If they're not a guard or armed when they believe someone is there they'll run and get someone to come back with them. The player is presented a challenge strategic challenge in the number of ways they can approach and deal with their obstacles, all within the bigger goal of stealth. In another game not being found might be a lesser thing, but in Thief where you are not the hulking warrior and any hostile creature has the potential to kill you, it becomes an immediately bigger thing.

.. trailer analysis.

There is gameplay in the family of the Thief formula, (the sneaking climbing bits) but the other thing that's noticeable is what appears to be either one of those (not actual gameplay/looks like gameplay ) cinematic trailer, a taste of what we might expect for a cut scene (doubt it seeing as there were other blatantly cut scene bits that fit existing Thief formula), or -more likely- a cinematic with what we can expect from scripted parkour/timed run segments (reminiscent of Mirror's Edge). And that is has strange effect on me, on one hand I really liked how Thief didn't have scripted gameplay events, sure sometimes the best way was to enter from this door, but there was never timed running bits with quick-time-event-slide-over-tables bits or anything, it presented a kind of freedom. But on the other hand, I reeeally liked Mirror's Edge and felt it's timed run segments were compelling and challenging, you had to think fast and preform the movements exactly. While that doesn't sound Thief to me, that does sound like a fantastic marriage. If this is the case I'm going to be optimistic and support whatever union of sneaking thief and parkour Eidos and Square dream up, until it proves otherwise. From what we've been given, in my opinion, the game looks like alot of fun. I just wanna wish best of luck to the developers, and God please let it be as good as I want it to be.  




Thursday, February 13, 2014

Valentines DeconstructionCraft- Games and Romance

 (click to take me to article)
(click image to go to article)


So as this Friday-tomorrow- is Valentines day Kevin of NextLevelGamingOnline's DeconstructionCraft and I wrote a combined piece on romance devices as they're represented in video games. Unfortunately the site doesn't actually acknowledge two authors so we had to include that bit in text, but that's fine. My bit builds of Kevin's work and introduction but if you're just interested in skimming mine is the second half. Kevin references Final Fantasy 7 and 6, along with Second Life. I comment on relationship mechanics as they're used in the Sims, Catherine, DragonAge, Animal Crossing, Mass Effect, Harvest Moon, The Marriage, and Ico.

Sunday, February 2, 2014

2014, The Year of Pies and Fingers.

With my first class of the semester just a few hours around the corner and a few elements of my platformer working I just wanted to take this time to throw out my game plan as far as game development goes for this semester.

I've decided to aim to develop three games this semester using the respective optimal programs for their development and record my progress and lessons learned here. One platformer, one rpg, one adventure game. Each using their respective suited creations software; Construct2, Rpg maker, and Ags. Each will only be using the most basic elements of gameplay from their respected genres that I can code without too much difficulty so I can focus on the design during development and come up with the most polished product possible.

Still, this is kinda nuts -for me at least- I'm a full-time student, have my game journalism column with Kevin along with my other duties at that internship, might help write for my friend's film journalism internship group, I'm getting a second part time job, and I've joined a band. But I'm still optimistic, second job is a every-other-Friday-or-third-shift kinda deal, my classes are basically condensed to two days through the week, with a one-class-easy monday/wednesday/friday, my other job is flexible, all of my classes are interesting, plus I've found awesome communities that can point me to tutorials and so far have been more than happy to give me advice and pointers on my work. The planets have aligned as it were. 

My aim is to learn as much as I can and develop my skills so that future design ideas can be realized more efficiently. The benefit of making a number of small games when first starting with a program to making one massive one is a stark contrast. When you spend half a year making a single(conservatively saying) big game it's going to take you much longer to distance yourself from the work and be able to reflect on it's flaws and missteps. You often hear developers talking about the benefit of having gamejams and having to fit some awkward random parameter in some genre they're new too. It challenges you and makes you think about the process and medium in ways you haven't before. The same way you hear writers often tell people the best advice they could give to a fledgling author is to read books that are out of their genre or style. Short projects that let you brainstorm on something completely new then see it through to completion without the time or luxury to spend time second guessing or last minute revising help build confidence, familiarity with working the crunch, and understanding of the development process.

And so in this fashion I'm going to be tackling a puzzle platformer, a turn-based rpg, and something in ags... just kidding it's going to be a point and click adventure game. I barely have the slightest knowledge of ags scripting and I don't have any Rpg Maker sofeware as of yet. But after fuddling around with Construct for a few days I spent today.. yesterday. Sunday, working on an engine and thus far I have

1. functional wall jumping
2. invert-able gravity 
3. button mashing type flying (broken double jump)
4. self destruct button (broken dash, soon to be fixed)
5. rotatable characters (no ai to have secondary character follow you around thus far)

But that's just one day. I plan on spending a week on each engine, getting what functions and place holder graphics I need working, and anything that's glitchy/unfinished/I-don't-like will be either removed or disabled from the code and I will use whatever I have to come up with a design. The design will be scaled on my remaining time, and as I plan on fitting these out across the semester the first two at least will probably be pretty small scale. There are really only two functional elements in the platformer right now but I'm getting a good arcade feel from it. Rpg will probably be a small mystery as that's a simple way to have a concise story wrap up at the end of a puzzle/dialogue session, it'd be rad if I had time to figure out a multiple ending sort of thing. And to be honest I have no idea what to do for the Ags and that's why I'm going to schedule it for last.

I'm not going to set any publish dates or anything like that for the individual titles. I just want to have a working beta of each by the end of the semester. There is the possibility that I will fall on my face and fail halfway through. I might end up with just three somethings that play kinda like games, but regardless of the physical product what I'll have learned through the experience gained as a developer will be immeasurable. 

Other great advice is have a good programming friend who can look at what you do and give you pointers, one I've chatted with mine and get those broken bits fixed I'll put up my links to the tutorials and include my own commentary on this platformer engine I'm making. I'm thinking something end product like Wario Land but with a gun.

Til next time, goodnight everybody and good luck with your projects. 

Friday, January 31, 2014

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.




Wednesday, January 29, 2014

Design Sense

TALKING ABOUT DESIGN. WHY DESIGN?

At one point in time, while talking about game making, someone told me the only safe career pursuit was coding. That the coding was any game's live blood and without programmers you wouldn't have any games. This was brought up because I mentioned I do the writing for a group making games and that I consider myself a game designer, and occasionally artist, who has little to no understanding of coding. Which is why I've had such trouble physically finishing any designs. The chap I was discussing with called writing and design the easiest part. I don't know about that. Now I might be wrong, some things come easier to others so for him they might be the easiest part. He could have his coding down, and a natural grasp of story and the design talent to back it and make functional beautifully thought out interactive experience. But for the most part when people say writing is stupid easy or think that coming up with a game that sells million copies first week is just stupid obvious, are the kind of people that have never done those things. Like, they think writing a best selling novel is really easy because they haven't written much so they don't really know much about writing, and chock up the art as a simple task. They misinterpret the aesthetics, the visible content, for the craft of putting the content together.

Say we're talking about a novel. What makes the novel great is not if it has robots or werewolves in it, or even the grammar. It's the way those things are presented that makes it work, it's the pacing and use of story devises. Understanding how the reader will feel reading the work, what and how they'll think while you introduce characters and elements. It's not solely the characters or elements but the significance in their use. Everyone has read a good book (I hope), and everyone has read a boring or dull book from the same genre. Even if the grammar in both was perfectly fine, if both books had gunslinger good guy, a hot distressed victim, an evil as sin bad guy, with a three act structure, and a hero sacrificed conclusion; the good book would never be compared to the bad. No one who had given either any consideration would confuse the two. When asked what's different, you might hear "This one's just got an awesome hero, he's super cool, and killed like thirty badguys. The other killed a bunch of guys too but he's just kinda lame." We've all had those experiences where a book or film just kinda "tell" us we're suppose to like hero X or think they're the coolest but we're just not into it. You can have as many special effects and good actors in a movie, but if the story is terrible and the character's are compellingly written, the movie will be rated poorly. Now that has nothing to do with someone's sense of grammar or including cool stuff, that's the result of design. Great stories are great by their merits in design and execution. Those two things just cannot be divorced. You can't make a classic book out of great storytelling but bad grammar just like you can't make one out of good grammar but bad storytelling. Personally I feel the great storytelling will help a book/movie more then good technical execution. Poor special effects and filming is something you see everywhere in cult classics, but if the story is soulless and poorly shown you're going to have a harder pressed time finding fans. Look at the 5 dollar bin at your local Walmart.

Bringing this back to games, I'm comparing grammar to coding, and storytelling to design. I agree with the individual that coding is the lifeblood of games, but if that's true then the art is the skin and outside, the story is the animal's temperament, and the design is design of the actual animal. The design is how the internal organs work, the system of how the animal moves, what the animal does. How it frightens it's predators, finds it's food, survives. Think about animals in a design sense. Animals that were well adapted and had a design that was well suited for the environment keep living, others died out because their design wasn't suited for the environment. Sharks are really, really old, they're still around because to today's standards they still do what they need to. Like how classic old games still stand up to today's standards as engaging and fun. 

What's Going On?

I think what's happening typically when consumers or starting up game developers misunderstand and dismiss the term design, it's because they haven't been given a context to really see design as what it is. Like learning English someone points at an apple, says apple, and you think apple just means red fruit. It's more than it's surface material. There's more to writing than just put words on paper and more to drawing than just lines on paper. That's not to say they can't design. It's just they're not as aware of what they're doing. Like people who can sit down and play something ridiculously complex off the top of their head, completely impromptu on the piano without ever taking a lesson. That doesn't prove that musical theory is bunk, it proves that it's something innately appreciated. You don't need to know a think about music to appreciate Queen. You don't need to understand or acknowledge all the little bits of brilliant in a Miyazaki film to be drawn in. None of that's important because design is an invisible art, a soft science even. You enjoy and are drawn to a well designed advertisement without ever knowing it. We're bombarded with thousands of logos and graphic art a day but will still notice a well designed image dispute ourselves. We'll categorize that image and remember it for years to come without giving it a second thought, not because we tried to remember it, but because the designer knew what he was doing. Design is a thing you enjoy effortlessly, good design is something you barely notice. You might internalize a general understanding and design sense by being exposed to a medium, but then might not be able to explain later why something is bad. You'll know it's bad, but you might not be able to exactly articulate why. 
"How was the movie?"
"It was boring."
"Why?"
"Just was."

Everyone who makes anything is practicing a level of design. Anything creative is designed and could have it's merits judged by it's design. Everyone who makes games is at worst and amateur designer. I'm not saying this to make a point about designers being the most important people in game production. No, I'm just saying that what being a designer means isn't what people always think it is. Design isn't an idea, it's the execution of an idea. It's not "Game with werewolves and guns!", at it's simplest it's "tower defense, werewolves", and that's the basic idea you start with. But throughout the production you're making more and more design choices. Level design, deciding what to include or exclude to balance complexity curve, gameplay, the interface, the guns work, the way the enemies work. Yes without coding you wouldn't be able to translate that into a functioning game, but from start to finish design is implemented throughout the game and has direct effects on the game. That theory I have with storytelling and grammar in books is the same with games, how many times do you pick up that great old game you love that has the occasional glitch over the brand new one with the uninteresting gameplay? You never pick up that last one because you traded it in at Gamestop or where-ever. 

Design isn't just 'idea guy', and if you're getting into game making thinking it is, you're in for a sad disappointment. Design is something that every contributor implements in their part aspect of the production, game design means the gameplay and the level design. To me design is all I really care about in a game. If a game has a fantastic story or art but cannot draw me in with it's gameplay I won't care to continue playing. If then the art and story are created perfectly to fit with the gameplay and paced well within the levels, then there's a game I love. 

When I'm working on a game when I feel the most alive is when I have the squares and pre-art bits moving around onscreen in the way I want them too. Transitions, puzzles, effects, controls. In the back of my head I have all the art assets, but those are just the skin, what's really happening in a game happens by design. Of course none of that happens without the rest of production. Squares are nice, but can't always convey a meaningful experience like art and sound can. Think of how iconic game music is, think of how popular sprite art is in gaming culture. Think of well written stories and how that contextualized fight scenes into an epic experience you'd come back to again and again. Then think about how none of that would be possible without lines of code.. complex.. computer language. You can't expect to divorce these elements from each other and weigh one or the other as more important.. well.. actually you can have a game with no sound. And then they have made that one mobile phone game where it's pitch black and you use alone to figure out where you are in the digital world... that's such a cool design. 


OKAY.

You can't dismiss the design side of games any more then you can dismiss the technical side. It'd be like removing the rules of chess from the physical board and pieces, or taking the physical construction and pieces out of the equation and just leaving the idea.. it's just not possible. Either way, you wouldn't have chess. Even if you were to try to image a game of chess you'd need to imagine physical properties to conduct the game. The aesthetics are a softer element of production, but just as vital. Dwarf Fortress depends on it's graphics as much as Minecraft or Super Meat Boy, without their individual aesthetic sense the games wouldn't be as iconic or convey the same experience they do. If you thought Mario, Zelda, or Pokemon could be the same without their musical numbers then you're wrong.  

I know they're old videos and everyone's seen them, but a great study of design in the way it effects game experience is Egorapter's Sequelitis series.        



Thursday, January 23, 2014

Gotta Walk before you can Crawl

Reverse That

So... learning pixel art and design. Code still looks like Russian to me. In what way can someone utilize and test their abilities in the design/writing/art section of game making without yet understanding the code, the very life blood of games? Well there are two possibilities, either A. you work with a team where the code is not your responsibility. This is good because you can hone your specific craft, the issue though is you are reliant on first a finished product to test your work in action and second forced to wait until a certain point of production. Games evolve as they are made and sometimes entire sets of art assets become useless if the design changes. What an artist or writer or designer wants, is to have something tangible to show their work. An actual game that functions as such to display their work, otherwise their craft isn't as well represented in portfolio (and obviously this is less the case with artists or musicians whose work can be appreciated separately) but design in interactive media needs interactivity. Even if it's just the menu buttons lighting up as your mouse hovers over them.

Option B. the artist/writer/designer can find a program that requires no code(or little) to create functional games and have at it. 

And that's sort of what we've been trying to do here. Find the easiest way to make games. Just to be clear, the truly difficult part -the area where a game becomes great or crap- is not in the tools but the creator. Card games are crated with paper and ink. Board games are cardboard, ink, and bits of plastic. The average Chess game is just made of bits of wood and cardboard, and yet that's been around for centuries. My point is the tools do not dictate the quality of the product. Someone can have the best equipment in the world for digital art and still come up with something that looks like junk. Back in the day graphic designers use pen and paper instead of illustrator and the existence of illustrator along with all of its tools have not lead to better graphic artists. 

Anyway, previously in a discussion I had heard Construct 2 mentioned. Previously I hadn't head of this program and at first glance figured it to be the same as MMF2, which dispite all of it's pros is still an expensive bit of machinery and therefor out of our running for "easiest to start making and learning about game making" contest. Ags is great and I'm loving the community, but there's still a decent amount of code required. It's inescapable. 

Or is it?

The reason I advise people use programs like MMF2 and (as far as my limited understanding) programs  like GameSalad, is because they have this sudo-code. Underneath it's the same code that makes any other game work, but it's broken down into symbols and an easily approachable interface. This teaches code logic, which if isn't later used to understand code in it's true raw form can at least bridge the gap between you and your coder when communicating in production. GameSalad is one that's free, but right now we're going to take a look at Construct 2. Or at least I am.

Here are a few games from a person I follow made using Construct 2
http://supajackle.tumblr.com/backlightbig
(personal favorite of his work)

http://gamejolt.com/games/platformer/hero-quest/16821/
(I get a bug with this one but idk, maybe it's just my computer)

http://supajackle.tumblr.com/PixelGame

http://supajackle.tumblr.com/post/45430588965/porterminus-a-spooky-rpg-by-supajackle

 Here's the link to their site where you can download the program. 

Great things one, the interface is easy to understand, it comes with it's own paint image editor which is also easy to grasp. Great things two, it starts out offering a list of templates to chose from, not just get a head start templates for making top down shooters, path-finding, physics, or platforms, but templates to make your game work on Facebook, mobile devices, ect. 

Personally I'm hesitant to jump onto another program, I'm trying to figure out two different programs at once. But really few of my designs are actually complex. Most of the ones I have now are just platforms or beat-em-ups, the big ones.. The ones that are going to take a while use Ags, and it'll probably take me the twice the amount of time to do the art then it will take learning and coding the thing. And with school and work, if I were to throw out a number of when I'd finish that game it'd be someplace in the years category, even if I weren't doing the coding. And while the payoff will be awesome until then the work will be rather slow. Not to mention this blog, besides the DeconstructionCraft notices how much can I say about a background having a bit more shading or a single line of code being added. Development on.. I'm just going to call it 'the Island' project will be slow, and I'd prefer if I can have more regular activity on here. I think I'm at a point in my "career" I just need to make games. Yes I have a group project going on and this big project of my own, but I need something consistent and easily completed. Ags would be my tool if it was more oriented for platforms or the like but it's not, and C2 is. With school coming up and other messes that require my focus irl I'm going to be posting for a while about Construct 2 with the intermittent updates on Ags and what I've learned there. Soon as I can figure out fraps(this is the kind of simple you're talking too) I'll start putting up let's draws or tutorials or speed production vids. But for now I'll just be written bits with the occasional screen-cap. 

Until then, good luck with your projects, and goodnight.