Thanks to @nonused , Brad's got a few different hit sounds now and also a shout during selection.
You can get the new version here. Version 1.21 Download. Remember that you need to uninstall the previous version before this one will install.
I'm still in the market for a jumping, landing and firing weapon noise as well as a catchy selection thing or any other interesting sounds that Ryan may have made. I'll normalize the volumes of the sound effects once they're all in.
Also considering making Brad's explosions deflect bullets. Either that or be destructible.
Hey duders, a while back I did a game jam and made a stupid little MegaMan X GiantBomb crossover game. I did a poll afterwards to determine which Bombadeer I should create next. It was Vinny -_-;;
Now, from time to time when I have the time, I've been building him out. I've actually got a couple ridiculous twists to his fight, but they're a bit complicated so they're gonna take a while to actually implement the way I want it to work. . .
In the meanwhile, just last night, I had this stupid thought about what a Safety Brad boss fight should be like. . . and I just whipped something up real quick. He doesn't have his own level, and most importantly, I'm missing sound bytes. So I'm callin out to the duder community.
How can you help!?
If anyone could go through some old podcasts/quicklooks/breaking brads and rip out some wav files of Brad cursing or any other bytes that would be appropriately funny for his jumping, landing, dying sound effects and send them my way, it'd be a huge help. I'll go ahead and throw em in and put up some credit for you somewhere. That's it!
So anyway, here's a link to a version of the game that has Brad soundlessly implemented. Knock yourselves out =)
A point in polygon check is exactly what it sounds like. It's a check to determine whether or not a point lies inside or outside of a given polygon on a 2D plane. These types of checks are fairly common in video games and especially so when dealing with rectangles and circles. A very easy example would be your mouse cursor over any type of interface. Your mouse pointer has a coordinate, and that coordinate is typically being checked against a bunch of polygons (though usually in interfaces they're just rectangles and circles. . . more on that later) to determine whether the cursor should change shape and what should happen when any buttons are depressed.
What up with Rectangles and Circles?
Checking a point against a rectangle or a circle is super easy peasy. For a circle, all you need is the center point of the circle and its radius. You check if the distance between the center point and the point you're checking is greater than the radius of the circle and if it is, not inside. Otherwise. Inside. Done. For a rectangle it's also pretty damn easy in that you just check if the point is within the left and right sides (x) and also within the top and bottom (y) of the rectangle and you're done.
Once you have to start checking against irregular shapes, things get a bit more complicated but not to worry because there's plenty of resourcesonline. The type of check that would work best for your needs depends highly on your specific needs. A small list of the types of things that could determine which methods might work best for you include things such as:
1. Which is more important, speed or accuracy.
2. Whether you're working with floating point numbers or integers.
3. If all your polygons are concave.
4. Whether your polygons have holes in them.
5. The number of polygons you need to check against.
6. The number of points you need to check.
7. Whether or not you will be breaking your complex polygons down into triangles.
There are plenty more factors which should determine what methods you use in your game/program.
Popular methods include
Hmm. . . I was going to write up a bunch of methods, but really. . . it's mostly just math. In most cases involving non-convex, complicated polygons, you'll probably use some form of ray-casting to determine whether your point is inside or not. That's a method where the point in question has a line drawn through it and the number of borders in the polygon is counted to determine whether it is inside (odd) or outside (even) the polygon. There are some issues with this method with the largest being floating point precision issues.
Floating point what now?
This can get super technical and you can find endless reading material on it just by searching Google for "floating point precision".
The super watered down, I don't give a shit about math version is that programming uses different types of containers for numbers. The higher the accuracy of a number you want, the larger the container needs to be. A bit can be a 1 or a 0. A byte can be between 0 through 255. An int can hold -32,768 ~ 32,768 etc. For the calculations that are required when working with decimals and fractions (which we are for point in poly tests with non-rectangular shapes) you use floats and floats are squirrely bastards. They can hold up to 7 digits with a decimal point within somewhere which gives you a pretty damn good range but when you go over that (as you generally do when working with crazy fractions), the numbers can sorta shift around. So, when you do some math one time, you may get 1.234567 but you do the exact same problem later and you could end up with 1.234568 or 1.234566 or seemingly any damn random number filling that last spot that floats can't go beyond. So even though it's a small as all hell error, that tiny amount could mean the difference between a point being in a polygon and not. Soooo. . . if you need to be uber accurate, it could cause issues.
Why. . . Why all this?
I originally just wanted to post about some progress I made today with my game. I had spent around 2 and a half to 3 months working on the vision portion of my game engine to accurately simulate line of sight in a 2D isometric world and after trying a bunch of things, I found that the best way to do it would be to create polygons for in world objects/walls/floors/etc and then test points to see whether things are seen or not against those polygons. Now, the way I'm doing it is different from other 2D games with line of sight in that I didn't just want horizontal line of sight, but vertical as well because it's isometric with multiple vertical floors. Anyway, basically I went from this
During a vision check, it would take almost half a second to finish because I was running over 3 million point in poly checks against 6,539 polygons. I set up the test to take place in manufactured situation that the player probably wouldn't encounter but they might and I'd rather the game not chug if they do. When I first plugged in the debug methods to check exactly how many times it was running the point in poly check, and more importantly, how many of them were hits rather than misses, I was pretty shocked. Less than 0.01% of the checks were returning as hits meaning that 99.99% of the checks were fails. . . I had already set up the method to cull out any polygons that they were nowhere near but I had to do more. What I ended up doing was increasing the fidelity of the array that was populated by the polygons which increased the number of polygons added to arrays from 11,116 to 92,322 but the trade off was close to 3 million point in poly checks. Also, the time it takes to run the method dropped by around 85%. So barring any memory issues, I think I'm on the right track =)
Oh, and the new hit count is around 21% which isn't bad at all in my opinion. I'm fairly decent at FPS games and my hit rate is rarely that high. I mean, because that's what I should be comparing it to right? -_-;;.
So yea, that's it
My quick status update of "Totally reduced the amount of time it takes to run a function today" into this mess. So I'll pretty much end this blog with a big ol "Fuck floating point precision errors!"
For my friend's baby shower, they had the idea of getting together a bunch of pictures of themselves and cutting out their features to allow party goers to construct predictions on what their baby would look like. They were having trouble getting the various pictures to print out at a normalized size that'd work so me being the computer/art guy, asked if I could help. After sorting through the pictures, I decided I could resize them, but they'd all look like crazy magazine ransom note cutout constructions.
Wouldn't it be better to just make a program where you could choose which features to use and then print them out on a printer instead? So I made this thing.
The husband's features are on the left, wife's on the right and multiple clicks would cycle through available versions. I also added in a couple for fun thingies because why not? I guess it ended up working out okay at the shower =)
It's stupid I know, but I love that we live in a world where this kind of nonsense can just happen =P
In all, the thing took around 6 or so hours to make. Most of the time was spent sifting through pictures and color correcting so that they'd work with each other. I'd say 4 hours on the "art" side with 2 hours on the coding.
So, I finally got around to getting a third monitor.
It's an Asus PA248Q and after about 4 or so hours of use, I have to say, it's a damn fine monitor. The colors seem right (at least to my colorblind eyes), and the swivel/pivot functions are awesome. Also, it has every kind of input you can think of on the back which allowed me to plug it into the DisplayPort on my video card. This allowed me to continue using my two DVi inputs for my Samsung and Wacom monitors and still have my TV plugged in thru HDMI. I guess technically this means I have 4 monitors hooked up but I leave the TV off unless I want to have some video playing in the BG while I work.
It's actually a 50 inch TV but it looks so small -_-;;
In any case, back when I got a second monitor, I couldn't remember how I ever made due with just one, and already I don't think I could go back to two! Honestly though, I did feel I needed the third because I'd always have 8 or 9 windows that needed my attention at any given time along with handwritten notes and I was spending an extra 10~15 seconds every time I lost track of one trying to find it. It may not sound like much, but as any starcraft player will tell you, over the course of a larger period of time, those seconds really begin to add up. Now I get the feeling it'll only be a few more months before I want to get yet another screen. . . 1st world problems indeed.
1920x1200 VS 1920x1080
I'd also like to point out that it's 1920x1200 instead of the more popular 1920x1080 that fits the 16:9 aspect ratio of most movies and tv shows nowadays. 120 more pixels vertically may not sound like much, but it actually has way more impact than you'd think. This is especially true when you use the thing in portrait instead of landscape. It's also interesting in games because you don't realize you're missing that space up top till you get it back. I have no idea when I switched to 16:9 monitors (maybe 3 or 4 years ago with my left side monitor) but I'm diggin' the extra I'm gettin now.
I'm still crankin away -_-;; I've just rediscovered threading and have been working to make things "thread safe" while improving performance. I'm almost done with setting up the vision stuff meaning I'll shortly be getting into the lighting. Lighting may take a while (possibly a month to get it right) so I'm dragging my feet just a little bit because it's so daunting. Though, dragging my feet means rewriting a bunch of stuff that makes everything run smoother so it's not actually a waste of time or anything. I'll hopefully have something worthwhile to post in the coming weeks. =)
A short small update. Pretty much what I've been up to today -_-;;
You can select things with a mouse!
Something that should be super damn basic right? Well, you'd think so until you try to implement it yourself. Up until now, I was using the mouse's position on the grid to determine which object should be selected, but this wasn't exactly a great way to go about things since in any given grid, you can have a floor, an object on the floor, 4 possible walls in each direction and an opening (door/window/hole) or wall object on any of those four walls. So with only which grid space the mouse is on, it'd be very difficult to determine which of any number of objects the player wants to interact with. That being the case, being able to just point at an object and have it be selected is critical to ease of use.
Per Pixel Sprite Selection
Initially, I was looking into per pixel collision detection to determine which item would be selected. The method of working this way is to create a fresh render target each frame and drawing all relevant sprites onto this render target as a solid color. Each sprite would be drawn a different color and given an index number. Next, the render target would be casted into a texture file at which point, you can grab the specific pixel at the location of the mouse pointer. Then you can check the pixel's color against the indexed colors of every sprite you've drawn and use that to determine which sprite the mouse is over. It worked. . . but not in a couple important ways that I wanted it to. The most important being that selecting objects behind existing ones became impossible. So say if there was a large object in front of a smaller one, the one in the back is impossible to select. . . So scratch that one.
Rectangles. It always comes back to Rectangles
So, back to the drawing board. Lucky for me, all objects that are selectable already have heights and widths and my previous work with the level editor also stores each objects modified positions. Using these things, I'm able to construct collision rectangles that exist in the game world and using those, I can check against the cursor to determine if an object is being hovered over by the mouse. While not pixel perfect, I got it working to a pretty solid state of usability as shown in the video. Next I had to tackle the same problem I had with the Per Pixel selection. To do this, I ordered the collision checks between the objects and the mouse from closest to the camera to furthest and then based on whether or not the object in front was an object that is in front of something else, tested the object behind as well. If there are no objects behind, then the first object is the one to be selected. So far, it's working reasonably well and I do feel there may be some problems that might arise in the future (especially with huge objects that take multiple spaces), I think I've got a pretty solid foundation to work off of. That's about it for now.
I've put some more work into fleshing out the level editor. Namely, I've added options to begin adding windows, wall objects (posters, clocks, basically anything that can go on a wall that I want the player to be able to interact with), wall/floor decals (visual things that don't have interaction applied to them like blood splatter, bullet holes, cracks, dirt, etc) and most importantly, a settings menu. The reason why the settings of specific objects is important is because this ability to retrieve an object's settings, and modify them is critical to being able to create proper saved levels. This way, when I save a level, I can save each individual object's state (damage, open status, placement, anything else I want to add) instead of just its location in the game world.
If you look at the prior doors video, you will see that when I selected doors as the object to manipulate, a graphical interface of a couple buttons popped up. While this worked fine, it had a major problem in that every door only had the same options available and those options were only toggleable (sp?) on and off rather than any numerical settings. The way I got around this is for every object in the game to be able to have an Interface applied to it that allows the retrieval of a list of settings and also for that same list of settings to be modified and then applied to the object. So when I select doors, the door appropriate settings become available for modification. I can also go so far as to giving different types of doors, different additional options. For instance, if a door is a sliding door instead of a swing open type door, the bulk of the options pertaining to which way a door will swing when opened will be moot so they just won't exist for the sliding door. This type of personalized list of settings can be placed onto any object in the game as long as I decide to apply the Interface to that object.
The importance of settings to the saving/loading of levels
I've been trying to wrap my head around how I was going to save not just the layout and positions of the objects in the game, but also the current health, open or closed, locked or unlocked, position and all that other important information as well and implementing the settings is sort of a two birds with one stone deal. Now when I get around to saving the levels and loading them up, I can just retrieve the settings from each individual object and save that information. When loading up a level, it can then implement the status of every object as it places them into the game world. Yay!
Another new little bit that I felt was important to the level editor is the ability to search through the available options. I'm going to assume that later on, I'll have a ton of assets and it'd be painful to have to manually scroll through everything to find what I want. So, I went ahead and implemented a search feature. In the future, I plan to further break down the search results to specific types of the searched item or maybe even display a list of results to choose from rather than just regulating the ones that you can scroll to in the editor. This may seem pretty easy (and if you know what you're doing, it is) but it was a pretty big ordeal for me.
XNA does not inherently support keyboard input. It supports the chatpad (yay?) but unless I decide to pull into the game XBL stuff (which I don't want to), there's nothing built in for getting text. The first thing you'd think to do is to just check the keyboard state for every letter and determine if a key was up the previous update cycle, and is now down indicating that a key was pressed. Then you could figure out which key was pressed but the problem with that is that the game will only update 60 times a second and there's a chance that there might be slowdown causing keys to be missed. A bigger problem still is that what if there are multiple keys pressed during one update? Most people can type faster than 1 key per 1/60th a second. Maybe not consistently, but there are times when you're typing and the difference in time between two key presses is smaller than 16ms. I'm already rambling but long story short, I set up a text buffer that would catch every key and then log them in the right order. Shit wasn't easy, but nothing ever is until you learn how to do it.
Windows, Wall Objects and Decals
I've also added the above mentioned types to the editor for placement and settings. Windows is self explanatory but the other two may not be -_-;; Wall Objects are any objects that are placed upon a wall that can be interacted with by the player or other game entities. These are things like paintings, barricades, Shelving, etc. Decals (floor and wall) are art only things that can be placed in the game world. This would be things like bullet holes, scuffs, dirt, blood, whatever else. These things could also be implemented in a way so that the player could initiate an action on them such as cleaning something up or whatnot (and they also add visual obstructions such as if you were to paint a window black) but they are things that can not be picked up or used in any physical manner.
Modify an object already in the world
One of the last things I did was implement object modification. Before, whenever I wanted an object to have different options set, I would have to create that object and have it replace the existing one. Due to the way I've got the whole settings thing (above) implemented, now I can select an object and directly modify its state. Wooo! Of course, it wasn't a big hassle to copy an object's settings, then change what I want, then place it back into the world but this just feels nicer. With the added bonus of it changing on the fly in the game world so I can see what it's going to look like.
Back to Work
Anyway, just a quick update. I'm going to get back into it now. I've also been putting in some work on adding Vinny to that Megaman X GiantBomb thing from a while back but since I'm not doing a jam type thing like before, it's mostly super short sessions where I'll draw a sprite, implement an attack, brainstorm ideas. . . that kind of thing. I haven't dropped it, it's still coming eventually but since most of the work is bits and pieces, there isn't much to show. I did just implement an attack that I think ya'll will enjoy. . . maybe. . . maybe hate. I dunno. This is a boring wall of text for most, but hopefully some of you'll get a bit of enjoyment/insight from this madness.
I've been working on doors for the past week and half or so straight whilst also modifying and tweaking other areas like vision. . . Actually, I've completely rehauled the way my vision checks are ordered which make them work better, but slower. In any case, the focus of this update is doors -_-;;
Something I've sort of noticed in games is that doors aren't really all that involved. In most cases, they are either impenetrable invisible walls to areas that aren't accessible or just a way of blocking progress until an objective is met or a key found. Apart from opening and closing, there doesn't seem to be all that much emphasis placed on their existence. Also, in isometric games, they have even further reduced properties. What I aim to do is have doors function as they would in the real world. First thing I need is for them to be able to operate and function like a real door which includes the following.
Have an outside and an inside. The outside is considered to be the side of the door that requires a key to unlock.
Optionally be a right handed or left handed door to control which way the door swings when opened.
Have proper vision blocking properties. Doors when opened or closed should not be able to be seen through. This is done automatically in First Person and Third Person games but I have yet to see it done in an isometric top down game.
Be locked and unlocked from the inside and require either a key or lock picking from the outside.
Have the path that the door takes when opened or closed be taken into account. You cannot open a door that swings towards you without taking a step back and you also cannot magically close a door that is swung open away from you whilst standing outside (you can't close a door you can't reach).
As of now, I've tackled 1, 2, 3 and 4 and am currently working on the 5th step. While building out the door class, I've built in a way to take into account the area the door swings through when opened or closed but haven't yet implemented anything there yet because I still need to figure out how I want the player to be able to control which way they move when they are interacting with a door. Another reason why this door swing area is so important is that when you barracade a door by moving furniture in the door's path, the door shouldn't be able to just swing through it willy nilly.
There's actually a whole lot of information out there on doors and things like building codes. Some small interesting examples I found are things like how in any commercially used building, exit doors always have to open towards the outside. This is so that if there's ever a situation where people are crowding the door to exit, they'll be able to push it open rather than all be stuck because it can't be pulled open due to people pushing from behind. Also, it turns out when doors are placed, they typically open so that the door is flush against a wall when in the open position for space reasons.
Notice how all the doors when opened are up against a wall. Maybe I'm just thick, but I never noticed this before and ever since I've been focusing on doors, I'm seeing this everywhere I go. Especially in smaller spaces such as bathrooms. Another small tidbit is that front doors to houses tend to almost always open towards the outside as well. Though the reason for this is because it's harder to break down a door in through the frame than it is in the direction that it opens. That's something I'll really have to take into account for door breaking scenarios that don't involve prying it open with a crowbar or some such nonsense =P
So, once I decided that I needed to have doors that open in every which way and be shown in those open states as well, I had to figure out how many different states the doors would be in. So I whipped this up.
It's super crude but coupled with the excel file it's attached to, I had all the different properties of the door in it's open and closed states. I basically needed 12 different door states. (I think I'll eventually need to make doors that swing open a full 180 degrees instead of just the 90.) I worked it all out to where I actually only needed a very small amount of art assets to be able to draw a door in all these positions. It actually ended up being just this.
The back end of the frame, the front end of the frame and two door versions. One with the knob on either side. Armed with just these sprites, I could create doors in all 12 positions listed above =) The frame has to be split as shown because of the way the door needs to appear above the back part of the frame yet behind the front part of the frame and also to work properly with the stenciling I've got set up to create holes in the walls that can be seen through when rendering everything together.
Now that I had the damn things represented visually, I needed to figure out a way to get them to block vision properly. Br properly, I also mean that the player should be able to see through doors in the fashion you would in real life. For example, the door above has a window, so the player should be able to see into the room the door is placed on, and also through the window when the door is opened and the player is looking in that door's direction. Well, I won't get technical because I'm not sure I could really explain how I did it without first explaining the way my vision works in game, but I got it working as you can see in the video =P
I'll annotate the video eventually, but for now, you can see the various things I've been talking about at work. Doors that open in multiple directions. That can be locked and unlocked from the inside but not from the outside. Doors that can be seen through to a certain extent (the characters are placeholder and will be taller and proportional to the doors eventually.). Etc. . .
Still to be done
There's still a damn lot of work I need to put into the doors before they're complete but I feel I'm making decent progress. While I mull over how to allow the player to have full control over which direction they move in when opening and closing doors, I will be implementing double doors and sliding doors. The way the class is set up, they can also just straight up be windows so I may try putting one or two of those in to make sure they function properly. In any case, progress! It's been quite some time since I posted anything about what I've been working on, so I thought doors might be an interesting little bit to write up. Comments, questions and suggestions welcome =)
Just a real quickie, Rastamen asked about mouse look, and it's in the game. Here's a short vid. Very short.
The voting for the next Boss has been completed. Vinny Wins -_-;; Whenever I have some free time, I'll put together a Vinny Boss fight next =)
or at least, free boss fight =P I did a quick and dirty game jam that I sort of posted updates on here.
It's my first time attempting to build a game out for distribution so I'm not entirely sure if it'll work and how it works on other people's comps. If it doesn't work, please let me know along with whatever errors you have. If it does work, drop me a note on what you think =)
If you've already installed, you must uninstall before installing the new version.
added respawn on game over screen if you lose.
tweaked ryan's attack so there are no impossible situations.
adjusted attack a bit more
lowered the low platforms a bit
reduced lifetime of ryddok's bullets
added start select arrow
attempted to be compatible with more video cards by dropping DX10
fixed various bugs such as music continuing to play after ending and also being able to fire while READY is flashing
Added a SLIIIIIDEEEE!!!! Down + Jump!
C button also fires weapon to allow both left/right combinations of jump/fire
Balance changes to keep things more fair.
Ryddok no longer moves before the player can.
Humming birds further spread apart to allow dodging through any combination.
Boundaries changed to prevent extreme travel through walls for Ryddok.
Full collision with all platforms.
V1.15 ~ V1.18
Made a large amount of changes to the structure of the program to support extra bosses and potential levels.
Changed the camera to have movement functions
Begun implementing basics of Vinny as a boss character
Added a select screen in which currently only Ryan is selectable.
Quickly added a difficulty selection. You can now play the game on Easy. I'll prolly change the attack patterns a bit based on which difficulty is selected but for now, it just reduces the damage taken by Mega Man when hit.
Please head to above link to get download and leave any questions/bugs/comments there if possible =)
In the beginning
In honour of this new beta site and because I spent the last 4 months working on a vision engine followed by 2 straight weeks of working on just how doors function, I think I'll be spending the next two days or so on a quick and dirty single screen game jam related to Giant Bomb. I'll post details once I start tomorrow here. In the meanwhile, if anyone is interested in contributing some music or say some sound effect work, please let me know. I'll be handing all the programming and the majority of the art.
Since this is going to be a super small scale project, I'll prolly go with something simple, quick and easy. Right now it's a tie in my head between a Giant Bomb themed bomberman game and a Megaman boss rush. Maybe using some of the sprites from one of my previous blog posts.
I'm sort of leaning towards the Mega Man right now since I really don't want to deal with any net code as that'd make things difficult to the point that it'd prolly take longer than the 2 ish days I'm willing to devote to this thing. As awesome as a giant bomb bomberman would be. . . it'd be a really sad and boring single player experience =\
So I originally posted this on the beta site, but seeing as how all that's gonna disappear, figured I'd put it up here as well. I was gonna do it tomorrow but I sorta settled on the Megaman thing and wanted to get my hands dirty. I found a megaman spritesheet and just got started.
What I've got done so far is the bulk of MegaMan. He can move, jump, shoot. . . which is just about everything he can do. I was considering adding his slide but figured he wouldn't really need it.
I've also put in basic collision detection so that he knows when he's on the floor and when he's not. While it's not shown here since it's just one big floor and platform, he can also run into walls when I want them to be solid. I'm fairly happy with how simple everything seems to be but since this was originally an NES game, I don't know what I was expecting =P
I also added in some of the traditional megaman sounds we all know and love.
Finally, just for the sake of it looking like something Giant Bomb related and not just a remake of Megaman, I went ahead and threw in Ryddok.
Here's where I'm at as I go to bed -_-;;
Things to do.
I need to build out the HUD which will pretty much just consist of a life bar for Megaman and the Boss enemy. I think that'll be pretty easy to do, I just have to get around to it.
I need to draw and build out Ryddok as an actual boss character rather than have him just hovering and following Megaman around. I'm thinking this is where the bulk of my remaining time will go. I'm prolly going to settle for 1 or 2 ranged attacks, and some attack movement patterns. So, I'm guessing say 3 to 4 frames of animation per attack plus a taking damage sprite. Shouldn't be too difficult.
A title screen. Most likely, I'll just use that megaman pic I worked up of giant bomb so this also shouldn't be a problem.
This entire thing was built up from scratch with the exception of the megaman sprite sheet using XNA and C#. I'm pretty happy with the quick and easy progress and very hopeful to actually finish this thing in the next day or so. Once I finish, I plan on figuring out how to package it and share it with anyone who wants to give it a run -_-;;
Need Help With
I could still use some music if anyone is willing to take a stab at it. If not, I'll prolly just end up picking a favorite from one of the many available Megaman tunes. I'll also take any suggestions anyone has into consideration on what Ryddok's attacks should be. Hell, if you can work some pixel art magic, I'll even use what you put together =)
While spinning a whole bunch of plates, one of the things I'm trying to nail down is the proportions of the characters. In most cases, I prefer the look and feel of characters that have exaggerated proportions (big heads, short legs) over normal proportions when it comes to pixel work but the game I'm building is going for a very sim like level of realism which is causing me to question which way I should go.
I've finally begun to implement height as being a real thing when it comes to vision and looking over/under things. I've got it worked out to where one inch of vertical measurement = 1 pixel. I've already modified all the current walls I've got built up to the new heights but I'll have to change the height of all characters to match the new system to make things look right visually. Now I've got roughly 30% more space to work with vertically on my characters so I need to decide whether I want to go stylized or try to retain realistic proportions.
Here's a quick mock up of the misproportioned style of characters and what they might look like in the game I made using some hopefully recognizable figures =P
If I decide to go with the stylized look, the characters won't be as tall as they would need to be to fully reflect the 1pixel = 1inch measurement system but there'll be enough of a height gain to not cause things to look way out of whack. Also, I'll have a little more width to work with for most of the bodies. If I were to go full on realistic proportions though, they would be about a head taller than what you see there now and only slightly wider. Discussing it with a friend, I may need to just go ahead and mock up both and see which one feels right interacting with the game world. Most likely, I'll have to do that but I figured I'd ask around and try to cast a wider net of opinions just to see what ya'll have to say about it.
Vision Cone What?
Here's a video that may or may not have finished uploading by the time you read this that shows what I mean about the vision cones working vertically. short walls obstruct vision as it would in a FPS game where if you're taller than the wall, you can still see the floor beyond it if you're taller. The closer you get to the wall, the closer the floor you can see since your angle of vision downwards will become steeper. This is also true for if you're standing on a higher elevated floor. Vision will play a very important role so this type of vision cone stuff has been a pain in the ass to program and still needs some tweaking and optimization but I've got a system that works for now =P
Sorry if my post isn't fully coherent as it's almost 1am and I really need to sleep.
For an isometric turn based game, do you prefer stylized proportion characters like FF Tactics or realistic proportioned characters like in the old Fallout Series?