Jump to content
IGNORED

New XB Game: Wizard's Doom (In Progress)


adamantyr

Recommended Posts

I like the blue. I think any other wall color would actually be a bit less pleasant on the eyes. It stands out nicely and it allows lots of nice color for the creatures. Creatures wouldn't stand out as nicely with the red walls--and other bright colors would actually be a bit too bright. . .

Link to comment
Share on other sites

I like the blue. I think any other wall color would actually be a bit less pleasant on the eyes. It stands out nicely and it allows lots of nice color for the creatures. Creatures wouldn't stand out as nicely with the red walls--and other bright colors would actually be a bit too bright. . .

 

Yeah, I agree! I can kind of understand why Wizard's Lair used magenta for the primary wall color, it's the only color you aren't really using elsewhere. I had similar issues when I was doing up graphics for the CRPG, you run out of options with only 15 colors to choose from pretty fast.

Link to comment
Share on other sites

Okay, so here is a ZIP file that contains two versions of the MAZE program, both use an assembly language routine to greatly speed up the drawing.

 

MAZEASM uses an in-memory buffer, and constructs the entire view before it puts it on the screen.

 

MAZEASM2 draws directly to the screen with each section of wall, in a similar fashion to the original XB implementation, just very quickly.

 

Note how the buffer actually makes things feel slower... if I pushed the actual calculations of the viewable sections into assembly I could speed it up, but at that point I'm doing TOO much in assembly. The goal is to assist XB, not replace it. :)

 

ZIP: MAZEASM.zip

Link to comment
Share on other sites

Currently working on graphics, nearly finished! It's tough work to do really GOOD looking graphics, plus I still need to actually display them in game and make sure they look adequate.

 

I also am plotting out the manual... with some research, I was able to determine the fonts used on the original manuals; Helvetica for the main type, and Parsons for the Title. The latter was particularly difficult to hunt down... and I had to get Helvetica for my Windows PC because apparently, Microsoft signed a deal with Monotype way back in 1991 which excluded Helvetica from their baseline set. In case you're wondering, I do want to print up some actual manuals for fun. :)

 

My only lament is I have to just take a digital copy of the Wizard cover image and re-use it, I would LOVE to find an original of it. But since nobody even knows WHO worked at Rainbow Software, that's not likely to happen. There's a signature in the lower left but it's illegible.

Edited by adamantyr
  • Like 1
Link to comment
Share on other sites

After finishing graphics, I've been working on game mechanics...

 

A big challenge with any complex system is to make sure you make a game that's not just winnable but overall challenging at every stage. Generally in RPG's you want a pattern like this:

  1. Start off weak and vulnerable, low resources
  2. At the end of a level you should feel like you have "handled" every monster and are much higher in resources. Plus strong enough to kick the butt of any lower level monster
  3. The next level should introduce new challenges and opponents that put you almost but NOT quite back to point #1
  4. Repeat until the end, at which point the final challenge should be tough, or moderately tough if you've spent a lot of extra time gathering as much resources as possible

The other aspect is pacing. I actually lucked out that the number of monsters, levels, chambers per level, and items worked out to make the experience rich enough for each of the classes. It would suck, for example, if you either got the strongest weapon by level 3, or only a single new weapon type on each level.

 

My biggest challenge was coming up with a formula for experience. I didn't want experience to be an empty statistic only used for calculating ratings. I wanted it to basically figure out a small "experience factor" that is added to various rolls like attacking, detecting and disarming traps, etc. so that you do gradually get MORE powerful as you defeat monsters and gather treasure. I didn't want to use a "level/XP" table approach like classic tabletop RPG's do either, I wanted it to use FP math.

 

My original formula I was going to use the logarithm function to crunch down the XP total into a smaller value, but I found two problems:

  1. TI BASIC, for some reason, uses some weird base of 2.7# for the LOG function instead of 10? You can convert to LOG 10, but that's just odd...
  2. The pattern of values was too top-heavy in the lower amounts. You would quickly gain EF in lower point values and then it slows WAY down so you're basically fighting for minuscule gains by the last level

I finally hit on a formula that works, using an Excel spreadsheet to plot out values up to a theoretical maximum experience threshold in the game. I basically take the square root of the current XP as a divider and multiply it by another favorable number to get the range I want. Play-testing may force me to change the number a bit but it's good for a start...

 

I should add that the game is mostly deterministic. Because each class (Warrior, Magic-User, Adventurer) has widely differing requirements for items, each one has a separate item list for each dungeon level that it uses to populate. Monsters are also distributed in this way. The only random factor is their locations in the dungeon, and the dungeon layout itself.

 

Before you think that this makes the game too predictable, keep in mind that the earlier games did this too. In Wizard's Lair, if you were very unlucky, you'd find that all the best weapon upgrades were guarded by Dwarf monsters, the strongest monster on the 1st level. It took MOST of your Constitution to kill one with just a stick. Situations like this can still happen, and that's good, because it makes every game different and interesting.

 

I considered a single item list and tracking usage ability by class (a magic-user obviously can't use a battle axe!) but I thought the game is hard enough without you having to deal with a bunch of items you CAN'T use. It may not be realistic but gameplay trumps realism every time. Plus playing with each class WILL be a different experience regardless. Magic-users have to rely on spells to survive, warriors just tank their way through problems, and adventurers straddle the line between the two.

Edited by adamantyr
  • Like 1
Link to comment
Share on other sites

My original formula I was going to use the logarithm function to crunch down the XP total into a smaller value, but I found two problems:

  1. TI BASIC, for some reason, uses some weird base of 2.7# for the LOG function instead of 10? You can convert to LOG 10, but that's just odd...
  2. The pattern of values was too top-heavy in the lower amounts. You would quickly gain EF in lower point values and then it slows WAY down so you're basically fighting for minuscule gains by the last level

 

On the Logarithms, that 2.7 number looks like they were using the Natual Logarithm, which used e as one of the numbers in the calculation, and e is approximately 2.71828. . .

 

Indeed—And that is documented. LOG(N) = loge(n) or natural logarithm (where e = 2.718...) and EXP(n) returns a value of en. If you want log10(n), simply divide loge(n) by loge(10), i.e., LOG(N)/LOG(10)

 

...lee

Link to comment
Share on other sites

I tried playing some Wizard's Lair tonight and boy is it rough... In particular, the game is SO slow.

 

Maze generation took tens of seconds on maximum speed in Classic99! Without acceleration doesn't bear thinking... I rolled my own maze algorithm generator, I didn't realize I did so GOOD of a job... even the maximum size maze (10x10, 90 chambers) takes less time than Wizard's Lair to make the first level.

 

Actual game play is severely hampered by the interface being very unresponsive. Just a glance at the code tells me it's spending way too much time crunching other things (the passing time and whether monsters will move down into your chamber) and not scanning the keyboard. I suspect that's why they eliminated the time factor in Wizard's Revenge. It reminds me to make the scanning loops VERY tight indeed... ideally you should only do checks for monster movement, status counter reductions, etc. on intervals, like every 20-30 loops of the keyboard scan. You can get away with checks constantly in assembly language but not in XB. (In fact in assembly you have to slow it down for human response time!)

Link to comment
Share on other sites

I realized something tonight... I was replicating the original game's keyboard methodology of entering keystrokes and then pressing enter for most of them. Then I thought "...Why?" Just single key commands will do everything, and it's a lot tighter and easier for gameplay!

 

In fact, the original games didn't even need this feature. I think the only reason was they wanted to use multiple letters for some commands. Wizard's Revenge lets you turn AND move by using an extra letter but this is primarily an advantage because the drawing engine is so slow you want that to speed up gameplay.

 

I played a bit more of Wizard's Lair and it's not AS bad as I initially feared... I'm puzzled at how long it takes to create weapon/shield items. It takes notably longer for them to pop up than treasure chests or even magic potions.

 

Edit: Figured it out... It's a result of storing all the data for items in DATA statements and reading them sequentially, checking the names to find the one you want. In Extended BASIC with memory expansion you're much better off just storing data in arrays (even offloading them to disk files) than using this approach, because then you can access them with an index value.

Edited by adamantyr
Link to comment
Share on other sites

Wow... I had forgotten some of the neat features in Wizard's Revenge. While designing traps for my game, I went and looked at the code for both games. Wizard's Lair has the typical standard traps, one that does damage, one that drains strength, another drains luck, etc.

 

Wizard's Revenge, though, has some new ones:

 

One is a teleport, which just randomly moves you elsewhere.

 

The second is "leeches" which fill up your inventory and make you unable to pick up additional items. You have to individually drop them to clear out your inventory.

 

The third is the neatest, a wall trap! It literally fills the screen with bricks and you have to attack them to escape. You lose strength as you bust through the wall.

  • Like 1
Link to comment
Share on other sites

So I've written up all the necessary code, now it's debugging, testing, and working through issues!

 

My assembly routines are mostly complete; there's just one thing I may add after I complete the game. So I've added them to a LOAD program using SYSTEX to embed the assembly code directly rather than load off-disk, which takes forever... Thank you Barry Boone for such an awesome tool!

 

The nice thing with working with assembly routines is that they STAY in memory, even if you have to break out and fix something and re-run the program. They only disappear if you type NEW or CALL INIT. That's very handy for quick turnaround.

 

Here is the title screen...

 

post-17978-0-55783800-1467322087_thumb.png

  • Like 6
Link to comment
Share on other sites

Debugging and testing and working away...

 

Currently I'm using the Warrior for my testing... so far I've adjusted damage for monsters down a bit. Early in the game, without armor or shields, you're going to take a LOT of damage. If you find you have to use every healing option just to stay on top, it's probably too hard. :)

 

I may go back and re-work the maze generation as well. It's tough to make one that moves relatively quickly and doesn't get bogged down trying to find new places to go.

 

The tough part is balancing the game for both extremes, the warrior (who has lots of health and potential for physical damage) and the magic-user (who is fragile in comparison). I may end up having to make healing and protection options available much earlier than I'd planned, or the MU is going to get killed A LOT.

 

I'm also wondering about the game's length... the original two games you could probably complete in an hour or so, this is looking like it may take longer. If that's the case, should a game saving option be added? Hmm...

Link to comment
Share on other sites

I have a lovely save/load routine written in XB. Took me a while to write, but it works beautifully. Could be easily adapted to your variables. :)

 

Of course, I'm sure you could whip one up fairly quickly that would be just as good or better.

 

Glad this is moving along!! If you need testers, I am your man!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...