Jump to content

Search the Community

Showing results for tags 'penult'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Atari Systems
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Gaming General
  • Marketplace
  • Community
  • Game Programming
  • Site
  • Classic Gaming News
  • The Club of Clubs's Discussion
  • I Hate Sauron's Topics
  • 1088 XEL/XLD Owners and Builders's Topics
  • Atari BBS Gurus's Community Chat
  • Atari BBS Gurus's BBS Callers
  • Atari BBS Gurus's BBS SysOps
  • Atari BBS Gurus's Resources
  • Atari Lynx Programmer Club's CC65
  • Atari Lynx Programmer Club's ASM
  • Atari Lynx Programmer Club's Lynx Programming
  • Atari Lynx Programmer Club's Music/Sound
  • Atari Lynx Programmer Club's Graphics
  • The Official AtariAge Shitpost Club's Shitty meme repository
  • The Official AtariAge Shitpost Club's Read this before you enter too deep
  • Arcade Gaming's Discussion
  • Tesla's Vehicles
  • Tesla's Solar
  • Tesla's PowerWall
  • Tesla's General
  • Harmony/Melody's CDFJ
  • Harmony/Melody's DPC+
  • Harmony/Melody's BUS
  • Harmony/Melody's General
  • ZeroPage Homebrew's Discussion
  • Furry Club's Chat/RP
  • PSPMinis.com's General PSP Minis Discussion and Questions
  • PSPMinis.com's Reviews
  • Atari Lynx 30th Birthday's 30th Birthday Programming Competition Games
  • 3D Printing Club's Chat
  • Drivers' Club's Members' Vehicles
  • Drivers' Club's Drives & Events
  • Drivers' Club's Wrenching
  • Drivers' Club's Found in the Wild
  • Drivers' Club's General Discussion
  • Dirtarians's General Discussion
  • Dirtarians's Members' Rigs
  • Dirtarians's Trail Runs & Reports
  • Dirtarians's Wrenching
  • The Green Herb's Discussions
  • Robin Gravel's new blog's My blog
  • Atari Video Club's Harmony Games
  • Atari Video Club's The Atari Gamer
  • Atari Video Club's Video Game Summit
  • Atari Video Club's Discsuuions
  • Star Wars - The Original Trilogy's Star Wars Talk
  • DMGD Club's Incoming!
  • DASM's General
  • AtariVox's Topics
  • Gran Turismo's Gran Turismo
  • Gran Turismo's Misc.
  • Gran Turismo's Announcements
  • The Food Club's Food
  • The Food Club's Drinks
  • The Food Club's Read me first!
  • The (Not So) Official Arcade Archives Club's Rules (READ FIRST)
  • The (Not So) Official Arcade Archives Club's Feedback
  • The (Not So) Official Arcade Archives Club's Rumor Mill
  • The (Not So) Official Arcade Archives Club's Coming Soon
  • The (Not So) Official Arcade Archives Club's General Talk
  • The (Not So) Official Arcade Archives Club's High Score Arena
  • Adelaide South Australia Atari Chat's General Chat & Welcome
  • Adelaide South Australia Atari Chat's Meets
  • Adelaide South Australia Atari Chat's Trades & Swaps
  • KC-ACE Reboot's KC-ACE Reboot Forum
  • The Official Lost Gaming Club's Lost Gaming
  • The Official Lost Gaming Club's Undumped Games
  • The Official Lost Gaming Club's Tip Of My Tounge
  • The Official Lost Gaming Club's Lost Gaming Vault
  • The Official Lost Gaming Club's Club Info
  • GIMP Users's Discussion

Blogs

There are no results to display.

There are no results to display.

Calendars

  • AtariAge Calendar
  • The Club of Clubs's Events
  • Atari BBS Gurus's Calendar
  • ZeroPage Homebrew's Schedule

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website


Facebook


Twitter


Instagram


YouTube


eBay


GitHub


Custom Status


Location


Interests


Currently Playing


Playing Next

Found 7 results

  1. Death in RPG-style videogames is handled many different ways, depending on the game. If there's not a reasonable chance of death in the game, then players may lose interest because the game is not challenging enough. If the penalty for death is too great, then it may be too discouraging to players, and they may give up on the game. Here are a few possible approaches to handling in-game death: Permadeath This is the most hard-core option. If the character dies in the game, then it is game over, and you need to start from scratch with a new character. This style is common mainly for roguelike games such as NetHack, where challenges are randomly-generated every time you play the game. Restore From Save This is a bit like permadeath in that there is no way for the character to be brought back to life in the game, but the ability to restore from the last saved games gives the player another chance. Within the game narrative, it is as if the death never happened. Resurrection With Penalties This is probably the most common approach in RPG-style videogames. When the character dies, they have the option of being brought back to life, but it has a cost: it could be money, experience points, or loss of equipment. Resurrection With No Penalty Some games allow you to be brought back to life as often as you wish with no real penalty, other than perhaps inconvenience. The original Legend of Zelda is a good example of this. Ultima Series Deaths For Ultima fans, here's a page describing how character deaths are handled throughout the series. Character Death in Penult In Penult, the character and the queen both share a connection to the Fey Realm via their fey companions (Penult Manual). By means of this shared connection, she is able to bring the player's spirit back to her upon death, and create a new body for it to inhabit via her magic. Given this rationale, a resurrected character has no equipment or gold when brought back, and only their experience. It has been said by those who have played it that it is too harsh of a penalty, and discouraging to lose everything after spending so much time earning gold for their equipment. I'm brainstorming other ways to handle death and resurrection. I don't want it to be consequence-free, but I also don't want it to beel too discouraging. My workaround in my latest demo is to have the queen give 100 G.P. per character level, which will at least allow them to partially replace their lost equipment upon death. I'm open to other ideas, but they have to fit logically with the rationale above about how the character is brought back to life by the queen.
  2. There are not a lot of Atari 2600 games that make use of a large amount of text. There are various reasons for this, including ROM size, as well as the fact that many implementations of a text display on the Atari use up a good deal of the limited RAM on the system. Penult has a large ROM size (128K), and makes use of a text display that builds the text lines on the fly to save on RAM (props to @RevEng for help with the initial design from which the Penult implementation had evolved). Penult is largely inspired by the early Ultima series, especially Ultima 3. Conversations in those games were a vital part of the feel of immersion in those games. I was pleased to discover as I was creating a new city that I've already exceeded the lines of dialog in Ultima 3, and I still have more cities to add. Additionally, each non-vendor NPC has a unique name, and a unique dialog. Line length is an issue, though, as I only have 24 characters to work with, although many conversations span multiple lines. Conversation in Ultima 3: Conversation in Penult: For vendors, compared to Ultima 3, the interface has been greatly simplified to allow for easy play with a one-button Atari joystick. Rather than a single vendor being able to sell a variety of weapons and armor, I have multiple specialized vendors each offering one item for sale. For example, in the starting city of Arcadia, you can buy a sling, a mace, or leather armor, each sold by a separate vendor: Penult vendor example: I have a script (UNIX/Mac) to allow me to convert lines of text into data I can include in my program. I'm including it here along with an example just for posterity, and on the small chance that it or the idea behind it could be useful to other developers. ./strconv what brings you here? 21 status__what_brings_you_here message__what_brings_you_here .byte __W, __H, __A, __T, _sp, __B, __R, __I, __N, __G, __S, _sp, __Y, __O, __U, _sp, __H, __E, __R, __E, _qu, $FF strconv
  3. I've been writing a few blog entries with semi-technical notes about the innards of my WIP Ultima-style game. In this one, I talk about keeping track of state in dungeons with extremely limited RAM. I've been working on implementing dungeons in Penult, starting with original data from Ultima 3 for testing purposes. Dungeons in Ultima 3 consist of 8 levels each, and each level is a 16x16 square of tiles. Since there are less than 16 unique tiles, two tiles can be stored in 1 byte of ROM, so a full dungeon takes up 1024 bytes of ROM space. Due to extremely limited RAM (256 bytes for a SuperChip cartridge), only the currently visible portion of a level is loaded into RAM. The problem with this approach is that there are treasure chests distributed throughout the dungeon. If the player loots one, it should either vanish, or show an open chest, and not give the option to loot that chest again. I could keep track of which chests have or haven't been looted throughout the dungeon, and override the chest information loaded from ROM with the current state of the chests. With the dungeon having 8 levels, and each level being 16x16, there are 2048 tiles in the dungeon, so 2048 possible places a chest could reside. Even if the chest state (looted or not) is stored as a single bit, this would take 256 bytes of RAM - which is all the available RAM, which obviously not feasible. (dungeon view and treasure chests in Ultima 3 (left) vs Penult (right)) On the plus side, due to the smaller visible range while in a dungeon, much of the RAM used for the visible tiles during the rest of the game is not used here. Specifically, I use 84 bytes for the 12x7 screen, but only 30 bytes for the max 6x5 screen while in a dungeon, so this leaves me with 54 free bytes. How can these be used short of storing the state of every single tile in the dungeon? First, I can at least track the state of the tiles on the current level. Each level has 16x16 = 256 tiles, so if the state of each is stored as one bit, then this will take 32 bytes. How to deal with the remaining levels, though? If I only tracked the current level, then the player could go to a different level, then immediately return to the previous level to loot the same chests again. The solution I came up with involves tracking the state of previously-visited levels in sections. I divide the levels into 16 4x4 sections, and if any chests in that section have been looted, the whole section is marked as looted. When a level is revisited, the chest information is loaded into RAM, and then the section information is used to mark any chests as looted on the level in sections that have been marked as looted. While this method isn't exact, it should be close enough that the difference would not usually be noticed by players. It is coincidence that the chests from the 37-year-old dungeon data that I'm using seems to align neatly with the sections I defined, but I can do that intentionally when creating my own content. The section data for each level takes up 2 bytes using this method, or 16 total bytes for all levels, plus 32 bytes for the chest data for the current level which comes to 48 bytes total, out of the 54 extra available in dungeon mode. Downsides: This approach does have a few downsides. The main one is that using all of the variables that aren't used by the smaller display means that I can't switch back to the regular display while in the dungeon. Cases where I would normally do so would be when displaying the stats screen, or when in combat. This means that I'll need to come up with dungeon view specific versions of each of those screens. In the case of combat at least, I think this will end up being more of a positive than a negative, since it will lend a different feeling to dungeon battles vs outdoor battles. (Current stats screen)
  4. Karl G

    Penult Maps

    I have enjoyed @SpiceWare's blog entries about the making of his games, so I thought I'd try my hand at it for my upcoming game Penult. My first demo was pretty much just a map viewer for the Ultima 3 world map. I chose Ultima 3 because it actually has the smallest world map: only 64x64 tiles. Converting the Ultima 3 map to data I could use in my initial demo wasn't difficult, but the first problem was that it was still too big: 64x64 bytes equals 4096 bytes, or exactly the size of one bank. This doesn't account for the 256 bytes I lose by using SuperChip RAM, nor does it leave any room for code to access the data. Since there were less than 16 unique glyphs in the map data, I was able to convert each tile to a nybble, so that one byte contained the data for two adjacent tiles. This gave me plenty of space to contain the entire Ultima 3 world map. When I switched to my own world map, I made the size a bit bigger: 80x64 tiles. Town maps were another issue. Each of these in Ultima 3 are also 64x64 tiles, and they have many more than 16 unique glyphs, so my compression trick would not work. Furthermore, even if it did fit, having each castle and town take up one bank each would cause me to quickly run out of space. Instead, my castle/town maps are 48x34 tiles in size, and I can fit two of these maps along with the code to access them per bank. For making my own maps, I use the Tiled app. I'll show how the current version of Queen Avaline's castle looks in the Tiled editor. I'm picking that one because it's likely to change greatly before the final version - it has unused areas and hidden areas that I'll alter before the final version. Just to be sure, though, I'll put the screenshot in a spoiler tag: The game uses whatever tile is in the upper-left corner (grass, in this case) as a "filler" tile to fill in the edges of the map as the character comes to the edges of the map: I export the map to CSV format, and I have a custom script that converts this data to data I can include in my source file: The script to convert the world map is more complicated. Unlike the town maps, the world map wraps, so there is some redundant data to make the loading of the map quicker. Additionally, the data is compressed by converting to nybbles as described above. Here is the script I use to convert the CSV export of the world map to the format I need: Still left to do on the map front is figure out if I want smaller "village" maps to save space for remaining towns, and I need to figure out how I want to handle dungeon maps.
  5. Karl G

    Penult Goes to 128K

    While I have aimed to keep my WIP 2600 homebrew Penult within 64K, I've always known there was a possibility that it could go to 128K. Maps and text strings take up a lot of this space, and I'm going to need a good amount more of both to finish the game. What made me make the choice to switch to 128K was sitting down and doing the math comparing what I have planned with what space I have left. I'm looking at dungeons now, and those maps alone will use up much of my remaining space. The good news is that I've successfully switched my code over to a bankswitching scheme that supports 128K (DFSC as described in this topic), so I can continue development without worrying about running out of space. I'm curious now if anyone has published a 2600 homebrew game that was this large yet?
  6. Karl G

    Penult Timing

    I've been writing a few blog entries with semi-technical notes about the innards of my WIP Ultima-style game. In this one, I describe how I handle all of the game's tasks without running out of CPU time. With many Atari games, especially ones that do not make use of a coprocessor like the ARM, limited CPU time for game logic can be a challenge. Since Penult is a turn-based game, timing isn't as critical for many of the game's tasks. I have divided all of the game's tasks into tasks that need to run every frame, and tasks that can run once every 4 frames. The tasks that can run every 4 frames are further divided into tasks that run before the visible screen is displayed (vertical blank), and tasks that run after the visible screen is drawn (overscan). For the most part, after breaking up the tasks like this, running out of CPU time hasn't been much of an issue. A big exception was the map loading and visibility code. Every frame, whatever portion of the map is loaded into RAM is displayed during the visible screen. Every 4 frames, the currently-visible portion of the current map is loaded into RAM (which may or may not have changed since last time). The tricky part is that once these have been loaded in RAM, the visibility code must be run to blank out tiles that would not be visible from the current position. Both of these tasks must be done before the next time the visible screen is displayed: Map before visibility blanking: Map after visibility blanking: The denser forest tiles should obscure tiles behind them, and hide the city from view from that position. Here's a broad overview of game tasks, and when they are performed: Tasks Before Visible Screen (Vertical Blank): All frames: Set P0 and P1 positions, Update wind, Sound / music updates Frame 0: Check turns and hunger, check for encounter, set status / text fields Frame 1: Line of sight code or combat logic or stat screen stats Frame 2: Menuing, button, joystick, movement Frame 3: Currently nothing Tasks After Visible Screen (Overscan): All frames: Currently nothing Frame 0: Stat screen base or combat arena or load town/outdoor map Frame 1: Joystick delay / repeat Frame 2: Process map triggers Frame 3: Load ship and other movable tiles
  7. Karl G

    Ultima 3 Musings

    I've recently started playing the PC version Ultima III: Exodus via DOSBox with an upgrade patch to allow for EGA graphics and midi music to more closely match the colors and music of the original on other platforms. The PC version out of the box uses CGA graphics and has no music. This was my introduction to the series, but I didn't play it on a computer when it came out initially, but rather on the NES many years later. I hadn't heard of the game, and I was blown away. The NES version has a different look and feel compared to the computer versions, but it is otherwise a decently faithful port. I think this is the installment that made the series really take off in a big way. You could form a party of 4 characters, with several race and class choices with different strengths and weaknesses. The choices can really make a difference in the effectiveness and survivability of the party. It is also the only one of the series where there isn't really a central hero. You make 4 characters, assign a marching order, and begin adventuring. If those 4 are all killed, then you can create 4 more, and resume with the world in the state that you left it. You can also freely swap out party members with new ones as needed. Official Ultima cannon says that the Stranger / Avatar is among these heros, but I prefer to think that he/she just decided to sit this one out, and let the land solve its own problems for once. I have a soft spot for the NES ports of Ultima, since that was my introduction to this awesome series. I think I'm actually too big of a fan to attempt my own port to the Atari, but I would like to take a stab at producing something very heavily inspired by Ultima III.
×
×
  • Create New...