Hello all! this is my development site for the game I am working on. I
will keep this site updated with the progress made in programming my
game. |
Updates
Detecting the Player's Groundtype
So, I have a variable within my engine that is called 'groundType.' It is an integer value that holds the value of the collisionType of the block that the player is currently standing on. This variable is what will be used to determine what animation or sprite to display when the character is standing on certain slopes-- the character will stand sure-footed on a flat block (square, or rectangle...), but will display a different graphic for when he is standing on a sloped platform. Initially, one would think that this problem would be easy as pie to figure out-- Couldn't you just pick the obstacle that is right underneath the player's feet, at the middle of player's width? This is not necessarily the case. What if a player is standing under half of the player's width ontop of a block, with the middle of the player dangling over thin air? What then? The answer: multiple checks. There are multiple checks that must be done, in order to correctly figure out exactly which block (if any) he is standing on. The following graphic can be found in our Dropbox folder-- it goes over the possible collision spots for proper detection of the player's groundType:  (Click the image to view full resolution) Well, most commonly, the player generally isn't going to be dangling precariously off of a ledge. So, we first check right underneath the middle point (1) on the graphic. If there is an obstacle underneath-- great! That is the correct groundtype. Even when the player is ontop of multiple obstacles, the one right underneath the middle of the player will be the correct graphic to be displayed. Next, we check the player's height-width/2 location, (2) on the graphic. This point is checked next. Why not check (4) or (3) next? Well, because, a player CAN partially enter into platforms when standing on the edge of a sloped platform with a square platform directly underneath (the bottom right case in the graphic)-- so, first we eliminate the farthest up point, and work our way down to point (4). After checking the center, and then the left, the right three points are checked similarly to the left side. If no groundType has been detected, the groundType is set to 1 (unless the player is jumping or falling, in which case it is set to -1), which is flat ground. This is perfect for what is needed, as occasionally, the player can walk flatly along the top of a lone sloped platform, as in the rightmost middle case in the graphic. I had been wrestling with this issue for awhile when originally programming this engine in Allegro, but just a few hours ago this solution came to me quite painlessly-- everything worked nearly immediately, with little headache... There may be a better way to detect which platform the player is standing on, but I can't think of any. This solution is quite simple to implement, and simple is good. Anyhow-- mainly been fixing bugs today, and I suppose I have two more hours until I should be heading off to bed-- so more bugs are to be eliminated shortly. Anyhow, later! - Falcon Five |
Dummy Blocks
I'm going to implement fake blocks that will be placed within levels-- these blocks will fill areas that the player can't get to-- on the inside of shapes and stuff, surrounded by real blocks. These dummy blocks will, when the level is loaded, tell real blocks not to bother with collisions on the inside-- for instance, a real block that has a dummy block on the right side, will essentially turn off the ability for that real block to collide on the right side. This will make the engine a bit more efficient in the long run.  Also, I have begun the porting of slopes from my old engine into the new XNA based engine. It is coming along, with plenty of bugs of course. Hopefully I'll get everything related to 45 degree slopes working by Tuesday-- perhaps even the smaller slopes-- but we will see. Anyhow. Later! - Falcon Five |
Level Test
Created a pretty big level (~10 screens wide, ~7 screens tall) (=7 2048 textues wide & 2 2048 textures tall) to test the engine with. Worked beautifully, with no noticeable problems. I will say however, that we are probably looking at changing to full HD resolution so that more characters will be able to be fitted on screen at once. This level is probably a pretty close approximation of the size of levels we are looking for-- maybe a little bigger? Dunno. Here's a picture of it, with possible concepts/ideas for the city level?  (Click on the image for the full resolution) Thinking that the subway area needs to be extended, like, much bigger, somewhere. And obviously, this is just for testing purposes, but may help with coming up with interesting ideas for our city level. We will make one level really big and really good. And then, hopefully when that is done, there might be time for more-- I was thinking ideally we could have three levels. But one well polished level is good too if time does not allow for three levels. Anyhow. Later! - Falcon Five |
Fall Through Blocks
are stupid. These are the blocks that the player can pass through from underneath, and then land on top of the block. If the player presses a certain button combination (usually down+jump), he will then fall through the block. Implementing these blocks have been a real hassle-- I overlooked these types of obstacles when initially coding my engine, and now, when implementing them, I basically have to tell my engine to disregard everything I have taught it up till now-- No engine, no! Do not collide with this block! It is special! Wait, now, yes, collide with the block! Wait, now the player is underneath, do not collide! But player 2 is on top of the block, so collide for him but not player 1!! WHYYYYYY After much headache, these blocks have been implemented correctly, save for a few little bugs that still need to be sorted out. In most games, if the player presses down+jump, he will fall through the block. For Robomb, it will be similar, but we will make the player double tap down, so that the player retains the ability to slide along the fall through platforms (down+jump=slide move). These blocks allow for great diversity in levels, and are a great addition to any platforming game. Hopefully it won't be too awkward for the player to double tap downwards. After deciding to do this, I actually happened to end up playing Super Smash Bros. Brawl at a friend's house. There were no available Gamecube controllers for me to play on, so I used a Wiimote to play (no nunchuk attached). I found out that when you play with the Wiimote, Smash Bros. uses the same concept we are implementing for Robomb-- double tap downwards to fall through these pass through blocks. This makes me feel a bit better about doing it this way-- if the pros (read: Nintendo) sometimes do it this way in order to retain the player's normal abilities on these fall through blocks, then I shall aspire to do the same with my engine. FALCON PAAAWNNNCH! Until next time! - Falcon Five |
Platforming Physics pt. 2
Glad to say that many of the initial bugs have been worked out in the current system, and some tweaks have been made to increase efficiency -- the Xbox can now handle up to 100 moving characters on screen at once... however, slopes have not been ported correctly yet, but I will be working on that soon! I look forward to it. Stay tuned for further progress!! - Falcon Five |
Platforming Physics
Hey guys. Been working on porting my character physics to the new game. Not going so well, however-- I have (with plenty of slight bugs) pretty much ported the system over, but it is not handling well on the Xbox 360-- I'm not sure why really. The code I had in C++ worked with hundreds and hundreds of characters-- the Xbox is having trouble with 20, and even my computer struggles with 100... I'm probably gonna look into doing a complete rewrite on my physics and collision detection code-- now that I know what I'm doing (having been working on my old Allegro engine for the past year and a half...), I should be able to do a better, more efficient Xbox friendly collision detection code. However, I will also be looking into tweaking my current code. That would be ideal. But if necessary, the rewrite will happen!! Anyhow. That's what's going on. Later! - Falcon Five |
Level Image Shennanigans
The levels for my XNA project, tentatively named "Robomb," will feature hand drawn graphics for the level. I've found out that XNA's maximum texture is 2048x2048 pixels. This means I will have to split up the textures at initial load time and display them that way. What does this mean? Well, for maximum efficiency, the levels need to be a multiple by width and height of 2048-- that way we don't have wasted space in the levels. I'm not saying the levels must be square, but they must have the width be a multiple of 2048 and the height needs to be a multiple of 2048. Also: levels need a 2 tile wide border at the left and right edges of the screen-- these don't have to be visible, just something to keep in mind: some older tube tvs (read: mine) can cut off as much as 10% off of the left side and 10% off of the right side. That means this: don't have anything terribly important to see/go at the first two columns of the level and the last two columns of the level. These need to be borders! Anyhow, time for some sleep!! Later! - Falcon Five |
On hold!
So, I've recently grouped up with two friends of mine, am porting my existing engine over to XNA, and working on a new platforming game with some mechanics similar to my old one. So, for now, my adventure platformer is on hold-- the new project will give me experience with XNA, and also perhaps will have reusable elements that I will be able to use for my platformer. I will continue to keep this site updated, however, as many things that I learn in XNA for the other game will apply to my platformer. Currently I am working on loading a tileset into XNA, and display a level, with a camera. It's coming along quite smoothly so far. Stay tuned! - Falcon Five |
Animation
Hello all! As of late I have been working on character graphics-- more specifically, animation. Recently I have ditched the old pixelated look of the game in favor of actually redrawing all of the old graphics in a new high definition format that will look quite nice once it is complete. One interesting thing is the way I am doing the main character's sprite-- it will actually be a compilation of three separate sprites layered on top of each other. First, the legs of the character will be drawn, and then on top of that the torso and head will go, and then after that, the character's gun, then the arms will be placed on top of it all. This will enable me to create more frames of animation without actually having a manually drawn out bitmap for each individual case. This will cut down on the time I have to spend on graphics by not making me have to draw out multiple cases for instance with the character running at a particular frame in the animation, but also aiming upwards. I can simply animate the feet, and then place the character aiming upwards graphic on top of that, without having to specifically create a running animation where the character is aiming down, left, up, etc. The programming will all animate this for me! As per usual, I will make a video once I've got a good animation test. This will make a big difference in the game's progress, and make it look much more like an actual video game, and not just some weird block video. I am also simultaneously switching the game over to XNA 4.0 so we shall see how long this will take! Anyhow, until then!! - Falcon Five |
XNA!
So I've decided I'm going to switch from programming my game in Allegro 4.2 to programming it in XNA 4.0. Pros - - XNA should have better vsync - Allegro 4.2's vsync would still display tears in the screen. It is a small detail that slowly drove me mad. I do not want my game to be the least bit jittery. - XNA works on both Windows computers and Xbox 360 with no changes in code necessary. I will be able to release my game easily onto an actual console when it is complete!! - Learning XNA and porting my game over will allow me to add C# and XNA experience to my resume :P - XNA might allow me to implement some graphical effects easily that would not have been as easily implemented into Allegro -- I'm thinking of eventually changing the terrain that the player traverses on to be displayed in 3d (hopefully with cel shading), instead of 2d, so as to add a more interesting visual style to my game. Cons - - Being a developer on XBLA costs $100/year. Lame. - Allegro (v. 5 anyhow) is easily ported to Windows, Macintosh, Linux, iPhone, etc. etc. because many ports exist. XNA only works on Windows and Xbox as far as I know. However I am not interested in porting my game to iPhone, due to the many complicated actions and buttons that will be in the game -- this is not suited to the iPhone at all. - Learning a new language and porting will pause development for a bit. But hopefully not too much -- surely porting from C++ to C# won't be too bad? And I already have a bit of experience in Java, and I've heard C# is terribly similar to Java. I will keep you updated on progress as usual on this site. Stay tuned! Regards, - Falcon Five |
1-10 of 18