Contact Info / Websites
So last time I participated in Stencyl Jam, I believe it was for a major version release. I want to say 3.0...? During that time, I discovered for myself just how unoptimized it was, and at the same time, someone released the flash version of the original inspiration for my game. Comparing my in-development Stencyl build, and the native Flash build just led me to give up on the Stencyl Jam.
This time, it is a Stencyl Jam for the 3.3 release version, as far as I know. Or it could just be a promotion, I don't know. I intend on completing a game this time, and I have some peers that I'm trying to pressure into helping me :D
The goal for this project: a metroidvania type of game, with lots of puzzles and lots of elements. All my ideas in the past have been too ambitious for the platform I was trying to make it on, so this time I'm going with a tried and true formula, no bullshyting with prototypes.
And here's the schedule I expect:
- 3 days: Learn Stencyl basics (again), discover just how bad it is again. DONE. Gotta admit, they got their act together when giving people options that are much less loaded, computationally speaking. It's far from bug-free however, and their code API is still consisted of 95% function signatures and 2% actual description.
- 1 week: Get up to speed with what Stencyl's capabilities are, by building rooms that contain the puzzles and mechanics that are intended to go into the game. Get some sound and art guy on board.
- 6 days: Create a design document, including the expected sequence, and mechanics.
- 2 weeks: Plotting and creating the playable world. Maybe throw in a story.
- 2 weeks: Playtest and polish the fk out of the game.
That said, here's what the actual schedule is probably going to be like:
- 2 weeks: Get up to speed with what Stencyl's capabilities are, spend 75% of that time trying to figure out why things aren't working. Hooray software development!
- 4 weeks: Abusing agile design practices while trying to grind out the game. Get a sound and art guy on board.
- 1 week: Playtest and polish the fk out of the game. Realize the deadline was passed.
Wish me luck!
I come back from the land of game programming as a lost wanderer. And I have come with news: if you are interested in algorithms and/or 3D, it'd be in your best interest to remember all your math from high school.
I liked to build my understanding of new knowledge off of my existing foundations of knowledge. And while I understood nearly everything I came across in the world of math, some things I just took for granted. Like vectors. I thought it was just a different way of looking at the world of math, and that for practical purposes I could just geometry and trigonometry my way out of anything. Calculus will be calculus.
And it worked. For a while anyways.
But during the whole time, we were told that there were certain ways to calculate some things, such as the reverse of square power, square root. Or sine and cosine. If we knew the values, great. Otherwise, we resort to our trusty tool: calculators (or if you're really old, the slide rule). Of course, we were told that certain values would always evaluate to something, such as the square root of 4 being 2, sin(30) is 1/2, and so on. But other than that, we were clueless.
How does one really calculate the square root of 7? Or the tangent of 67 degrees? As far as I know, if the value isn't known before-hand, the only way to find out is by trial and error. Even calculators and computers have to do this. Of course, we don't do this blindly. With every guess we make, we make a better educated guess based off of how inaccurate we were, and we get closer to the actual value.
Fast forward a few years, and I'm sitting at my computer desktop wondering what's the best way to teach a computer how to tell whether two rectangles are touching each other. From testing, I have discovered that calling Math.sqrt(n) is almost 20 times slower than simple mathematical operations. Math.sin(n) and the like are slightly worse. Obviously, I would have to do this with as few operations as possible, and I should especially avoid using sqrt or sin/cos/tan, all of which are incredibly helpful when dealing with shapes floating in a vacuum.
But wait, wouldn't it be so much nicer if I didn't have to use those expensive functions at all? Turns out this is possible, thanks to the magic of vectors. As long as you knew the location of the vertices of the rectangles, it is possible to determine if one rectangle is colliding with another rectangle, regardless of orientation, size or location. The same is possible with any polygon, although complexity obviously slows down the process. If you're using a shape that has a curve in it, that's when the nightmare begins. Circles are an exception due to their mathematical properties, but for any other curved shape, I have yet to find an algorithm that doesn't use sin/cos/tan. Still, it's easy enough to define a psuedo curve constructed out of vectors, but even better yet, why pay this much attention to detail when the users won't notice such small things? If something is roughly a rectangle, just use a rectangle collision shape.
Some of you may be wondering why I would bother with speedy algorithms when calculators can spit out the cosine of x squared at the speed of light. Well, it may be fast enough for you guys, but the scope here is on an entirely higher level. Computers are dumb. Yes, that's right, computers are dumb. They can't just watch two rectangles speed at each other until a collision happens. They have to decide whether they are colliding or not, and they can only do it every several nanoseconds or so. Not convinced that speed is still an issue? Hold on, let us set the stage for a bit....
So let's assume that your computer was designed to play a shooter game, and there is nothing else that will grab its attention. On a normal computer, there's several other programs that will compete for the computer's attention, and it can only do so much. But this computer will not give a shyt about any of that. It will only care about the shooter game you're playing. (In reality you'd probably be willing to close down programs to get the best performance out of your gaming experience anyways.) After playing your game for a while, you get to a particularly intense level, and pause the game. You're shocked at the fact that there's literally a bullet every 5 pixels on the screen, dozens of enemies, and you're just spraying tons of plasma weaponry back at them. You unpause, and continue with the onslaught. Then you notice that your game seems to be slowing down. Why?
What the computer is doing is doing is tracking the locations of everything: enemy bullets, your bullets, enemy locations, your location, environmental objects, bonus items, etc. And in all of that, it has to figure out if you're trying to do something. And if you are, what exactly your action does, such as moving forward with a velocity of 35. It also has to figure out what stuff is colliding with what, and whether the computer should do anything about it if x and y suddenly are in love. But that's not all. The computer has to dedicate its time to drawing everything (that it is told to draw), which is incredibly time-consuming. And we're not done yet. The computer has to do all of this as fast as possible. For flash games, this is every time a frame is introduced. And this can be anywhere from 15 to 60 frames per second (fps).
All this chaos can be crunched down and reduced to quantifiable numbers. But how precise you want to be depends on what your goals are. Since this post is about collision detection, we'll talk about collision detection. In my case, I want to ballpark doing 5000 collision calculations at 60 fps, which I guesstimate to be close to the most extreme cases (7500?) while still being practical. It's no exact science, but it's good enough for our purposes. Using various tests, I have to decide what is good enough and what isn't. But we can't just simply devote all of our time per frame (16.667 milliseconds) to collision calculations. Realistically, we'd probably have only 40% or less. It's hard to know. But at the very end, if the game runs at the desired fps, then all is well.
In the vast majority of collision calculations, there will be no collision, unless you're playing with few elements, which a shooter game isn't. Therefore, it is smart design to conduct tests that return negative really fast. So we do a stress test that runs our collision detection algorithms. For my basic level of detection, I do the incredibly fast circle vs. circle comparison. My budget gaming desktop is capable of completing 500,000 basic detection calculations within less than 0.65 seconds. If we were to do only 5000 calculations, then it's reasonable to assume it would take 0.0065 seconds, or 6.5 milliseconds, to do it all. This is well within feasible territory. But if we run the more expensive rectangle vs. rectangle collision detection test (using only basic math), it takes ... 27 seconds to run 500,000 times. Ouch -_-;
But fear not! That was only with my original attempt at the algorithm, and is not optimized. And that test was done with FlashDevelop's debug mode (which runs 5x slower than if Flash was on it's own in a browser or as stand-alone). And such a calculation would only happen if the extremely fast algorithm determined there was a collision. Still, why leave this as slow as it is? Using some tricks that I know and some trial and error, I managed to reduce the time down to 6.9 seconds (in debug mode). It's still miles behind the basic detection speed, but this isn't the end. I refrained from optimizing the code to the point of unreadable (to humans), so it's incredibly likely I can reduce the time even further.
Why did I do all of this when there exists free collision detection kits on the internet? I did it so I would know the fundamentals and learn some tricks. That's mostly what it comes down to. But there's also the bonus that I can tailor the collision detection for maximum performance with my own code and design specs. Kits that are made to be general-purpose typically aren't tuned to be as fast as possible for specific applications. And, to be honest, if my algorithms aren't actually on par or faster than the free kits, then I consider my efforts a failure, and that I can do better.
A few other things I took away from this adventure:
-- Write up and test for a ridiculous amount of cases. Circles won't teach you this, but rotated rectangles will. It's not fair, but if your algorithm works correctly except for a very specific niche case, it can be considered a failure. A friend of mine had a couple of alternative proposals to my algorithm, but none of them passed the case where both rectangles crossed each other.
-- Don't delete complex code once you've written it! If for some reason what you're doing doesn't work out, you still can go back to square 2 since you kept a copy of the code.
-- Optimization takes away readability of code. Save optimization for after you're done laying out all the things. If you don't, you risk losing a lot of time optimizing for something that won't get used anyways.
The Stencyl Jam 2012 contest was announced since early May (I think... it's been a while). Usually when these contests are announced, there's some sort of tight deadline. But since the deadline is July 31st, and Stencyl was a program meant to aid budding game developers, I figured maybe it was worth a shot. Gives me a great excuse to get started, and start small.
Yes, start small. My original idea I've been writing about in my earlier posts is going to be much larger. I don't have all the ideas down, and it's going to be much more complicated than I could possibly do in a couple of months. Even without the testing and iteration, it's probably still not enough time. So I had to quickly come up with an idea that I want to do. I decided to do a tribute game to an obscure puzzle game that I had enjoyed, since it is territory not covered by Stencyl's crash courses (a platformer, a shooter), I personally enjoy puzzle games, and it's also something Knuckstrike wanted (dungeon crawler). Kind of.
So here we go: making a game in flash, so that I'll know what to expect, what I can do, and what a huge pain in the ass it all can be!
Dev Diary ==========================
Early May: Started doing pixel art for the game. I already know what I want when it comes to pencil drawings, but I've been dabbling in pixel art earlier for the phoenix. And ... well, it was a lot harder than I expected. One thing's for sure, pixel art at a medium scale or smaller cannot really be done with computer algorithms.
This time was mostly spent in experimenting with shapes and sizes of the main character. I have the least confidence in drawing creatures, so I just kept at it for all sorts of tries and variations. Eventually, I finally settled on a couple of poses that I could use for the meantime. If things go as expected, it's very likely that the character will be replaced for something that's better. I couldn't just go without trying out a weapon on it, so I went ahead and pixeled myself a sword too. That went a lot faster >.>;
Mid May: Started pixeling my first tile set. It went okay. There's quite a bit that's left to be desired though, both from a level designer's perspective, and aesthetics. Specifically, the walls that aren't facing south can only be seen as a thin line of pixels that aren't distinguishable from the core/fill. I'll have to come back to this later, but first, I have to figure out what exactly I'm getting myself into when using Stencyl...
Late May: Downloaded Stencyl, and went through the crash courses. Other than the provisional "sounds" and "music" being .png images (lolwut), it was a fair display of what to expect. However, for the genre of my choosing, it left very little to go on for a starting place. Well, I wouldn't be a programmer if I didn't attempt to tackle such challenges head on. Mostly spent the week staring at all the options, and thinking about how I wanted to do things, as my training from the crash courses quickly disappeared.
I decided to check out the scene designer, since my years of playing games basically screamed "a tileset exists!" Sure enough, I had the tools to make a level. However, in a bit of shortsightedness, I quickly learned about my fallacies in my tileset, partly due to the possible combinations of wall arrangements, and also because of how level designing doesn't necessarily impact performance cost.
7 retries later, I got really fed up with the rigid inflexibility when it comes to editing tilesets in Stencyl. I decided to just roll the common tiles, then make a tileset that can make virtually any tile I could possibly want. Extra doodads and details were to be made in their own tileset.
Beginning of June: I got into the dirty of coding, Stencyl style. Actually that didn't last very long, since what I wanted quickly went out of the scope of the "design mode" tools that were available. So it turns out I have to learn AS3 much sooner, not that I mind.
Right off the bat, I had to deal with coordinating computer calculations and the visual interface. It was certainly much easier dealing with only code that happened in sequence. However, I have to deal with handling player input, making sure something happens when it should happen, and something shouldn't when it shouldn't, timing events, making sure other code doesn't interfere in the process, ... , all while making sure that it runs at a satisfactory fps for smoothness. In addition, I have to learn about all the nuances that come with working in the "fourth" dimension. For example, the KeyStateListener for a keyboard key that's held down (as opposed to pressed or released) will keep firing off, even if another condition later becomes false.
That all said, I tested the waters with what little I have and discovered a few things. FPS is already dipping close to my lowest acceptable rate, and a massive amount of enemies severely slows down the game. Clearly a work-around will have to be done, since Stencyl is using a lot of scripts that I don't actually need. The big culprits being suspected are drawing the whole screen, and the Box2D collision engine.
June 4th: Finished up the movement system, excluding rotation controls, and it's pretty solid. However, since I want to incorporate convenience and some semblance of dynamics, I've went the extra mile to allow the ability to hold down a directional key so that instead of just moving once per press, you can continue moving across a room really fast if you hold the key. The set of conditions I'm using aren't air-tight however. I'd like to continue working on the control scheme, but I'm probably better off exploring the rest of the components needed to make the game function at its most basic.
June 6th: I explored ideas in coordinating information between the player, monsters, and the level. It is infuriatingly annoying unfortunately, since I can apparently define, set, and get attributes on the fly, but I can't refer to attributes of an external creature/level that "may possibly not exist"? Maybe there's a really good reason for this, but it's a barrier that I will have to overcome and work around.
June 7th: Worked on making the camera follow the player. It's unlike the kind of cameras I've seen used for flash movies and games. Or even the SNES. Go figure >_> I've also discovered a critical error with my movement code in the current revision if I were to proceed with my camera coding. This makes me glad that I'm looking at all fronts first before I try to bring the project forward as a whole.
June 9th: Fixed up the movement system, so that it now works as intended, and should work smoothly in all situations. However, it isn't responsible for coordinating with the camera system or monster movement. I'll need to figure out the best way to coordinate all of these elements, along with the scene, so that it all works in harmony. Or disharmony if you die. lol.
June 10th: I forgot that you can define getters and setters for your own functions and behaviors. Part of it has to do with how Stencyl and Stencylpedia is set up, part of it has to do with the fact that I haven't coded for years now. FML!
June 12th: I'm quickly learning that Stencyl and possibly Flixel are including tons of features and functionality that are running constantly, whether they're being used or not. I suppose it's fine if you're doing some platforming action. However, I have absolutely no use for the vast majority of their functions. Using the more in-depth knowledge, I conducted some tests. Stress testing has revealed that adding oodles of Stencyl actors causes severe FPS drops, even if they're off-screen and "disabled"; same result as the last time I tested this. In addition, the Stencylpedia claims that there's no performance impact for having multiple layers of tiles as opposed to one layer. That's a flat-out lie.
I've set up a bare-bones level that hopefully captures the optimal performance that I can squeeze out of Stencyl's engine. It has two layers, but a layer that's composed of null tiles runs faster than a layer filled with actual tiles. I'm also rigging up a system that handles the drawing and collision of the monsters. Stress testing with this system revealed that they're virtually lagless (thanks to Abigayl and Sunflower for the idea!), with the exception of when the screen is completely stuffed with them. Even in the worst case scenario, the FPS is still pretty darn high. In the meantime, the player will remain a Stencyl actor, just because it is convenient. Depending on what I can code up, I might convert the player into my own custom system.
Technically speaking, the system that handles the monsters is a series of lists, each that hold their own values. It's easily conceivable from a programming perspective that monsters can be objects, though at the moment I have no idea how this impacts performance.
June 18th: A worst case scenario has happened. My computer froze while Stencyl was prepping the game for testing. This resulted in all the .xml files associated with the game becoming corrupt, and all work is effectively lost.
But fortunately, I have a backup copy of my game! Unfortunately, it is from 5 days ago. Still, it's not going to take me 5 days to reproduce what I've done. In fact, some of what I did was exploring possible options for coding and tinkering around with possible effects.
I've also discovered that the game that I'm trying to emulate actually released its source code a while ago. That kinda felt like a slap in the face, but at the same time, it would be cool to see what they've done. Right off the bat, I don't understand half of what's going on, since it is written in C++, and I don't quite know the jargon of that language, especially with all their symbols and syntax. But I'm certain with enough staring, I should be able to understand what's going on. It is also clear to me that the Flash engine being used by Stencyl is incredibly inadequate in terms of performance compared to the source code. Whereas my Stencyl game struggles to make all the necessary calculations in a timely manner, the source code just laughs in its face while having a shytton more methods, classes, and flexibility. As for me, I gotta do this one step at a time....
June 24th: It keeps feeling like I'm derping on something and/or I'm jumping the gun on things. But as I continue to learn the nuances of the coding language, I've learned more and more about the best practices. Obviously this issue would be over 5x faster if I had an actual tutor xD
June 26th: Since the Stencyl API is shytty as hell, I decided I would dig into the Flixel API and see what I can find, since Stencyl makes use of Flixel. What I discovered was that a good amount of stuff I didn't want running in my code was to be blamed on Flixel. But Flixel was designed to be a general-purpose library that's suppose to expedite the game programming process, so I can't exactly blame them. Instead, I'll just continue to dig deeper and see what useful goodies there are.
That doesn't mean Stencyl is completely off the hook though, far from it. I've devised a simple profiling test for small operations, which basically repeats the function on the order of 10 million or so. The execution time ranged from anywhere between a fraction of a second (!!!) to nearly 30 seconds. Anything significantly longer than that, and I should either scale down the number of loops, or the game "froze". I'm amazed at the number of things that Stencyl does behind the scenes that works for the bumbling beginner game dev, but is unacceptable for a journeyman programmer. For example, if I wanted to increment a number by 1, doing it Stencyl's way (tells ... something that the variable has updated) has a test duration of roughly 13 seconds, while doing it my way (variable++;) has a test duration of 2.5 seconds. Seriously?
Despite the light in all this however, I can't get bogged down in optimization. If I had it my way with optimization right now, the code would be nearly unreadable, and I might risk having to redo everything if I find out that something I wanted to do doesn't work with my current code. At this point, all I need to do to finish the core engine is code up player death. Then it is time for the bells and whistles. I'm still a bit stumped on how to approach drawing the map, but I believe looking into the BitmapData object would provide vital answers.
EDIT: Major setback has appeared! Apparently when my camera moves, the monsters move with it. This is absolutely unacceptable, and will need to be fixed.
June 29th: Is it really only a month left until the Jam deadline? Dang, that's a lot of time gone!
I got really interested in stress testing my engine to see where I stand in terms of performance. It's amazing what kinds of strides you can make when you really put your mettle into it. If you tried to use Stencyl's actors for monsters, you'd start getting a lot of lag at 20 monsters or so. And at 100 monsters, you'd get horrible lagging. If my computer is struggling to breathe, what chance do most people's computers have? On the other hand, if you just have one actor and copy its sprite all over the place, while having a grid of numbers to track data, it can pass for an actual monster. I filled a single room with nearly 700 monsters, and the fps is showing at a stable 26 when everything is moving around. When you think about the magnitude of improvement, that's some wicked sick biznasty.
Of course, that was without the bells and whistles. I already had the code in mind to program the gibs when you kill monsters, so I decided to do it, iron it out, and debug. It didn't hurt performance noticeably more, but my game is looking a lot better because of the particle effects.
I can't help but feel that an expert game dev would look at my code and literally lol at how bad it is. Whatever. Make the mistakes, learn from them, move on. Gonna actually code death tomorrow....
Oh, and a matter of urgency has turned up: designing and sizing the width of the HUD. It was a decision I kept on putting off, but it has to happen soon or else the rest of the game could go out of sync.
July 2nd: Today, I put together a whole level to test out my engine so far. It was moderately cool, but it doesn't really have much substance to it. Probably because it has no sound, no story development, and I just threw together a level just for testing xD Nevertheless, I discovered a few more bugs that I needed to iron out. And rather disturbingly, the game crashed once for no apparent reason. Hmm....
These tests so far have all been done on a fairly high powered computer as far as flash games are concerned. It'd be interesting to see how much crap I'll have to deal with in my game when other people test out my game later this week xD
But before I can even think about rolling out a test game to the testers, I'll have to implement changeable controls. The game abuses the 10 key, and some people either don't have the fortune of a good 10 key, or it just doesn't exist whatsoever. Options to change the controls, among other things, will be required before I can proceed.
July 7th: I found a composer that's willing to provide music!
On the other hand, the number of complications never ends. Over the past few days, I've quickly started hating my color scheme. I mean, seriously, who really enjoys a non-action game that's all grey? And like most really complex software, Stencyl started doing strange things, such as giving me a completely white behaviors screen. To save myself from needing to do unnecessary debugging, I've decided to ignore any demands for updating Stencyl to a more current version, since things change, and some of the bug fixes would cause my code to not work anymore (mostly math-based calculations).
The first beta test round has been delayed because of these complications. If Stencyl was a veteran product, there would be no way that I should have encountered some of these errors and bugs. But time marches on.
August: Been a while, but better late than never. There's been several reasons that have contributed to why I never finished this project. But I will list the most important ones:
1.) My brother was having a wedding mid-late July, and there's a lot of shenanigans that go on with my mom's side of the family. Due to poor planning and an excessive amount of wading through highway traffic jams, there was a lot less time than I was hoping for.
2.) Stencyl is great for expiditing the process for making games, but unfortunately the limitations and restrictions intended to make it modestly idiot-proof got in the way and made my game unable to perform well on all machines. The alternatives were to either strip the UI (which probably would lead to lots of "what do?"), or do lots of clever transitions. In comparison, Caravel Games released the flash port of DROD: KDD, which basically blows my tribute out of the water in terms of performance.
It's too good to throw away at this point, but for the forseeable future, I'm probably going to abandon this project. I'm going to move on and learn AS3 from the ground up instead of using Stencyl, and hopefully build cool and interesting prototypes for better games. Some things I have learned from the theory:
-- Flash uses a single thread. That means all the code and rendering happen "in line", and where one takes a while, there's less room for the other. Overloading the thread causes lag in the flash player, and it will slow down. There are tricks to reducing lag, and if you really need to, you can resort to coding asynchronously, which allows the code to execute and not hang up the rendering.
-- Allocating memory takes time and sucks. This is why object pools exist, and why in certain games, it is advantageous to allocate all the memory you anticipate using from the get-go instead of during a game.
-- While the garbage collector is a nice convenient feature, it actually takes up resources during run-time. This can cause intermmitent lagging. Another reason why object pools exist!
I realize that making a game from scratch is no easy feat, and that there are major components that go into making games. While I won't be doing sound and music, I will become a Nazi over the art, coding, and playtesting.
I have a couple ideas of what kind of environment I want for the game, therefore I have some idea of the music and menu sounds that I want. Ultimately I'll want to pick them out for when I have some of the basic groundwork laid down to see how they complement the atmosphere when a player plays the game. I would prefer to be able to do this for free, though I'm not entirely opposed to hiring SoS to do the job :o
The coding aspect will be a bit difficult without any art assets. Sure, I could take sprites from existing games, such as Tails. But ... it doesn't quite feel the same as a bird, and it's highly doubtful that all the sprite images for what I want exist in such a nice package. I plan on a 360 degrees movement, complete with continuity on all aesthetics (mostly the wing flapping and tilt afaik) to make it smoooooth! Someone out there is probably going to show me something like this....
But in the meantime, I've written down pseudocode for the expected variables, functions, and etc. It already looks like it will be a lot of fun to test and debug! I can't write the actual code yet, because I don't know exactly what goes into programming a game that runs real-time, and I don't know AS3. As for the software, Flixel and what I hope is the IDE for AS3 have been downloaded already. It's been a while.
Now for the art... being the asshole that I am when it comes to self-criticism, I don't think I'll ever live with myself if I released a full, serious game with my current drawing skills. The evidence: rather than enjoy a good movie for what it is, I usually end up picking flaws in their art, animation, transitions, script, etc. The Bitey of Brackenwood series is more or less the only things where I have problems picking out anything wrong for improvement (there's more, but I can't remember them off the top of my head). And if I chew out others, think about what I would do to myself! Truly, you are your own worst critic.
I could have someone else do the art, but I don't know anyone personally that would be willing to undertake such a job.
In light of these facts and circumstances, I've decided to resort to pixel art for my game. It's a new medium for me, but since I'm nitpicking over stupid details anyways, I mind as well excercise myself here while having full control over my art. And since this is a process of exploration, I tried out a few techniques to see if they work for me or not.
The first approach I tried: create the concept image and try some macros. Yes, this isn't real pixel art, but it does at least give me some perspective. Not to mention when it was said and done, it turned out really ugly anyways. What looks good as a regular picture does not look good modified, especially as pixelated. It also made me appreciate chibi styles a whole lot more, since there's no way you can cram all the details you want into, say, a 32x32 size image. Proportions will also change, as well as the need for pixels to convey multiple messages at once.
Next approach: doing it the right way, by starting with the outline, and completing the picture with the major colors first, then working into the finer aspects until you have the complete picture. This proved to be problematic for me, since with the mediums I'm used to working with, you can see how your picture can turn out at the outline phase. But with pixel art, the resolution of the outline is so low and so anarchic (at least to me), I had issues being satisfied enough to continue, even knowing the limitations of pixel art. Eventually, I decided to do these outlines with three shades: the usual black and white, and gray to convey contours and some additional detail. This helped immensely. I haven't seen any tutorials advocate for doing both outline and shading in one go, which only goes to prove that there are no hard and fast rules to art.
I still haven't went beyond 1 frame of the countless frames I'll need for the phoenix. It is something I'll have to explore as I acquire experience in pixel art. Hell, even that first frame is still a WIP, since it's a lot easier to be picky about a creature than it is for something like sand. Speaking of sand, it is the first tile I drew for the world, and it will be one of many tiles for a tile set, and there will be many tile sets. That's going to be a lot of work! I may need a standard for this, as it can help to organize my work better. But I'm a messy-organized person with good memory, so that might create undue burden on myself on certain aspects. Hell, even the standard that got developed in my senior design class was really only a formality for the most part. It's invaluable for finalizing the project amongst our team members, but throughout the course of the work, we changed the standards so much because we kept on finding things that we just didn't like about it, or it couldn't adapt to some of our problems.
There are still a couple things I don't entirely have down, such as the size of the tiles. I've heard mention of tiles being in sizes of 16, 24, 32, and so on, but I don't understand why those numbers. Maybe it is arbitrary? Maybe it has to do with monitor resolution? Times sure have changed from games being run in DOS to GPU-killers such as Crysis. Ultimately, I'll let the phoenix decide what size of tiles I'll have. Another item of interest is full screen, as seen in Sarah's Rebuild 2. I haven't seen code on how to do this, or whether this is possible at all with the free tools that are out there.
For now, only time will tell how much I get done. I know from experience that the initial development will take the longest for me, and not because of the work hours. However, once I get to a certain point, it's going to become like wildfire.
It's been a while since I actually decided about committing to making a game in flash.
I've asked around for ideas of what kind of game people would like to see. Not to put fault on them, but most suggestions have been overly generic; things like "dungeon crawler", "Tetris", "top down shooter", and "Checkers". The more ambitious suggestions included "Dominion emulator" and "Crossfire hybrid". Well, Crossfire and Dominion already exist in the physical world, and it's much more fun in a social setting than in front of a computer anyways, so I won't be doing those, to say the least.
Fastforward to this week, and I took a look at the game Subtle Energy 2. Pretty neat game, and I really like the color trails the particles leave behind. This spurred me to think about the older games that I've played that I have enjoyed, even though the graphics couldn't even remotely compete with today's material.
Overall, my goals for this project is to get some insight into programming a real-time piece, get my brothers to shut up about making a game, and to have fun. I would also like to spend quality time with it, unlike my first attempt at making a game (which consisted of a 3 week summer crash course in Project FUN), but I also don't want to deal with a project that is so large and complicated that I couldn't possibly finish it.
So far, here's what I'm thinking:
-- The protagonist will be a phoenix. Seriously, I've never heard of a game where the main character was a phoenix. Someone out there is probably going to prove me wrong....
-- The game will involve a large degree of freedom. Phoenix flight will be awesome if executed correctly, but this will have a large amount of hurdles to jump. The freedom aspect will also test how thorough I am.
-- There will be a world to explore at your leisure. The details aren't final, but it will have a great amount of similarity to Star Control 2, in that you can do negotiations with other creatures, get involved in minor skirmishes, and maybe collect resources. However, there probably won't be a countdown to destruction.
-- The amount of skill required to 100% the game won't be very high, although it might still be beyond 90% of the people. However, if you have a rock for a brain, the most you could probably do is the "main" storyline and a few optional goodies.
Some inspirational games:
-- The Ur-Quan Masters. Basically the free, open source, fan version of Star Control 2. Seriously, this game is awesome, but the most glaring flaw is the lack of explanation of the controls. It's incredibly unlikely that you'll win the game to any degree on the first playthrough without lots of saving, but the experience is immersive and unique.
-- The Tiamat Sacrament. Think Final Fantasy, without the overworld map, or excessive grinding (although you can still do that to make things easier). Learning the lore of the world rewards you. Teamwork is paramount to your success, in that you need special items to use your dragon breaths, and only certain others can supply these items. Or you can build up a single attack that strikes 8x times with 2x damage. New items don't equate to "hits harder", but enhances your power in different, unique ways. Though it's not a super polished game, the concepts and mechanics behind it impress me. Newgrounds trailer for this game can be viewed here.
-- Various Newground games of various categories. Yes, even ones without medals. The melting pot of creativity is why I love Newgrounds.
I'm sure most of us have heard about the 1% or how Africa's children have it worse off than your most holy fking tantrum moments. You most likely aren't part of the blessed or ill-fated group of people that have garnered attention, and you would know that. But a big question that has bothered me for a while was just where exactly do those two groups of people stand relative to one another, and where am I in between? Yes, it's correct to say that they're at the top and bottom, but just how wide is that gap?
I've always been a numbers kind of guy. Combine that with the fact that I don't like immeasurable vagaries (such as how many happiness points do you get when your boss awards you with a 10% raise in salary), and you get this news post topic: how to place yourself against the world through video games. I can't promise that you'll ever get anything precise, as everything involves uncertainty. And if you hate competition, you'll get even less precision. Personally after having went through this exercise (unwittingly), I can say I see things through a different light than before.
How do you measure your performance in a video game? The easiest answer is that the game tells you. The less obvious answer is that you decide for yourself. You could think that the McVarial 900 you just pulled off was wicked sick air, and it certainly isn't the easiest feat to pull off. But how do you know if that was the best of the best, or more probably the lower half echelons of skill? By repeatedly playing the game, you get a feel for the latter, but without being able to compare to other people, you can't really find out for the former.
eSports games are a great starting place to find out where you compare with other players. They have ranking ladders for comparison, the best of the best usually have videos of them playing somewhere on the interwebs (such as tournaments), and they actually take their shyt seriously as to be a very solid game. All the same though, you must be aware of the limitations of the games's audiences and who the player base consists of. eSports are nowhere near the caliber of real life sports, thanks in part due to the great variety of games that the industry has to offer, and also due to the immaturity and casual nature of gamers. They're probably not abusing steroids, but they sure know how to swear up a mean rant, and it's not unusual for some pro gamers to show up to a match an hour late.
Did you know that South Korea's national sport is Starcraft?
Anyways, we'll take my example to show you what I mean by using an eSport game to compare where you stand versus the world. I've been playing League of Legends (LoL) for about 1.5 years now. It's a F2P MOBA that has recently taken roots into the eSports scene, such as tournaments in MLG, Dream Hack, and ESL. It has ranked ladders for all sorts of play modes, and it is relatively free of hackers, due to how their game is coded. Hell, the client-side data files aren't encrypted, because they're just that badass. (Virtually nothing is hack-proof though.)
So how many players does it attract? Since we're trying to get a comparison of ourselves versus the world, we'll have to focus on the ranked mode of matches. In order to participate in ranked matches, you have to attain summoner level 30, which is anywhere between 100 to 500 games played, average of 275. That's an impressive requirement for entry. Most casual gamers may not stick around for that long, especially considering that LoL, like any other MOBA, has an extremely high learning curve. However, LoL takes several steps to ease the introduction of the game to newbies. But even if players hit summoner level 30, they may choose to never participate in ranked mode. So the number of players that participate in the ranked ladder is...
Well actually we just look that up on the website. There are just shy of 175k players whose ratings for ranked solo/duo mode are 1200 or higher for Season 2. (Season 1 had a little more than 184k players rated 1200 or higher.) This is somewhat problematic, since 1200 is the starting point of one's ranked career, and a rating lower than 1200 cannot be viewed and is unlisted. Fortunately, the eSports manager gave out numbers on what exactly the ranked medal designations mean in this announcement. A bronze designation means you have a rating of 1249, and you are in the top 25% of players. Conservatively, we can estimate a total of half a million players in the ranked solo/duo mode pool, which is a good sample size for what we're going for if you ignore the constraints of being able to obtain a computer with internet and dedicate the time to fulfill the prerequisites and keep on playing the game. Here are some further factoids that devs have dropped about the game's demographic: the average ranked player is far superior to the average ranked and non-ranked player, and LoL has a player base of 32 million players, where every day about 4.2 million players play at least once.
What skills does playing ranked solo/duo mode games test? Well, it definitely measures understanding, strategy, and reflexes/dexterity in real time. More specifically, it measures the following, not exclusively:
-- Micromanagement of your champion and proximity (e.g. last-hitting, timing your skill combos to kill someone)
-- Macro strategies (e.g. map awareness, lane pushing mid-late game)
-- Knowledge of champion skills and item interactions (e.g. if Skarner has captured your teammate using his ultimate, it is usually very bad idea to use Tristana's Buster Shot on him directly)
-- Picking champions and counterpicking (e.g. use Galio versus Brand)
This can be different from another competitive eSport game such as CounterStrike, where reflexes and sharp senses play an absolutely vital role in whether you succeed or fail as a professional gamer.
So now we know the types of people we're comparing ourselves against, and we can guess what range of demographic those people consist of (teens, young adults from developed areas mostly). And we have the website resources and the eSports manager's post to help us get a good comparison for where we stand versus the world. I personally finished with a silver designation in ranked solo/duo mode Season 1, which means I'm in the top 10% when comparing attributes that LoL ranked games favors. If I'm to compare myself with the rest of the players that play LoL regularly, it's probably closer to top 2%, conservatively.
That in itself was pretty staggering to me. I thought I sucked as a gamer, but that was because I was comparing myself to videos of pro players, and videos of players showcasing their best shyt. Hell, I do just exactly that for NG games. Still, it's good to keep in mind the limitations of this exercise. More hardcore MOBAs exist comapred to LoL. Hell, the original MOBA that everyone recognizes, DotA, is more hardcore that LoL. HoN is a reskin of DotA for the most part, and their community is hardcore. And LoL definitely does not test players on their office skills.
And I have to throw this out here: while eSports games are good for comparing yourself versus the world, get some psychology tests with you-versus-the-world comparisons completed if you can. While my experience with LoL is pretty reassuring to my ego as a gamer, it doesn't beat the confidence of my visual-memory abilities getting blind-sided in a test and still passing with flying colors.
(In one such test, there was an abstract picture with 30 gradeable elements. You had to draw it with the reference, then immediately draw it again without the reference. An hour later, after doing other mind-intensive activities, you had to draw the same picture again. This test does NOT work if you know how to execute it before-hand.)
Again, this isn't the most reliable stuff out there, but at least it is better than nothing.
When I speak of the bad things developers do to games, it's all the stuff that makes people groan or put them off from a game. Realistically, I don't think there's any single game that has the perfect mix of elements that create maximum fun for the whole family, even if you ignored gamer preferences. I find that exploring these evils is interesting nevertheless, and some of them even apply to real life.
This is a pretty strong culprit. Grinding games are very easy for developers to design and make, while increasing the apparent game time or value for little cost. In return, it sucks thousands of hours out of living creatures who could have otherwise been stimulated by something interesting. Granted, if you did anything enough times, anything can become a "grind". Hell, sometimes I look at my profile in League of Legends and go "did I really grind that many games?", even though the experience is almost never the same. That is, unless you play ranked games that aren't close to platinum levels.
In my opinion, having a little bit of grinding is okay. It affords the player a rerun of previous mechanics and allows mastery. This can be a great thing if you're easily overwhelmed by new information and having to try things on the fly (not the same thing as Time Tax, although it can apply too).
Too much grinding however leads to stagnation and the putting off of players. Why repeatedly kill monsters? Because you want to level up, earn money, and become more powerful and awesome. Oh, and if you want to see the story and beat the game, you'll have to do it anyways. But wait, why not just play that other game that offers the same goodies, but with a lot less genocide? Because you don't know that it exists or what it is called. But by all means, if you actually think grinding is fun, I'm not going to stop you from doing it.
Grinding, unfortunately, has seen reasonable success among game developers, and this success has been heavily dissected and adapted for the most notorious cases: MMOs. It works well in those cases because most of the time, their games are continually being developed and don't want the players to reach "end game" too quickly, while catering to the masses. And by the last clause, I mean that the vast majority of players make pro gamers go "omg y u so terribad"; they're going to be insignificant at doing what the game demands them to do, and the few shining examples will make them feel bad. Fortunately, even bad people are good at doing the one thing integral to grinding: wasting time.
Again, I'm not opposed to game developers introducing a little grind to their games. But in case you haven't noticed it, the vast majority of them are in it for the money. Fuck man, they even throw offers in there to make it less of a grind at the price of your wallet! I'm a cheap bastard, so I'm a bit biased, but this becomes ridiculous when they decide to charge you the equivalent of a monthly fee just so you can enjoy the game with others without the ominous feeling of being the one to drag down the whole operation. Example: money gear gives stats, but expire after 90 days or something.
The finer points of why grinding has a grip on many gamers can be explained by lessons in psychology. But I'll let your imagination and Google to lead you the rest of the way.
This may or may not be associated with grinding, but the fact that there's a ludicrous reward for doing a simple little thing makes this addicting. Or for the frequently unlucky (like me), downright rage-inducing. Because while you could win the jackpot in one try, it is also equally true that you'll never ever win the jackpot. Ever.
The amount of addiction to reward-based RNG mechanics, like say you getting a legendary item for killing a slime, is at its highest when it is pure random. Any other gimmicks like psuedorandom don't encourage this behavior as much, unless the odds of winning are ludicrously low. And if you thought us humans are moronic monkeys, anything else with a brain that lives for more than 3 years isn't free from this effect either. Mice and birds that learn doing X rewards you with Y randomly go nuts doing X.
This one is more like a group of patterns and behaviors than an actual single concept. But the effect is the same: less fun, or no fun. I can only give examples as to what this is, but they all can be pointed to have design flaws.
-- Melee character versus ranged character. If the mobility of each character is approximately the same, it probably won't matter that your melee character can 1-shot the ranged character: you're going to groan and yell at the screen while you two play cat and mouse. In the meantime, for the ranged character, he's probably going to just grind your health down to zero, and he won't exactly feel as much satisfaction out of it as opposed to skillful executions. While this isn't inherently broken or nonsensical, it's an anti-pattern.
-- Developer versus gamer. I'm sure many gamers that particularly enjoy indy or solo game projects have experienced this at one point or another. Developer makes a goal so ridiculous that no gamer will ever accomplish, and it isn't exactly skill-related either. Among the hardcore medal collectors in the NG circle, the Keeper of Secrets medal from Pico's Musical Experience is a good example of this.
-- Unclear optimal use. It's just not as fun to use a skill where you could have done something better nearly 90% of the time, as opposed to using a skill where the use it clear, or at least the optimal conditions arise 90% of the time where its complexity doesn't really matter.
I hit 100k medal points a week ago, and an obvious thought was "that's a lot of points!" So I thought I'd type up this news post to commemorate the event, including resources for aspiring medal points earners, general tips for getting a high spot in the rankings, and miscellaneous "awards" for the easiest, hardest, most troll, douchiest, or plain lulzy games.
If you're wondering about where you can find more games and movies that give out medal points, you can find them on the gameswithmedals page.
If you think you're a god among gamers, see how wrong you are in the NG top medal point users list thread (kudos to Hybrid-of-Souls for doing a great job). If you don't show up on the list, either you don't have enough medal points, or we don't know you exist. There's no NG-generated top medal point users thing anywhere as far as anyone knows.
If a game or medal is causing you to rip your hair out in frustration, give the Newgrounds Medals - Games and Tips a look. Use the search function (preferably google's advanced search) before you ask a repeat question, as per the NG BBS policy. Or you can look up walkthroughs and videos on other websites. But in general, feel free to ask questions in the Games and Tips thread, I promise not to bite! (I can't promise the same from other users though, sadface.) It is generally frowned upon to tell people what a secret medal is in public, so don't do it. PMs asking how to get a secret medal are a-okay.
Common alternative walkthrough resources:
-- Wylina's links and guides
-- NG Wiki and FAQ
-- Knuckstrike's list of video walkthroughs
-- Miscellaneous userpages who have written walkthroughs
-- Author comments on their own games
Last but not least, the Official Broken Medals Thread by PsychoGoldfish. This is for cases where, no matter what anyone does (outside of cheating of course), medal not get. It's a good idea to check this thread and the Games and Tips thread if there's a bugger of a medal that's just teasing you all day and in your sleep or something.
-- Generally, in order to earn medals, just meet the requirements as stated, and you'll be notified in-game that you got a medal. Beware, some games don't use the typical "medal get" notification, and even fewer of them don't use them at all, such as EON.
-- It takes time to get medal points. If you thought taking an hour to get a 100 point medal was just terrible, you have seen nothing. But generally, 100 points per hour is an okay benchmark to shoot for.
-- Approaching a game for the first time? It helps if you play the game through once just to learn everything. The second time you play it will be for specific medals or those extra challenges. Obviously, be efficient about it, know what the medals and their criteria are ahead of time.
-- Practice makes perfect!
-- Don't be a scrub. Something is not impossible just because you refuse to adapt to a certain strategy that goes against your self-imposed morals or rules or whatever sick twisted compulsions you have. If you can't follow this advise, I would suggest that you take up something else as a hobby. No offense.
-- Ask for help if you need it! Swallow your manpride if you have to. Most of the smart people in society aren't afraid to do so, and communication is key to the success of society as a whole anyways. Team PvP veterans know what I'm talking about.
-- Make backup copies of your save files. Some games do not resend medals, and it sucks to spend hours getting a grinder medal, only for t3h interwebs to throw it out the window. Learn more by googling about .sol files, or searching the NG forums. Or alternatively, just PM me for the details.
-- You either have the skills or you don't. Sometimes you'll just have to accept defeat and come back later to try again. It happens even to the best of us.
At 4/10/11 06:21 AM, anonymous wrote:
: On a sidenote, you earned the Cover Band (Punk-o-matic 2) medal a few days ago. Do you have any tips on how you did it? I remember it being the first medal I gave up on, and you did it with ease. You're obviously better at the game, but I might go back and give it another shot if you have some good pointers.
... ... ...
: Thanks for the tips!
: Long story short. You're way better than me at the game, but I'm going to give it another try. Thanks. :P
Best of luck to you!
(based on my opinion mostly; I haven't tried EVERY game yet)
The One, The Original Medal Game: Portal Defenders
Most Tenacity Required: OCD+, Thieves Away!'s Wave 50!
Most Patience Required: English Pub Pool, Punk-o-matic 2 (POM2), Plinko
Most Stupid: Pixel RPG Battle, Why This?
Most Difficult: Feed The King (without $$$), AVOIDAL
Most Fun: Achievement Unlocked 2
Most Old-School Achievement-Like: Tetraform
RATE THESE POORLY CONSTRUCTED LEVELS AND COCK JOKES AND GET A MEDAL FOR IT: Time Fcuk (portal name), EON
Medal Point Sugar Rush Hyper Special: Magic Pink Man 2, Achievement Unlocked 2
Most Unworthwhile: Jetbus, Arkandian Crusade, Ever Rising Water's 500 Challenges
Most Controversial: Kill Innocent Babies
Best Hacker Detector: Anything with a broken medal, Brawl Royale
Utter Hopelessness And Despair: Arm of Revenge
Most WTF!?: Bieber Metamorph
Most Creative: Hmm...
It's Probably Your Crappy Lappy That Is Fking You Over: The Gun Game
Pro File Swapper, Dumbass: Spaceland Adventure 2
Largest Upset: Crazy Over Goo (some users just can't get the medals for some reason)
So Secret, You Cheat To Get It: Pico's Musical Experience's Keeper of Secrets
Just Plain Gross: The Breach (it's also somewhat scary, but mostly gross)
Blatant Portal Games: Depict1, My First Quantum Trans., p.i.g
Highest "OMG I HAVE TO DO THIS ALL OVER AGAIN!?!?" Because of Bad Coding:
-- Medieval Rampage 1
-- Medieval Rampage 2
God of Platformers: Alkie Kong 2's Drunken Deity, Lastman (the other two games would have been here, except the save function is abusable and legitimate)
Reflex Burner: Hippolyta
Carpel Tunnel Game: K-Million, Dadgame
Hardcore Fighting: Arm of Revenge
Thinking Outside the Outside Box: FISHBANE
Danmaku Desu: Bullet Heaven
Stratego: Sonny 2
Music Maestro: DJManiax, Punk-o-matic 2
Whew, that's it for now. Enjoy life y'allz!