Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store

NRV

Members
 View Profile  See their activity

  • Posts

    444

  • Joined

  • Last visited

  • Days Won

    2

 Content Type 

Posts posted by NRV

    "Bad guy" AI for games

    in Atari 5200 / 8-bit Programming

    Posted

    15 hours ago, rdefabri said:

    I was playing Raymaze 2000 and I noticed some interesting AI for the "bad guys".  That had me thinking - how do you build in that AI in a game?

    You could try to look for some kind of source code, or disassemble the original Z80 roms (from the arcade version), or maybe look at the 6502 NES version (not the exact same game, but maybe the enemies have similar behaviors).

    What I did was to look at a couple of youtube longplay videos and also played the original game in Mame, until I have an idea of the algorithms behind those behaviors.

    Sure, is not that simple with the more complex behaviors, but I wanted them to be good enough, not perfect.

    In fact I remember seen some videos where an enemy did something that I could not explain with my final models, but at that point it could even be a bug in the original code :D, so 99% was good enough for me.

    In the end you cannot really do it perfect without looking at the original code.

     

    After you have the basic behaviors in a nice list of steps and conditions you can start thinking about algorithms.
    This is going to be easier if you have experience with those.
    But for ""AI"" so simple as this, probably this list of steps is already your algorithm.
    Then implementing this in your chosen language will depend on how much experience you have with it.
    There is no shortcut for all this, you just start with simple things and move to the complex ones.. baby steps as they say (and time and patience).

     

    As an example, one of the behaviors for the first enemy is that it tries to rotate toward the player's "perpendicular" direction, every time that it gets to an intersection in the maze.

     

    Then if the enemy is moving up, and gets to an intersection or a front collision, the final code look more like this:

     

        .proc BehaviorUpFollowTarget

     

        // if there is a CounterClockwise exit and (playerX < enemyX) rotate CCW
        // if there is a Clockwise exit and (playerX >= enemyX) rotate CW
        // if there is no front collision continue front
        // else turn CW, CCW or back..

     

    And there is equivalent code for when the enemy is moving right, left or down.

     

    • Like 2

    [RELEASE] RASTER Music Tracker, v1.34.00

    in Atari 8-Bit Computers

    Posted

    In the old player you just change the code that writes to AUDCTL. I assume that it would be as easy to do in the new versions.

    Normally there is only one write to the hardware registers at the end of the RMT code.

    To implement APAC with IRQ's and play RMT music at the same time for example.

    I suppose the RMT player's code could have a generic "AND mask" and a generic "OR mask", so a user could clear or set specific AUDCTL bits. Don't know if that is what you need :)

     

    • Like 1

    Moving beyond RMT ?

    in Atari 8-Bit Computers

    Posted

    After all the experiments from Vinscool, Synthpopalooza and other people, I would say that supporting custom note tables (3) and providing fine control over all the Pokey values per frame (7), when needed, are the most important.

     

    You can forget about number 6. It was that sometimes, some note tables or instruments, need to be used in specific channels. But you can give total freedom to the user in the end, there is no need to check everything.

    • Like 1
    • Thanks 1

    Mad-Assembler (MADS)

    in Atari 5200 / 8-bit Programming

    Posted

    1 hour ago, ascrnet said:

    Hi all,

     

    I am passing a program from MAC65 to MADS, but I did not understand what the equivalent of the following lines is : 

    
BASE = $5000

; MAC65
SETVEC = *-BASE
BUFFLEN = *+1
ERRNUM * = *+24

 * = *+49
  .SB +$80," START "

    regards

     

    I would try with something like:

     

    BASE = $5000

    SETVEC = *-BASE

    BUFFLEN = *+1

    ERRNUM

       org *+24

       org *+49

       .sb +128, " START "

     

    (untested!)

     

    • Thanks 1

    Favorite magazine/type-in game

    in Atari 8-Bit Computers

    Posted

    5 hours ago, vitoco said:

    I liked Bopotron (A.N.A.L.O.G. #24, Nov 1984) very much, because in the same magazine it was also published a construction set (another type-in program) to create and add custom levels. I designed some of them...

     

    You made me remember that I typed that one, almost finished it, but lost it to the Atari Basic's lock up bug (could not save it ?).

    Never tried again x)

     

    Probably the ones I played most:

    - Zurk: http://www.atarimania.com/game-atari-400-800-xl-xe-zurk_5952.html?version=5952

    - Kooky's Quest: http://www.atarimania.com/game-atari-400-800-xl-xe-kooky-s-quest_2834.html?version=2834

    - Avalanche: http://www.atarimania.com/game-atari-400-800-xl-xe-avalanche_442.html?version=442

    - Spy Plane: http://www.atarimania.com/game-atari-400-800-xl-xe-spy-plane_4952.html?version=4952

     

    Maybe Avalanche could interest you.. is a QBert clone in machine language, from Analog.

     

    • Like 2

    Arkanoid [WIP]

    in Atari 7800 Programming

    Posted

    23 hours ago, SlidellMan said:

    Just played it on JS7800, and you just may have made the best 8-Bit home port of Arkanoid. Maybe you could port more Taito arcade titles such as Raimais (You may have to include the cutscenes from the Japanese version), Darius, Legend of Kage, Bubble Bobble, Space Dungeon, or Exzisus?

    There is already an A8 version of Raimais, so there is code done if you need it, but probably if there is a popular vote Bubble Bobble would win x)

     

    (and the graphics for the 7800 are already done in this thread: )

     

    • Like 2

    Atari stamp and stencil

    in Atari 8-Bit Computers

    Posted

    On 8/22/2020 at 5:14 PM, ivop said:

    Idea for a multijoy game. Five persons. One person controls Pac-Man. Four people control Blinky, Pinky, Inky and Clyde. After death, Round-robin the players one, two or three full rounds and count the points gathered by each player. Perhaps extra points for being the ghost that catches Pac-Man. For less than five players, Clyde(Inky(Pinky)) could also be computer controlled.

    https://en.wikipedia.org/wiki/Pac-Man_Vs

     

    • Like 1

    HW-Detect

    in Atari 5200 / 8-bit Programming

    Posted

    4 hours ago, MrFish said:

    The fix for this is easy. You simply test for <SELECT> to be pressed, then you test for <SELECT> to be released. That's it.

    As a general programming advice I prefer the other option, detecting the "just pressed" event, so a detection of a "key not pressed", followed by a detection of "key pressed".

    That way you know that no other application can mess with yours.

    Also, detecting "just pressed" feels more responsive than detecting "just released", from the user's perspective.

     

    But I understand that this doesn't protect you from messing with the next application :D

     

    • Thanks 1

    Arkanoid [WIP]

    in Atari 7800 Programming

    Posted

    7 hours ago, mksmith said:

    The ball movement/collision really gets me frustrated at times

    What method do you use?

    When I did my pseudo clone I moved all balls by steps equal or lower than one pixel, many times per frame, checking if they cross over brick limits.

    With this there is no problem with the collisions (even if you hit more than one brick in the same frame), but the problem is that a higher speeds (and with more active balls) the processing cost is also higher.

    So I don't know if this method will work well with the 7800.

    Well.. probably there are ways to optimize this, like doing the fine steps only if we are moving through a zone with bricks on it.. but I never explored this solution.

     

     

    • Like 1

    Canyon Bomber genre games

    in Atari 8-Bit Computers

    Posted

    On 7/24/2020 at 4:49 PM, Philsan said:

    Canyon Bomber is an arcade game made by Atari in 1977:

    1288004831_CanyonBomberArcade.png.295dbc55839fba2e23efc528914a0b49.png

     

     

    Is kind of funny that this can done almost equal (or better) in the A8 (G0, P/M's for the white "underlay" color, narrow playfield).. and the arcade uses a 6502 clocked at 756 KHz.

     

    How much do you like the original? :D

     

    • Like 3
    • Thanks 1

    Knight Guy in Low Res World: Castle Days

    in Atari 7800 Programming

    Posted

    Not trying to influence your opinion, I think both options are valid, but I just wanted to add a vote for some "mild" randomness.

    Probably one of the extreme examples for this is something like Spelunky (or Rogue Legacy for metroidvanias), and for sure that have some epic speed runs :)

    In my case, when I do any type of game I end testing it so much, that I feel forced to add some kind of randomization, so it still feels fun down the way.

    Without changing the order of rooms, I have experimented with changing the starting direction of the enemies, changing slightly the speed of some enemies and obstacles,

    adding a small random delay to the start of some periodic events, all with the intention that the player don't only memorize every pattern, but has to adapt to the small changes.

    Anyway, whatever you do is going to be a great game ?

     

    Saludos vecino.

     

    • Like 3

    Atari Basic maze generator?

    in Atari 8-Bit Computers

    Posted

    1 hour ago, Wilheim said:

    A.N.A.L.O.G. has a maze generator as well, in the game Motorcycle Maze Rider, created by Charles Bachand.

    Ouch.. that fired some neurons that were sleeping for more than 30 years x)

    The vector line maze.. the sound..

    It was in the Analog Compendium.

    MADS: Type Based Macros

    in Atari 5200 / 8-bit Programming

    Posted

    If the macros provided by mads are not enough for your case you can do your own.

    But you need to decide first where you want to put the results (A, X or Y, or some memory addresses).

    Also if you want to support negative numbers and how you handle the cases where there is overflow (adding two bytes could give you a word result, for example).

     

    Anyway the syntax would be something like:

      

    .macro Add

.if [:1 < 256] .and [:2 < 256]
// code to add two bytes..

.elseif [:1 < 256] .and [:2 > 255]
// code to add one byte and a word..

.elseif [:1 > 255] .and [:2 < 256]
// code to add one word and a byte..

.else
// code to add two words..

.endif

.endm

     

     

    Plot and Flickering in Action!

    in Atari 5200 / 8-bit Programming

    Posted

    More than that, if you have more than one software sprite:

    - first "erase" all previous/old sprites in the screen

    - then draw all new sprites

    ..repeat

     

    Erasing means restoring the background and it can be done in different ways, for example:

    - if you background is empty, you just put 0's in the old sprite position.

    - or you could have a copy of the background in memory and just copy the area touched by the sprite from there.

    - or use some other logic to restore the background, like when using background "tiles"..

     

    Drawing can also be done in different ways, some of them faster but prone to more visual artifacts:

    - just storing the sprite data on the screen without masking or caring for the sprite "borders" against the background.

    - doing an OR or XOR/EOR of the sprite bytes against the background.

    - doing the "proper" method of having a sprite mask (different than the sprite data) to AND against the background (basically cutting a hole with the shape of the sprite in the background),

    and then ORing the sprite data against the background.

     

    Then there is the problem with rotating the sprite bits inside a byte, because the graphic modes use 8, 4 or 2 pixels per byte.

    This can be done in real time (slow) or having the rotations pre-calculated in memory (faster, but using a lot more memory).

     

    All this is for graphic modes. Char based software sprites are a little more complex.

    • Like 2
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...