Might as well mark this day down as the day I realized that I'm more than likely going to have far too much dialog in my game to really consider having VO work. At least, not for all the lines. I'd still love to get some in just because I love VO, but with the limitations on the size of XBLI games coupled with what I think will end up being an immense amount of dialog, I don't think I'll be able to do it. /Emo
I don't have a video to show this update since as usual, the bulk of what I've been doing is behind the scenes stuff that won't really be something you can see. That being said, I figured I'd do a write up of what I've been doing for anyone that's interested. . . Not sure who would be, but I know I would if someone else were to write it so here it is.
Save room for more
As usual, I've been making a lot of improvements to existing code and how everything works with each other. The biggest changes I've made have been to the way my game handles loading and unloading content between levels. It'll now ditch all textures and sounds and whatnot that are no longer necessary to hold in memory between level changes and load up only the files it needs to work what'll be up next. This all takes place during the loading screen. At this point, it's not necessary since I'm working with such a low amount of textures/sounds/resources but later when I'm building things out, have more things going on and all that jazz, this'll prolly be a bigger deal. So I wanted to put a system in place to handle it all before it became a problem. I've got a pretty good idea as far as what types of things I'll need to be loading and unloading so I've built it to handle more than I'm currently using and also set it up in a way that makes it easily expandable.
There's been a lot of changes to what goes on during the load screen behind the scenes. Since I'm disposing of no longer used textures, during the load of the next level, I have to check to see what items I need to have loaded for the game to run. These checks are pretty quick and they work in conjunction with my content management stuff. I've also made some large changes to how items/objects are spawned and respawned. I'll get more into the details here when I'm finished and things are set. Right now, I'm trying out various things to see what works best -_-;;
Tools are goddamn important
Level Editor Improvements
As I've been adding new classes and rejiggering the way my game is structured, I've been modifying my level editor as well. Once again, I'm very happy with the way programming works. For instance, I was having some issues with figuring out which collision rectangles were effecting which textures when things go invisible and it was a chore to individually click all the textures to see which ones were which. . . so I went ahead and wrote in code to allow me to see what things are associated with what things.
So for instance, I can either click the rectangle, or a texture, and all textures/rectangles that are associated with the selected one will be shown. In this picture in particular, I selected one of the foreground leaf textures, and it shows me which textures are in the same group of textures that will fade when the player runs into the also selected collision rectangle. This is also true for spawn rectangles, and pathing. If I were to click one of the paths, all NPCs/Enemies that use that path would be shown. Also a lot of little ease of use things such as a ruler for measuring pixels. I used to use a grid or just reference other textures that I knew the size of, but figured, what the hell, why not make a quick ruler tool? And Bam. As I've been doing all this, I've come to realize how damn important tools are for generating content and will be expanding on this greatly.
This is what I'm currently using to place enemies on the map. I can choose the type of enemy, and set all the various variables to my liking. Previously, I had to manually find the path I wanted to link to the spawned enemy, type in the enemy type and all it's other assorted variables, but again, I spent some time building it into the actual editor and now I can just fill out clearly labeled boxes, check off what I want, choose from a list of available paths/rectangles/etc and just generate it. I can save it, and test run it in the game immediately. Tools. Tools is the key. It took a bit of doing to make it, but now I've got this sort of interface for all sorts of things including NPC, player, camera, various interaction rectangles and other goodies. In the end, the time I save with being able to quickly create large map changes will pay for itself in time spent actually creating the tools to do so. I very much expect the tools to get much more complicated moving forward but I've (hopefully) planned ahead for expand-ability so it shouldn't be too difficult.
Spritesheet and Animations for Levels
This is something I've been working on for a while, and pretty much I've just been improving on parts of it. I think I'm pretty much done with updating this section of the editor. It now loads up sprite sheets using the image and an XML file. It'll load up every sprite, properly name it and set all it's properties so that I can just drag and drop it into the level. If it's animated, I'll get all the controls such as which frame to start on, how fast it should animate and whatevs. In addition, it was taking a long time to load up and I figured out it was because every time I changed directories, it would be tearing up the spritesheet and making thumbnails for each piece, every time. I went ahead and set it up so that it'll do this once, and save all those thumbnails in a directory. Now, it'll do it once and in the future it'll check to see if the thumbnail for that particular item already exists. If it does, it'll load up existing thumbs instead of creating new ones which reduced load times on folder changes by like, iono, 90%? It'll also run checks to make sure that even if the file does exist, it's up to date with the spriteSheet in case I've made changes.
Other changes I'll need to make eventually
I'm sorta looking forward to incorporating particles into the level editor. For things like falling leaves, steam, etc. Eventually I plan on being able to place all that stuff from within the editor as well. Other than that, I guess it's just whatever I need. Maybe cutscenes? I do know that I'll prolly be setting up NPC dialog from within the editor but I've gotta get that stuff set up in the actual game before I start writing it into the editor.
More generalized lists for fewer iterate calls
Prior to recent changes, every update, my game would call through a list of enemies, a list of npcs, a list of interactive objects, projectiles, the player, etc. Basically, a ton of freaking lists. Everything was separated into their own group of things to update. This in itself isn't a huge issue, but it got to be pretty messy when I would have to check collisions between everything in their own lists, and also in every other list. It was a damn mess. I've since figured out a way to group EVERYTHING that has any chance of interacting with each other, into one master list to check through. This was maybe one of the single greatest things I've done up to this point because it simplified everything. Collision between objects for one, is incredibly easy now.
The Technical Hows
This is specific to XNA, but I'm sure can be used for any C# or object oriented programming. Since all my collidable objects are reference based objects, the master list I created is just a list of a base class I created that contains the specific things I need to make the types of checks I need. Every type of object still has it's own individual list for when more type specific actions need to take place, but for general things such as 'are these two things touching', every separate list on level creation is loaded into the master list. Moving things from one list to another is easy as the master list is public and can be accessed from anywhere in any class due to the static nature of the main game engine class containing that list. So, for example, when the player throws a bomb, the bomb will add itself to the master list. This will insure that it will be updated with everything, collide with everything, and be able to damage everything else in that list. When the bomb explodes and is done, the bomb's last action will be to remove itself from the list. It will no longer be updated and all this without the need to check if it's still active before updating or drawing it. More than anything, I love that I no longer have to make all those checks to determine whether or not something is active. That alone will save me many, many checks because it used to make that check for every object, on every update and every draw call. This is prolly something that everyone who knows what they're doing is already doing, but hey. I'm new to this and figuring out this basic stuff makes me happy =P
That's it for now
I've got so much that needs doing that it almost seems overwhelming at times. I think it's better to have a bunch to do and constantly be making progress rather than being stuck not knowing what to do next. . . I think. I'm pretty sure I'm nearing the point where the engine itself should be pretty finished and I just need to start adding content. Enemies, moves, lots and lots and lots of art. . . Sounds. Jeebus. I still would love to have VO but I was thinking, I only have like 3 or 4 friends that might be interested in doing it, and of them, I'm not even sure that they'd be good enough at it. You know, not make something that sounds like it's a remake of the original Resident Evil -_-;; I'll be back with more updates as I make progress. I'll try to make have something to show in video format. I feel like I've forgotten to mention a lot of things that I've already forgotten I've done. . . but I guess it'll come up sooner or later if I did. Sorry for the wall of text.
that allows you to custom build a character. Specifically, a custom character in which you're allowed to alter the details of your facial structure.
In most games, you get to choose out of a set of pre-generated faces and bodies, or select a character or whatever and I never have an issue with those games. I pick the character I want to play as, and don't give it any more thought. In games that do give you full control over your appearance such as Fallout, Mass Effect, Dragon Age, Oblivion, and most recently Skyrim and Saints Row the Third, I really delve into this stuff. If I plan to play a game as myself, with my name, and making the decisions I would make in the presented situations, I tend to try to recreate my own face in the game as best as possible. Usually to somewhat sad results. I'll play the game with my newly generated me, and typically, a few hours in, I'll find a glaring flaw. Something that just doesn't look right. Sometimes it's the game's fault in the way it causes the face to move, and other times it's my own fault for making my cheeks too hollow, or my chin too short, or whatever.
The option that doesn't exist. . .
For some awful reason beyond my mere consumer comprehension, these games will not allow you to change your face. When you are allowed to change aspects of your appearance, it's usually just your hair, or tattoos or something along those lines, but almost never your face. I have no idea what would cause a developer to not allow this as I don't think it really has any impact on the game other than allowing the player to have a better experience. In the case of Dragon Age and Mass Effect, I have literally played the game for a few hours, then during a cutscene, noticed something that is just wrong, and from then out, can not unsee it. Every time my character appears on screen, I see this flaw and only this flaw and it drives me mad. Sometimes I can just live with it and press on (which was the case in the Fallout games) but in other cases, the character is front and center in almost all scenes and I have to resort to restarting the game from scratch.
If only it were my own fault
If this were a fault of just my shitty ability to make a character, then this complaint would just go into the pile of "shitty things people complain about because everyone loves complaining" but I feel that I have a slightly better position to lob this out there because of some general character creation system flaws. Specifically, when you're making your face, games tend to only show it to you from a straight on angle. Sure, most times, they'll let you rotate the head 360 degrees and from a head on angle (pun?) it looks just fine. Problem is, the game will throw all kinds of angles at you with all kinds of lighting and it's in these non direct angles that the flaws are noticed. Things look just fine until you're looking at the face from an off angle and below, or from above. Sometimes you can't tell that a cheek is too far out or not out enough until you're standing under a light. . . Sometimes your lips look perfect, until the character opens his/her mouth to speak and then just. . . balls. Your lips are totally jacked. Oh, and some games outright make it difficult to see what you're doing with either crappy lighting, limited angles or some unholy mixture of everything. Just give us more angles to examine our character, maybe a few different lights and a toggle to make the thing's mouth move as if it's talking. Then I only have myself to blame for my monstrosity.
Why? Why not let me change?
My biggest gripe with all this is just that almost all games refuse to allow you to change your appearance after you've created your character at the very start of the game. You're locked in for what might end up being 50 to 100 hours using something you thought you wanted at the very start of the game. But why? It just doesn't make any sense. Why not allow the player to alter their appearance? It doesn't have any effect on the game. I recently started playing Saints Row the Third and had this problem arise where in game, the face looked funny and it was driving me nuts. Luckily, you can go to a plastic surgeon and get it all fixed for a small fee. Speaking of small fee. . . I guess you can also change your appearance in Dragon Age 2 if you either purchased the game new, or buy it's DLC. Fuck that game. On the flipside, I'm really enjoying and loving the hell out of Saints Row. Unexpectedly delightful. And you can (and I have) change your damn character's appearance down to the sex and voice at any point in the game. Kudos.
Which I felt was humorous to be sure, but also a sad and accurate portrayal of the "vocal minority" in the gaming community at large and began to wonder. Do the people who are being made fun of, realize that they are the target of the joke? And if so, do they laugh along, or being the type of person they are, do they get angry? Are they conflicted? Can you laugh at yourself for being the way you are? And then, it sort of spun off into other areas. For instance
What do racists think of the way they're portrayed in popular media?
Do they watch these shows and cheer at scenes that are made to be jeered at? Can they appreciate characters who start off racist but eventually see the error of their ways and become better people? If you are legitimately of the same mindset of the character, is the entire show/episode/movie a completely different experience than for someone who isn't?
How about gamers?
In most cases, when the butt of a joke is that the person is a gamer, I'm usually laughing along rather than feeling like I'm being laughed at. I feel like things have gotten to a point where there isn't as negative a stigma attached to being a gamer as there was say 5 to 10 years ago. I might be singing a different tune though if I were a morbidly obese, extremely socially awkward fellow who's life revolved around an MMORPG. If that were the case, maybe I'd be a little more offended but in my personal case, prolly not because I'd be able to see that it's funny because it's true. . . I laughed out loud in 40 year old virgin during this scene. Btw, I'm an asian gamer with a lot of games.
I looked so hard for a movie clip, and it doesn't exist...
Anyway, for the most part, I think smart writers know who the target audience is, and can write in an in-joke type of fashion. Though, you do occasionally get this.
I tried so hard to find Sarah Silverman at the VGA, but I think ninja assassins have somehow deleted it from the internet. Seriously, it's crazy. The video doesn't exist. . .
Anyway, back on point. Did I even have a point?
No. not really. I was just curious whether people who rage about review scores see these types of things portraying them as, I dunno, crazy people and realize that they're sort of crazy. Do they laugh along? Or do they rage some more? Are they embarrassed? The world may never know. I'm hungry.
On rare occasion, I'm asked about programming and how I learned what I've learned and if I have any suggestions or whatnot so for anyone interested, here it is. This is pretty much, the process I went through, and my recommendations for anyone thinking about doing the same. I am by no means a reliable source of information, and I take no responsibility for anything resulting from this. Unless it's awesomeness, in which case, I'll take as much credit as you'll give me.
If you have absolutely no programming experience
then you're just like me when I started. I came into this knowing pretty much zilch about programming and/or any languages. The closest thing I'd ever done to coding was about 15+ years back when I "programmed" snake into my TI-86 graphic calculator by copying lines of code into it from a printed out sheet. I think that anyone can become proficient at anything as long as they invest the time. Some things will be harder for some than others but with the right commitment, short of an actual disability or physical inability, I feel anyone can do anything. Maybe not exceptionally well, but at least competently. Under this line of thinking, I took it upon myself to create a game and if you want to, you can as well. I think.
Where to begin?
There are probably as many ways to learn as there are reasons for wanting to. Also, depending on your current situation, (work, life, whatevs) your options will vary drastically. For myself, I have a full time job and can't afford to just quit and go take classes at some school. I think schools that are actually focused on teaching the art of making games are awesome, and I'd love to go, but I realistically can't. The route I took is self teaching. Once I decided that I was going to go with using the XNA framework and learn C#, it was pretty easy to find tons of tutorials and sources for learning on the internet. If you're a complete noob like myself, I'd recommend downloading Microsoft Visual Studio Express (it's free and awesome) and then running through a few basic tutorials on youtube. You'll literally start with extremely rudimentary things like getting a program to start, then saying "Hello World".
Syntax is King
Once you've tried a few tutorials and building the most basic of programs, I highly suggest actually learning the language. If you've ever tried learning a foreign language in school, learning C# is sort of like that. . . except about a hundred times easier. I know how to write, speak and understand 3 languages. 2 very well, and a third on about the level of an 8 year old -_-;; I'd say the hardest part of learning a new language is memorizing the alphabet (if it's not the same as English), followed closely by learning the grammar and syntax of the language. Finally after tackling those, it's expanding your vocabulary so that you can actually use the previous two things to USE the language. That's oversimplifying, but you get the idea. Learning C# was a piece of cake. For starters, you already know the letters and alphabet. The hardest part then becomes learning the rules of the language and how to construct sentences that make sense. Now, initially, this is pretty daunting. Everything seems like goddamn gibberish and nonsensical but as you begin to learn what's going on, you'll begin to realize it's all very clear and makes perfect sense. Everything has it's place and everything always does exactly what it's supposed to do. The entire thing breaks down into simple math, and logic. Hell, you look at any C# book, and you'll know the core of the way the language works within the first two to three chapters. After that, it's all about expanding your vocabulary.
Aside from the amazing amount of free information available on the internet, I suggest the following books. For starters, Microsoft Visual C# 2010 Step by Step by John Sharp. This book was written for people who have zero programming experience and are learning for the first time. If you can get a good grasp on the first few chapters here, you're more than half way there. A very nice side book to have that is specifically for C# is the C# Pocket Reference by Joseph Albahari. It's a pocket bible sized little book that gives the most concise and to the point description and examples of everything C#. It's basically cliff notes and I reference it a lot when I just need to remember one little thing and don't want to go searching through a huge book to find it. Also, I can carry it around and browse through it frequently so it's mighty convenient. Once you've gotten your feet wet in C# and want to start diving into making games on XNA, I suggest XNA 4.0 from O'Reilly by Aaron Reed and XNA Game Studio 4.0 Programming by Tom Miller. Both these books will sort of assume you're new to programming but won't cover C# as in depth as the previous books. They will however, get you up to speed on XNA which is pretty much, more vocabulary/words for you to use to help you build your game.
What I mean by Vocabulary
Once you know the syntax, you have the core of it. You can build out anything you want from what you have but it'll be damn difficult. That third language I know, I can survive with it, but I'd have a hard time telling a story. I'm limited by my vocabulary -_-;; It's sort of the same way with C#. The words you learn in C#, are all things built using the same tools you already have, and have code behind them that you can look at, but really, it's just giving you the result without you having to put all that work into it. Say for example, I were to tell you about this thing, that is alive, and it has a warm body temperature, and it breathes air, and has live babies. . . or I could just say mammal. It's the same thing with C#, instead of writing out something like "(int i = 0; i < list.Length; i++)", you can just write "foreach()". That's sort of a bad example but there are things that would take you lines of lines of code, that can be condensed into a single word. In fact, once you get further into it, you'll be making words of your own called objects. If there is a set of lines of code, that you'll be using more than once, you can group those lines yourself into your own word, that you can call at any time whenever you need it. All XNA is, is a book filled with words you can use that have been made to make life easier for you. That's pretty much all any framework is. C# has an extensive amount of vocabulary and even now, a year+ in, I'm still learning new words that are built into C# itself that make my life easier. A lot of times, when I learn something new, I realize I could have done something better so I'll go back and fix it and use it in the future. You never stop expanding your vocabulary either because you're learning existing words, or creating your own. It's when you start creating your own that things get really exciting =)
With all that, you're pretty much ready to make whatever it is you want. I've already blogged about how you can do anything in programming and I still think it's true. At this point, or before you reached this point, it'd be a good idea to peruse the XNA forums and also download and dissect the starter kits they have available. One of the biggest things that helped me throughout learning the language was actually using it as I was learning. If you go back to my earliest videos, you can see that I was coding as soon as I could. Start creating as soon as you can, and just keep at it while learning at the same time. You forget words you don't use -_-;; In addition, I recommend going through the forums at the XNA site for questions other people have. The community there is great and a lot of times, reading other people's questions, and the answers they receive will help you out in the longrun. Sometimes, it may not seem even remotely related to what you're currently doing, but the mechanics of it are all the same so you may figure out something else that seems to have nothing to do with the question being asked. . . that sentence doesn't make sense. Anyway, that's it.
I've now built up a way to implement simple pathing to anything I choose to spawn from the editor. For now, it's just a series of points that the object will follow in order. They'll either follow it to the end, then start over from the beginning, or follow to the end, and then reverse their course along the points. I plan on expanding on this in the future to allow pauses at specific points, maybe choosing which direction the object should face once paused or a variety of other actions that may take place at those points. In addition, I think I'll add a way to have just general roam areas that the object will wander around in randomly rather than a strict point to point type movement.
The game now supports the ability to store and recall what was in the previous area. This is obviously very important and basic, but yea. I've got it set up and functioning swimmingly. This stored data could also be used in the future for save files. I think the system is robust enough that if I want, I could go ahead and use it for saving at any point the player wishes. . . I doubt I'd allow that, but the option is there. In any case, all objects will now store and restore correctly. In addition to this, I've implemented a way for those objects to know how long a period of time the player was absent for. What can be done with such information you ask? Well, for starters, I can change their alert status from active to inactive so that if the player was gone for a long enough time, they'll just go back to doing what they were doing prior to chasing the player around. I'm also toying with the idea of having mobs be able to follow the player from one area to the next. It's not hard to do. . . at least, it's not too complicated, but I'm not sure just yet it's something I want. We'll see.
Another thing I threw in is that enemies will now react to other enemies in their direct vicinity attacking the player. So you can't say hit one, and have only that one know what's up with joe blow right next to him is oblivious. Right now, it's super simple so they'll just also join in on attacking the player but I can flesh it out further once I get down to the nitty gritty.
It took some doing, but I put in a loading screen. On the PC which is where I'm capturing this stuff, it doesn't seem to take any time at all to load, but on the 360, I'd say in between those two levels, the load is around 4 or 5 seconds. I'm figuring with more art, sounds, and full sized areas, it'll be considerably more. I figured out how to break off a thread so that the loading screen can have stuff going on (animations and whatnot) to show that something is still happening to the player as the bulk of the system is loading up the next area. I also added a fade to black and fade back in between level loads to keep it from being too jarring. Again, this is all place holder and I plan on making something a little more interesting later on, but the foundations are now there so hurray for that.
Aside from those, I've made a lot of smaller changes here and there to various systems so that everything works together nicely. A lot of clean up and optimization. I put a little more time into the way the camera handles as well. . . There was a crazy bug with the camera that I tracked down over an hour. The fix took literally 5 seconds. . . But oh man, finding it was sweet.
The biggest thing I've done since the last update is in an area that you can't really see which is the level editor. I've completely revamped it from the ground up. It's more robust and helps me build levels, make edits and whatnot way faster than before. Pretty much what would have taken me an hour will now take me only around 20 minutes or so. I'm guessing this'll be an even bigger help when I start constructing larger areas. Of all the things I've changed, the one I needed the most was a way for the editor to break up my larger sprite sheets into the individual pieces without me having to input the information every time. Now I can make an XML file with the info, and the editor will grab it and load up the pieces as individual selectable "tiles". They're not exactly tiles, but you know what I mean. I've also added a bunch of new types of world collision rectangles and the ability to spawn enemies in the locations I want them to be in.
Changes to the Game Engine
I've gone a bit deeper into the whole, segments turning see through. Now I can have multiple sets of objects become visible and invisible at the same time and I can also control when they become visible separate from each other. All for what I THINK is a low cost. In addition, I've further added to the functionality of switching levels. I show it here by running to the right, and appearing on the left of a different area, then running back left to once again appear on the right side of the original level. This can be toggled to happen automatically or be player controlled with a button press. I haven't gotten around to resetting the objects that are in the level yet, but I've got a good idea of how I can do it. Which should also work nicely with the save system I have planned.
Shadows. I have Them
Another thing I added is a system to determine whether or not objects should be shadowed or not. By shadowed, basically I just mean darkened as I don't think doing normal maps and whatnot on 2D sprites is something I'd want to invest my time in. . . yet. Anyway, I've got it set so that you can go in and out of shadows to varying degrees. It shouldn't be an issue applying this to everything in the game and as far as I can tell, I don't think it's a resource hog. Anyway, I think it's pretty.
A long long time ago, I had the whole tunnel thing implemented, but I've gone and updated it to work a bit better. Instead of just checking against your height, it'll check against the height that an object's head (or top most point) is at when deciding whether or not you're hitting the ceiling. I think I'll make it so that baddies take damage if slammed up against something. Anyway, it's back and I'm glad to see that it still works.
That's about it for now. A lot of visible progress. It seems like a lot in a short time but really, the speed that I could do it was only made possible by the week and half of straight cleaning and coding I did previously. Anyhow, I've got a couple other things planned. I really need to work on making the transitions between areas a bit smoother. . . Also, I need some new art if I want to build out levels to test, but before that. . . I need to finalize at least some of the areas the player will be going through. Mmmm. . . . also have to clean up my targeting code some. Plenty to do, not much time to do it in.
But that doesn't mean I haven't been coding furiously, because I have. Once again, I've gone through and cleaned up a ton of code. In the process, I've totally revamped the process my game uses to generate levels received from my level editor. I've also made a lot of improvements to the way the level editor itself works. The largest amounts of rewrites and code changes were in the environmental collision section of my code. Everything has been separated and compartmentalized so that I can easily modify specific types of collisions and have it applied to every portion of my game. Once again, I love object based programming.
The new stuff
One of the biggest environmental collision based updates I've put in, is the ability to have diagonal collision rectangles. Previously, I'd have to staircase multiple collision rectangles over and over to simulate a diagonal while now, I can just have the damn thing check against angles. This took a little bit of math wizardry but now that it's in, it's marvelous =) I've made the collision rectangles on the first platform layer visible so you can see what I'm talking about. Not only will this save an immense amount of time in level creation, it should mean fewer collision checks every update.
In addition to that, I've added the ability (not shown in vid) to change maps based on either the player moving to a specific location, or activating something. I've also put in a very rudimentary load screen. Eventually I'll make it so the transition is sexy, but for now it's just super basic and functional.
I've also added shadows to the aiming cursor to give the player a better idea of where the item they are throwing will go. The height that the item is thrown is also now player controlled dependent on how far the trigger is depressed.
The last thing demonstrated in this video is transparent background objects. I've managed to figure out a way to use my level editor with my environmental collision stuff to have sections of the level become transparent when the player is at specific locations. This'll be useful later on when I'm building maps.
Things I've been working on
I've still been hard at work building up the dialog system that I need for my game. I've got all the basics down, but what I really need to do is nail down how it's going to look, and in what way the player will be able to manipulate their choices. Hopefully I'll have a bit to show on this section soon. I'm also still working on the story. . . which is something I really need to get together soon as I think I'm nearing the completion of the engine. I've still got plenty of HUD work to do so while I have a lot of wiggle room, I'd like to have it nailed down before I actually NEED it to progress.
My friend in his youth created an entire storyline and comics based on some batman like characters. One was BatChao (his last name being Chao) which was I guess, for all intents and purposes, Batman. He was then killed, and became BatChaos. A new BatChao rose to take up the mantle of the now deceased and ghostly BatChaos. In this universe, Batman exists as a comic character. . . I didn't go too far into the nitty gritty details of how things work seeing as how this was a middle school creation.
Anyway, I'm currently deep in Arkham City (Which is fantastic) and got the urge to draw the Batman, but didn't really want to devote the time to doing it. . . And in some kind of perfect storm of coming up with a flimsy excuse to do some batman fanart, I went ahead and did a fan art drawing of my friend's characters (who are basically batman anyway). He also works at Disney Interactive, so that should explain the BG. Oh, and it's the size it is just in case he wanted to use it as the art for a custom iPhone case online.
I sorta skimped out at the end because it was getting late so the cape isn't all that it should be, but overall, I'm fairly happy with the results. Here's some pics I took while I was drawing the thing.
BatChao is the one in the front as well as the one in the initial super sketch -_-;; Apparently, he's got like, a baklava type deal on underneath the mask that covers his entire face. Anyway, just thought I'd share cuz. . . . well, just because.
In the meanwhile, I'm still working on my game. I've redone the targeting system and I personally think it works better now. I'm also in the midst of trying to figure out how I want dialog to work, so I've been making, dismantling, and recreating my dialog system. I've got some specific things going on that I think are unique so I can't really share it at the moment as I don't want to give it away. . . you know. As if anyone would really steal my ideas, but on the off chance, I'd rather keep it to myself until I'm ready to really show it off =P I'll post some other updates sometime soon.
This is a short vid, with a long post about how I dealt with the gravity situation. I love physics. I love math. But they can be a real pain in the ass when you don't understand them -_-;;
The Math Behind Gravity
So, I've had a pretty basic way to do targeting before with the balls that show the trajectory and whatnot, but it was janky and a sort of slamshod put together business and was pretty restrictive in the types of aiming I could use. The hardest restriction being that the height of the throw couldn't be altered on the fly =\ This had to be changed so I delved into the math behind gravity and how I could use that to determine arcs and such. The following is basically a math class for anyone interested. To some it'll be sort of hard math, to most it's basic physics with some intermediate algebra. All I know is, I remember when I was learning this stuff in school thinking "when the hell am I ever gonna need this crap? Quadratic formula? psshhhhhhh" but lo and behold, this shit's everywhere.
Physics wise, you can pretty much completely separate directional movement and the force of gravity. At least, in this game you can as I'm not going to calculate anything like wind resistance and whatnot. . . at least not yet. Getting the direction that an object should travel is easy. You just normalize the difference between the target and the object tossing the item. The problem is determining how fast this object should travel at a given launch velocity. This gets even more complicated (at least for me) when you start to factor in varying heights for the target and the tosser.
The base of applying gravity is simple. The speed an object is moving vertically is just increased by the amount of gravity over and over. This is simplifying things greatly if you're looking at the real world, but again, I'm working without any frictional drag. And also as of yet, haven't found the need to apply any sort of cap on fall speed. So, if I want to figure out the Y value of an object given a launch speed and an elapsed amount of time,
Y = launch speed * elapsed time - gravity * elapsed time ^ 2 * 0.5.
That right there is how I determine how high the targeting balls are to represent the arc the thrown object will take.
Now, if I'm talking just plain old flat ground, the speed that the object will travel is easy to find out. Basically, using the previous formulas, you can determine how long an object will be in the air assuming it was thrown from the ground, and will land on the ground. You can use an easy
time of flight = 2 * launch speed / gravity
Knowing how long something is in the air, you simply divide the distance between the two points and you know how fast you need to travel to reach the destination as the object is hitting the ground.
The real difficulty I ran into was figuring out the arc to hit the target when the target was above or below the tossing point. To get this bit of information, I ended up using the quadratic formula. First, I had to figure out if the target is above or below me using both their heights and getting the difference. If I always place the tosser at (0,0), I could use the QF, plugging in the difference in height as the Y value to figure out how much time, with a set launch velocity, would have to expire before the tossed object hit that height.
Time In Air Till Impact = launch velocity / gravity + sqrRoot ( launch velocity ^ 2 / gravity ^ 2 - 2 * target height / gravity)
With the knowledge of when in time, an object launched at a specific velocity would hit the ground at the specified height, I can now divide the distance that I need to cross by that amount of time and get the speed that the object needs to be throw in. And BAM.
I've got the core of all my gravity based targeting in place. It's set up in a way in which I can vary the height and if I wanted to, the speed of thrown objects. This'll go a long way in terms of enemy attacks in the future as well as giving the player more options. I'll still have to figure out a nice way to give the player control over their item throws, while balancing the complexity of the action. Progress.