27.04.2012 - More progress ------------------------------------------------------------------------------------------------------------------- 27.04.2012 * Fixed the bug that I believed had to do with the RoutineList and FadeToBlack subroutines. The real problem was in fact that when KillCharacter deactivated the last active character slot, it also overwrote the palettes so that when next time uploading the palettes, it produced different colors. It's now fixed. * Made the enemies stop for a while when they collide with each other. This makes it more unlikely for the enemies to be ontop of each other and be seen as one unit by the player. * Made the player interact with the machine. When touching the machine meta-tile a special subroutine is called. * Wrote that special subroutine that will refill the oil timer and place the oil can back on the floor at a random location. ------------------------------------------------------------------------------------------------------------------- 26.04.2012 * Made enemies be able to take more than one hit before dying. * Made player be thrown away from enemy when colliding with him. ------------------------------------------------------------------------------------------------------------------- 26.04.2012 - Major update I've still been working on the game engine. Here are the things I've been working on: ------------------------------------------------------------------------------------------------------------------- 25.04.2012 * Made Enemy AI to NOT overrun the showdeathanimation routine. Problem was that enemy AI code overrun the death animation so that the enemy did never die. * Moved the RoutineList array in RAM a little later in the RAM page, this cured the problem with FadeToBlack that was halted in the middle if graipen was used. Not a good solution by any means, but worked for now. The bug that caused it is still there, haven't found it yet :( There must be some routine that overuses some variable or something else or whatever... * Made character to character collision detection :) * Made EnemyHit and HeroHit subroutines that deals appropriate damage to the respective characters. * Made So that the player is immortal a short while after he is hit, like in normal games. ------------------------------------------------------------------------------------------------------------------- 22.03.2012 * Made the general enemy movement update their target not only when they reach their old target, but also every X frames. This made them much more unpredictable at close range, but at the same time the player can control them more easily on a distance. ------------------------------------------------------------------------------------------------------------------- 21.03.2012 * Tested on RetroDuo, seems to be working properly (same as emulators), some difference in colors noticed. ------------------------------------------------------------------------------------------------------------------- 20.03.2012 * Made Enemy to Wall Collision detection. The logic is; it searches for an enemy among the character slots, the first character to be an enemy type character is chosen as the first character to be checked. The second character is then taken from the CharNext variable of the previous character. It's CharType is always checked so to make sure it's an enemy type character. Depending on it's CharFacing variable different directions are checked for obstacles. If there is an obstacle the character is ejected out of it. Also, when collision occurred the CharAction is set to 5="pick random direction", however the "pick random direction" routine is NOT YET completed, instead it simply alters the CharAction to 0=accuire new target coordinates. ------------------------------------------------------------------------------------------------------------------- 14.03.2012 * Made ProcessEnemyCharacters which is the enemy AI. Every type of enemy has it's own AI-code. Using a jump table and the CharAction variable, the subroutine is determined. * Made the generic movement routines, and put them to be used by "Basil" types of enemies. ------------------------------------------------------------------------------------------------------------------- 02.03.2012 * Implemented Blargg's TV system detection (PAL/NTSC), variable name is "ntsc_if_neg". made a text display on title screen saying whether it's running NTSC or PAL mode. ------------------------------------------------------------------------------------------------------------------- 28.02.2012 * Fixed a fundamental bug in the ShowDeathAnimation routine that made it impossible for two characters to die at the same time. Now it is possible to kill several characters at the same time. ------------------------------------------------------------------------------------------------------------------- 27.02.2012 * Made the spawnCharacter routine select the correct x-index when calling ForceAnimate. This fixed the problem with graipen/KillCharacter/SpawnCharacter. ------------------------------------------------------------------------------------------------------------------- 11.02.2012 * Made MovePlayer call ForceAnimate when changing direction, so the animation is immediate ------------------------------------------------------------------------------------------------------------------- 10.02.2012 * There was a problem with graipen weapon attack routine that I fixed with a ForceAnimate subroutine. so now when a character is spawned it's first frame is immediately animated, making it appear at once. ------------------------------------------------------------------------------------------------------------------- 09.02.2012 * Tested on hardware, it works just like in the emulators. * Made KillCharacter free up slot also for graipen. * Made the foundation for B-item usage in sub_DoButtonActions.asm ------------------------------------------------------------------------------------------------------------------- 31.01.2012 * Made B-items able to be picked up by touching them * Made B-items selectable by pressing SELECT button, now also visually presented in status bar * Made Graipen weapon character, which is like a fork type weapon :) ------------------------------------------------------------------------------------------------------------------- 30.01.2012 * Made AbortFadeToBlack check if fading is ongoing or not before aborting. * Made SELECT change Current B item, does NOT show visually yet, ONLY affects variable CurrentBItem ------------------------------------------------------------------------------------------------------------------- 27.12.2011 * Fixed the loading of Game Over state. It's now loaded on separate subroutine! Just JSR GameOver to change state. * Made AbortFadeToBlack subroutine that stops the fading and restores the palettes. ------------------------------------------------------------------------------------------------------------------- 25.12.2011 * Made the status bar show which level is current one. * Made game over state return to previous state (level), similar to pause state ------------------------------------------------------------------------------------------------------------------- 20.12.2011 * Made MovePlayer recognize "illegal" key presses (left+right, up+down, three directions) and use "NothingPressed" as their value. * Made the main character's background collision detection work well. It's now possible to walk very close to the walls without getting stuck. * Made ShakeScreen routine. It's part of the RoutineList system (element +2 of RoutineList) * Also added SoftScroll variable that is copied to PPU scroll register PPUSCROLL every VBlank ------------------------------------------------------------------------------------------------------------------- 10.12.2011 * Made MovePlayer move the player in only one direction at the time. A 'CurrentKeys' controlled jump table decides which way the player is moving. * Made item spawning system, can now put items on screen, fully sprite cycle compatible with characters' sprites. ------------------------------------------------------------------------------------------------------------------- 08.12.2011 * Fixed the NTSC/PAL nametable loading problem, the NMI was altering the PPU registers while the 'upload nametable' routine was using them. * Tested the game on real hardware for the first time (RetroDuo, ciclone not working). Everything is good, but there are random sprites appearing on the title screen randomly when powering on, when the console is reset only the characters are there. Is the solution to upload new data to PPU in reset routine??? * Fixed the random sprites showing up on power up on title/intro screens, I did not inc NeedDMA until the level1 state so the content of the PPU sprite memory was undetermined. ------------------------------------------------------------------------------------------------------------------- 14.11.2011 * Compressed the nametables even more with the "use only a nibble per meta tile" technique Now there seems to be some problems in NTSC mode with both emulators. ------------------------------------------------------------------------------------------------------------------- 11.11.2011 * Made Routine List which holds 5 routines. They are run every frame when they are activated. * Made the background fade to black routine and also included sprites to become darker. * Made the KillCharacter routine display the death animation, using RoutineList technique. The Characters have also been given damage and health variables. when death animation starts the damage goes to zero, making the character harmless (because he is dead) while death animation is playing. ------------------------------------------------------------------------------------------------------------------- 10.11.2011 - Completely rewritten the whole program Yes, I have rewritten the whole program to become easier to maintain. I have however used a lot of the old code but improved upon it. Some of the improvements are that now every subroutine has it's own file, and because I know a little bit more about the concept of a game engine I for example use a lot more buffers in RAM for various things. Another big difference is that I try to make all the subroutines very robust but simple and elegant instead of hard coding so much. The object handling subsystem is now taking care of all the characters in the game. I have one subroutine for spawning characters and one for killing characters. The characters are stored in slots and each character nows which slot the next active character is in. So when processing the characters iteratively in subroutines I don't have to care about which slot they are in. For the main character (Hero) I have implemented 16-bit coordinates and acceleration based movement. All the enemies have 8-bit coordinates and doesn't accelerate or decelerate, they are just moving/not moving at a fixed speed. I am currently working on the OAM cycling (sprite flickering) to be able to show more than 8 sprites per scanline. Well it looks like this, except Youtube makes it look a lot worse than it really is, so try the .nes file instead if you are really interested to see the real deal. 10.07.2011 - Object handling system completely remade I have completely rewritten the whole system for handling sprites and objects on screen and in RAM memory. The way it's set up now is so that I only need one subroutine for all objects, instead of one per object which is unreasonable, for instance now I only have one background collision detection subroutine that iterates through all objects, like enemies and the hero, using the X index register. Unfortunately the lives and point system is now gone again and may return in another form later, who knows. I don't have a game design document to follow, as this is the first real game I ever make I want to have the freedom to just try things out and change things as necessary. In addition to the object handling system I have implemented a weapon, another enemy (well it's the same one, different color), sprite flickering and the ability to carry an item with you. In the process I have ruined some parts that were working before, for example the point system, life system and the enemies ability to kill you, well this is just disabled for debugging reasons. The weapon that is now implemented is a pitchfork like weapon Currently there's two enemies, two items and the hero on screen and because of the NES's 8 sprites per scanline limitation I have made a simple sprite flickering system to show them all, but it flickers too much, it's annoying, there must be some better/smarter way of doing it. I'll look into it. The enemy AI is still not good, thing is that if they hit a wall they will try to go in a different direction, but they are not as smart as I want them to be, in addition to that, because they are controlled by the same routine they will most of the time take the same route towards the hero, this will cause them to actually be on top of each other and appear as one. I will definitely need to make some collision check between them, and when a collision occurs, one of them can change direction or something. I'll look into that too. I've also made so that the hero can pick up items such as the oilcan and the pitchfork and he will keep holding it until button A is pressed, this is a work in progress ability, but it sort of works a little. Well here's a video clip, it's short and shitty quality so enjoy. 20.04.2011 - Point & life system You now get points for every time you refill the machine, and you loose one life for every time Basil gets you. I have uploaded the new ROM.  17.04.2011 - First animation video No real update, just another short video, this one is meant to show the animations. The enemy is temporarly moving very slow, it's for testing purposes. 14.04.2011 - Main character animation The main character has now got some animations for movement in the four directions plus one separate animation for idle. The sprite CHR ROM looks like this at the moment.  The enemy, Basil, doesn't have animation implemented yet but I've drawn some sprites for him as well, although they aren't in use. The main character's animations are nothing but 2-frame animations but according to this: Tutorial: Walking Animation for Low-Res Sprites it can look good if done right. I wanted to go with 4-frame animations but when dealing with those the memory just isn't enough. The ROM is coming soon, I just found a stupid bug that I don't care to fix right now, so I'm not uploading the new ROM just yet. 06.04.2011 - First enemy One enemy has now been implemented, his name is Basil and this is what he looks like at the moment:  . He can move around without restrictions so far, but in the future he will also be bothered by all the walls and obstacles. If the player is in contact with Basil, then one life is gone. The player has three lives to start with, after they run out it's game over. The lives are not visually represented as of now but they will be in the future. Another thing that's implemented is that the player can now pick up the oil can item and place it in the items boxes in the status bar.When I did the research on how to program the enemy AI I was considering the path finding algorithm A* (A star) at first. The A* algorithm basically looks for every possible path and goes for the one which is shortest or least troublesome. The problem, I think, would have been that this is a huge operation for the NES to manage, and if it could be dealt with in a simpler way then that's the way to do it. The other path finding algorithm I considered was the Bresenham line algorithm, which calculates the line of sight path from A to B, like in a straight line. This also sounded good but I never got around implementing it because I came up with an idea of my own, and it goes like this. First the enemy puts the players coordinates as his target. Then the enemy is lining up either the horizontal or vertical coordinates to match this target's. Which direction (horizontal/vertical) is lined up first is chosen by random. Then it lines up the other direction until it reaches its target. By the time the enemy reaches its target the player may be long gone but it doesn't matter because every time Basil reaches its target he will store the player's current position as its new target. A little game play footage: Update 02.04.2011 The oil can item is now being randomly placed onto the walkable area of the map after being used by the player. A pseudo random number generator is deciding where to put the oil can and it's seeded by the timer that makes the oil drops in the status bar running out. New are also these boxes  in the status bar which holds various items, there are currently three boxes up there but so far I have only two items figured out, one is the oil can.Update 31.03.2011 The mysterious machine is now actually consuming oil, this is quite a big step again, and when the oil runs out it's really game over, yeah the screen goes dark. The player can now also fill oil into the machine if he/she has the oil can item (this item  ) , by walking onto the machine. Currently it's hard coded so the player has this item from the startup.There are maximum 6 oil drops in the upper status bar  , which will drain out one by one with some seconds interval. I haven't decided on the time yet, I'll have to fine tune all the parameters at a later time. When all the drops are gone it's game over.Update 29.03.2011 The other sprite->background collision detection bug is taken care of. It's now working properly! Another thing I implemented is the movement of the main character is now basically the same as in for example the first Zelda, that is you can't go diagonally, only left, up, right or down at the same time. Update 22.03.2011 I have just fixed one of the two known collision detection bugs, the bug that still exist makes it possible to move trough walls if you are moving in two directions simultaneously (ex. up and right). You can only move trough walls to the right/left of the character, not walls that are above/below the character. It's time to show a video :) The bug which I fixed was making the character move in an undesired way when standing up against a wall and moving parallel to this wall. Update 21.02.2011 I have implemented sprite to background collision detection. The routines still have some undesired effects when making collisions in two directions at the same time. For example when moving up and right at the same time the collision detection does not work correctly. Also I noticed that when writing new background nametable the screen jumps when fading out. This must have something to do with how I wait for VBlank. So I guess it's time to check the code and find the bugs before I implement something else. I also want to clean up the drawing routine and sprite handling code. It's boring to go over the code again but it needs to be done. The lesson is that it's best to do it right the first time. Update 18.02.2011 Meta-tiles (16x16 pixels, 2x2 tiles) are implemented. This means that each individual screen takes up only 240 bytes of ROM. Before using meta-tiles one screen consumed 960 bytes of ROM. So it's like a compression method which unfortunately comes with a few limitations, but no problems :). It also means that I have to do most of the background graphics all over again. This is how the background screens are represented in the assembly program when utilizing the meta-tile system: gamebackground: ; each byte is a meta-tile consisting of 2x2 tiles (that is 16x16 pixels) .db $2,$2,$2,$2,$2,$2,$2,$2,$2,$2,$2,$2,$2,$2,$2,$2 ;row 1 .db $2,$2,$2,$2,$2,$2,$2,$2,$2,$2,$2,$2,$2,$2,$2,$2 ;row 2 .db $1,$1,$1,$1,$1,$1,$1,$1,$1,$1,$1,$1,$1,$1,$1,$1 ;row 3 .db $1,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$1 ;row 4 .db $1,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$1 ;row 5 .db $1,$0,$0,$0,$1,$1,$1,$1,$1,$1,$1,$1,$0,$0,$0,$1 ;row 6 .db $1,$0,$0,$0,$0,$0,$0,$0,$1,$0,$0,$0,$0,$0,$0,$1 ;row 7 .db $1,$0,$0,$0,$0,$0,$0,$0,$1,$0,$0,$0,$0,$0,$0,$1 ;row 8 .db $1,$0,$0,$0,$0,$0,$0,$0,$1,$0,$0,$0,$0,$0,$0,$1 ;row 9 .db $1,$0,$0,$0,$0,$0,$0,$3,$1,$0,$0,$0,$0,$0,$0,$1 ;row 10 .db $1,$0,$0,$0,$1,$1,$1,$1,$1,$0,$0,$0,$0,$0,$0,$1 ;row 11 .db $1,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$1 ;row 12 .db $1,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$1 ;row 13 .db $1,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$0,$1 ;row 14 .db $1,$1,$1,$1,$1,$1,$1,$1,$1,$1,$1,$1,$1,$1,$1,$1 ;row 15 And this is how the background looks like when drawn to the screen (sprites are removed). If we look at the nametable above we can notice that the ones (which are in bold font) represent the green block, the zeros represent solid blue block, the twos represent solid black block and the threes (only one) represent the meta-tile that is supposed to look like a machine (generator). The nametable above takes meta-tiles from the pattern table below.  And below we have the set of background tiles, this is called a pattern table. There is one pattern table for the background and one pattern table for the sprites. The first block of 4 tiles (meta-tile) is empty this can be fetched with the index zero from a nametable. The next block of four tiles is the wall block, which has index 1. Next up is a solid color block, it has index 2, and the next block is the machine with index 3 and so on... , so this is how backgrounds are built up, well there is also the palettes by which you control the color of the tiles.
Update 06.01.2011 I made some changes to the appearance of the game. Added the generator which consumes gasoline which you need to find and refill into the generator, otherwise something bad happens and it's game over. Here's a picture.  Below is also a video clip of the game in action. Here you can see the transitions, the first transition looks a little messed up because of that green line that is the only thing on the screen during the last frame. The second transition is much better. Update 03.01.2011 I have implemented fade-out effect that runs when a state change happens. For example when the player presses the start button on the title screen. The transition is a three stage process with 3 frames in between, so it's like darken screen - wait 3 frames - darken screen - wait 3 frames - darken screen - wait 3 frames - load new screen. Technically it's the most simple method of screen fading I could think of. It's definitely not the the most beautiful screen transition, but I think it's better than no transition effect at all. Update 29.12.2010 I updated the title screen to look somewhat nicer. The title of the game is "Nighttime bastards".  Update 29.12.2010
This is the title screen that appears at startup of the game. It's not very well done for now, just something to show that the game state engine is working properly and changing states. When the start button on the first player controller is pressed, the game state switches to gameplay. It's a PAL game by the way (not that it matters). The main character is just there to test the movements are working (it's not the final design hehe). The main character can be controlled by the first player's controller's D-pad. I'm writing a simple game for the NES game console in assembly language using ASM6 assembler. It's my first game for the NES so I will try to keep it simple. It's a one screen game called "Nighttime Bastards". I'm going to write a little about the ongoing work on this page. If you would like to try it out, there is a download link at the bottom of this page. The story of the game is as follows. Because the evil is weakened by the light, it's your job to feed gasoline to the generator which produces electricity for the lights. When the light goes out the game is over. Oh, and protect yourself against the "evil characters". |
