Search the Community
Showing results for tags 'Ursine Core/RPG'.
Found 35 results
-
Due to scheduling difficulties, the CiE game is being indefinitely delayed. However, a RPG will be produced, and I'm taking efforts to prevent it from slipping too far from the original CiE release schedule. The code will be mostly the same, but the game data itself will be different. CiE is still planned for a later release, using the same game engine, possibly with some incremental improvements. The new game data is being rushed into production but is based on an existing RPG game design from my personal library, and is unrelated to CiE... I may be bringing on an assistant designer to flesh out scripts and conversations in time. Thanks to all who've been emotionally(?) supporting this project; an updated schedule should be forthcoming soon.
-
Haven't had time to really fix this up. There's an infinite loop inside the sprite handler, apparently incurred as a side effect of moving that subroutine into its own memory bank. The revised layout goes something like this: Banks 0 to 5 are map screens (game play screens); bank 6 contains sprite judgement/drawing-list creation, the interleaved (every third scanline) map venetian blinds code, and sprite graphics; bank 7 contains the Ursa interpreter, scripts, Ursa-injected bitmaps, text-drawing, and the status screen. I fully expect to shift that around a bit, such that bank 6 ends up being bank 7 most likely, and banks 0 .. n are map screens while n+1 .. 6 are Ursa banks. The Ursa interpreter, thank God, is flawless, but it's only running with the barest essential functionality, which (as it turns out) is sufficient for theoretically doing the main menu, simple NPC interactions, and NPC (monster) control sequences of the usual sorts, e.g. "walk toward the player without walking through walls." I'm working on a slightly more intelligent NPC script to implement a "right-hand rule" but really want to see the sprites actually functioning before messing with that any further. Besides which, the ursac rewrite was put on hold to get sprites done. The new parser is a bit more LALR and a bit more flexible in its string injestion, which is the more important part. String display is still basic 48px 12-column display; I toyed with 24-column and such and decided to KISS; there wasn't any real need for any of the game displays. Note that letters M, N, Q, and some punctuation are still double-column-width characters because I wanted legibility ... On the personal side, while I'm still ardently hoping to get this project released in a fully playable form in less than a month, the toll of having been beat up pretty good while breaking up an attempted murder two weeks ago, and the discovery yesterday that a friend of mine is on hospice care and not expected to be around many days more, along with all the usual madness of trying to juggle 3 jobs and an hobby like this, are making it sadly likely that a playable demo level might be all that's ready in time for the 30th anniversary :-( Nonetheless, I'm still rather proud of the architecture of the engine and hope that by year's end the Skyline game, at least, will be fully finished and polished. Regardless, I'm aiming to have "as much as possible" working perfectly in time for the 21st, and the release party will go on in whatever form the game ends up.
-
OK ... she fits. With no space to spare in the ROM, as it should be. Now, if she would also actually run after my latest hack-and-slash memory-bank re-org, I'd have something to show you, but I haven't :'( ... today (Thursday) I'll debug the bitch's sprite code Once And For All.
-
Began a major rewrite of ursac -- the Ursa script compiler -- some time ago. It's a lot cleaner code than the first go. It's also more practical for the type of game Little Dipper has become. It'll need reworking for Big Dipper, if that project ever flies. Among other things: Global default includes file rather than hardcoded enumerations (res/global.ursa) -- mostly just needed for defining global flags set File inclusion (include file. => res/file.ursa) Special binary modules supported: currently just for password-entry, everything else (so far) is stock for Skyline -- use module. do module. -- for example: use numeric_password_entry. do numeric_password_entry. -- The "use" declaration will be monitored by mkmk (Makefile generator), the "do" verb is an actual runtime command to call the exported method (ursa_do_$x) Syntax is more COBOLish than BCPLish now. Some example statements ... # these two are equivalent say: HELLO, WORLD. . # as: say "HELLO, WORLD.". # Menus... ask "WOULD YOU LIKE TO PLAY A GAME?"; for "YES", let_us_play; for "NO", you_are_boring. # Maths set my x to 8. set my reflection to true. set my x to player_x. set r0 to r0 + 4. # Assembly-type maths load r0. add 4. rotate left. rotate right. subtract 3. store r0. # Note that carry is cleared and ignored. # Flags. if my reflection is true, label_to_jump_to. if bit 3 of r0 is false, label_to_jump_to. set bit 2 of r0 to true. # Comparisons compare my x to player_x; when lesser, label_to_jump_to; when greater, some_other_label. compare r0 to 8; when equal, label_target. # bpl, bmi, bne, beq analogues. # zero test if r0 is zero, label_to_jump_to. # Object classes dispatch table class zombie: when hit, zombie_hit. when bump, zombie_bump. when lighted, zombie_lighted. when become, become_zombie. class done. # Invoking an object method zombie_hit: if friend is zero, zombie_hit_player. # ignore non-player sprite collisions done. zombie_hit_player: set player_hp to player_hp - 2. become zombie_attacking. done. class zombie_attacking: when become, become_zombie_attacking. when alarm, zombie_done_attacking. class done. become_zombie_attacking: set my reflection to false. set my graphic to zombie_attacking. set my timer to 1. done. zombie_done_attacking: become zombie. done. show picture skyline.png with caption: BY BRUCE-ROBERT POCOCK AND CHRISTOPHER BURLINGHAM . The ursac rewrite is back burner, but progressing, so hopefully some scripting capabilities of a minimal sort will make it into next week's "playable" pre-alpha.
-
got a note from a potential artist, confirming that he's available on this kind of schedule for this kind of brutal slave labour. updated project status in margin here. basically chugging along despite setbacks. new binary hopefully in 2 weeks.
-
Got my HMOVE's almost all striking at the right timings, but not my PF2's, and somewhere in there I really walloped the HMP0 when I shouldn't have. But, notice where the HMOVE bars are(n't). So, 20 minutes' work in Stella debugger knocked out most of the problem... and the remaining stuff should be as easy (...?!) to clear up. I hope.
-
Last night's efforts. Ignoring the rest of the screen, which I've blocked out for the moment, notice that these trees are drawn "perfectly." Every PF2 hit is exactly on cycle, and the HMOVEs also. (There's an HMOVE on every scanline, but always at cycle 73.) The rest of the screen is fouled up because my "bad line" (triplet 7 line 2 on each row, i.e. scanline 24 of each 24-scanline row) is still not cleaned-up. Now that I have the timing "perfect," though, I can try to re-arrange some of the tasks from 7,2 into the SLEEPs in other lines I actually have an 8-cycle sleep that I completely lack understanding as to why it's needed... but hey, if it works, it works. It has to do something with the interleaving of 24-line rows, 8-line x 3 playfield graphics, and 12-line x 2 player graphics, and my total discomfort in working with figures. To get the timing right I'm afraid I used the "tube of toothpaste" method. "squeezed" in extra SLEEPs on line (0,0), then (0,1), then (0,2), working my way up to about (2,0) before the other lines snapped into place (excepting (7,2) of course). Ironing out the joystick code tonight and possibly augmenting the sound code slightly. A musician friend of mine (thanks Natalie!) saw some animatics I'd sketched out and noticed my use of musical repeat notations - ||: | - and the discussion reminded me that I could maybe support such repeats in the sound code to compress the music better. The combat kernel is mostly intact on my iMac, I've got to merge it back into the Subversion fold though. The kernel (notably) lacks some major functions, notably: there are no animated attacks yet (horrors!)... the attacks have no actual effects (HP/MP aren't changed)... and monsters don't animate individually. (All monsters on screen animate in lock-step. You know... NUSIZ clones.) Oh... and equipping items/magic doesn't work through the UI. I've been tweaking ZP locations in Stella, which is probably not the best UI ever. Ursa's basically done, tile drawing's almost done, combat kernel gets some TLC next and then I get to point at Mayday and take a nap for a while. But instead I'll probably hack up some cool magic and attack animations and work on stuff like the stats display (easy, but annoying), the save/load game code for Avox/memcard (where did I stash that MemCard during the move!?), and the attraction mode and "you win" animation sequences. I've toyed with the idea of giving Ursa some controls to do "Macromedia Director" type animation controls, like, "move P0 in a line to location (x,y) doing alternations every (n) deciseconds between bitmaps (a) and (b)" to do the attraction and winner kernels and possibly (gasp!) a cut scene? ... but that kind of candy should probably wait. It depends on whether I think I can pull it off more easily using Ursa or 6507 assembly... and which takes less ROM space. BTW, don't think I "blogged" this before, but all animations and fx are based on a decisecond timer. Unfortunately I did have to go for NTSC/PAL conditional compilation. The NTSC version naturally has 6 frames per dsec, the PAL,SECAM version only 5, and the music generator "mksound" -- which is abyssmal, right now, I really should work on it, too! -- writes conditional-compilation AU* register triplets out. Also, all colours are registered with conditional-compilation NTSC v. PAL colours, and the SECAM colours are used as the B&W values. This does mean that if you trip the B&W switch on the console the screen will look kinda trippy on colour TV, but, it'll be playable on a B&W set. Aside: I was playing another author's homebrew on my B&W test set and was brutally murdered by invisible enemies on about the 4th level, not realizing that their colour was nearly the playfield colour Of course, I may be the only one who'll ever see "CiE" on a B&W set... Hey! it's "colourblind mode!" There ya go. I knew it was practical. Oh, nearly forgot: here's the goodies!
-
second time today, the attachments failed me. executable: screenshot: starpath.zip
-
It's been a long time a-coming but something "clicked" in my head Friday and I managed to get the above entry (lovely grid pattern that's stable) drawing. The idiots at the cable company have somehow managed to fry my connection at the moment, so I may have to burn a CD-R and sneakernet it to a Panera to get anything uploaded. The biggest fallout is that I've gone from a "2lk" format for the tile artwork (as shown in the yellow photo) to a "3lk" format for the playfield, with a "2lk" format on the sprite overlays (not shown). Moving around a few details, that makes fora 24-scanline-tall row. I might be able to afford one extra branch-and-test after the 12th row to reduce the ROM footprint. I'm also contemplating the evil but fun option of splitting the kernel between ROM banks: i.e. having the ROM data for different parts of the map in different banks with a bank switch occuring within the kernel itself. It'd save a lot of ROM, and is just nutty enough that it might work. The ill-defined concept would go something like this: the tile maps (which tile art goes on which spaces on the display) and the tile bitmaps for the upper 12 scanlines (4 logical lines) are stored in bank (n), with the kernel code to draw the upper 12 scanlines. After the 12th scanline, though, the kernel does a bankswitch and continues the 13th line (line 12) in bank (n+1) where we have the bitmap data for the lower halves (4 logical lines) of each tile. The breakthrough that made this possible? Pre-OR'ing tiles. The compiler now handles arranging every used combination of tiles in advance. More work for the PC compiling the game... less work in realtime. And, not a bad overall impact on slated ROM sizes. Travel test kernels for your viewing pleasure coming shortly. PS: the screenshow appears below not above on this blog format. Or just click on Saturday's date on the calendar. It's totally unimpressive.
-
Details a-comin' ... but ... at long last ... It's late and it's Cinco de Mayo. More to follow.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord