The Legend of Beryl Reichardt

[sometimes99er]

Just gave it a try. Pretty slick for Extended Basic

Guess if you want to get more out of this you'd have to implement some assembly language routine.

Then again, I'm not that much a fan of hybrid extended basic/assembly programs.

 

But for this type of game (with complex logic) writing everything in assembler seems pretty hard/time consuming/cumbersome.

Wonder if C99 would be the way to go in this case.

Yep. Agree. I was kinda expecting XB to maybe choke on a string array of this size, but it performs okay.

 

I’ll do some Zelda type game at some point. Pure assembler for sure (very data driven though).

 

Owen, if you don’t get the "slot" idea, I can cook up an example.

 

[Opry99er]

This is fascinating. There's a few Questions I have, but it'll have to wait til after the massive Easter activities

we have planned today. My sisters came into town with their families and we are doing a big Easter egg hunt with the little kids. This is the first time we have done up a big Easter since I was a kid, because my siblings and I have a mess of kids of our own. It's funny--- an entirely new generation of kids--- all going to experience what I experienced when I was a kid-- except now I am my father and he is my grandfather. This is off topic, but my heart is warmed today, and I wanted to share my happy Easter wishes with all of you. And Beryl Reichardt too... Wonder if he is going to enjoy Easter this year.

Edited April 4, 2010 by Opry99er

[Opry99er]

***This just in--- Beryl is NOT having a good Easter... He spent all morning killing dark hounds and sand sentinels. No turkey, ham, pie, nothing... Just death and tribulation.

[Opry99er]

Okay. Home, rested, ready to rock. First, I like seeing this. It gives me an idea about how this would look in XB and it tells me I need to go another direction. I can't use this particular method, as it would drive me insane as a player to have to go through that entire screen re-draw at that speed everytime I moved. So, a couple things... First, an assembler routine to re-draw the screen would make this go much faster, obviously... So the question would be, should I completely scrap my idea of doing this in XB, or should I scrap my idea to have it as a scroller? I'll be thinking on this pretty heavily tonight and tomorrow. SPECTRA has made me confident that I could at least BEGIN the process of doing this up in assembly. However, if I stick with XB and make it a section by section map exploration at a larger size (larger than 15x15) I will be able to (potentially) finsh this game within a relatively decent amount of time. I don't know... Other than these two options, I would need to come up with a routine to do all my screen drawing in assembly while keeping my variables and info accessible from diskette through XB.

 

It's either

 

*ALL XB (sectional exploration)

-allows me to do it all myself, relatively quickly but no scrolling and limited memory for map size, music, etc.

*ALL ASSEMBLY (scrolling)

-I would need much help, learn an entirely new language, but I would be able to have all the memory I need with music and graphics

*Hybrid XB/ASSEMBLY (scrolling)

-I would need help developing the assembly routines, all of them. My memory would be limited, but I could do most of it myself.

 

These are tough questions... Alot to think about. My decision will determine the speed of development, quality of gameplay, complexity of design, and the scope of the game as a whole. There must be trade-offs. I just need to be decisive. (yea right) =)

[Opry99er]

I'm thinking Zelda-style sectional exploration. It makes the most sense... I can knock it out with a bit of graphical assembly support, and I could do it the way I want to. I don't need scrolling... Really don't... I can be totally happy doing it sectionally. Scrolling is unnecessary. (((am I doing a good job convincing myself?))) =) hehe... I'm trying so desperately to convince myself.... Getting close here. =)

 

 

[sometimes99er]

Owen, you do pull off stuff, but for your first full assembler project I think you’d have to go for something much simpler. As Retroclouds said, this type of game potentially has complex or at least lots of logic that easily gets out of hand. Either you have to be good at planning, structure or abstraction. I’d said, go for an all XB ! When it’s all done, then good documentation of logic etc. could make the basis for an all assembler totally enhanced cartridge version ...

 

Maybe you could divide your game into worlds. Loading a world as the player progress. A world could consist of maybe 5 screens all held in string arrays ... SCRS$(5,20) for 5 screens each with 20 lines and 28 columns (the limit using DISPLAY AT). So you’d have to solve the puzzles or whatever in world 1 before going to world 2 etc. (well, it’s just to make the program logic a bit more easy).

 

[Opry99er]

That's what I had in mind... A big map for the Forest World, a big map for the desert world, a big map for the cave world, a big map for the dungeon world, etc.... I was just working on a single one first--- trying to figure out what exactly I needed to do before I started going nuts. The scope and magnitude of this game is probably bigger than most of you realize yet. I'm talking a full "game" for each world level--- 4-5 "worlds" and all the stuff that goes along with it. I think you're right, sometimes--- I need to do this in XB. However--- to jeep up the speed of the screen draws, I will be employing the help of a good friend to convert all my pre-designed screens to assembly--- CALL LINK to them, and BOOM, blazing fast screen draws. Once I get the hang of doing an entire screen draw in assembly, I intend on writing a subroutine to take an XB screen draw and make it assembly. VDP multiple byte writes, single, whatever. As I said, I don't know how I'm going to accomplish it, but now that I have the methodology figured, I'm gonna be on-point. Thanks for your thoughts guys--- I will certainly be calling on you for guidance as I move forward. I am glad to have such a great community to come to for help.

[Opry99er]

To be more precise, I will talk about the flow of the game--- this is what "Beryl" will be--- it is a linear RPG that must be played in order by worlds. It will have a definite start and ending, and the order of the game is as follows---

 

1-a town setting

2-Forest world

3-Desert world

4-Mountain world

5-Cave world

6-Dungeon world

 

each world will have it's own program, it's own data and data files, graphics, map, etc. Think about it as 6 seperate "games" in one--- the continual factor will be the stats and items, etc... At the end of a "World," the player data and stats and all the values that need to be upkept will be saved to a datafile and loaded up into the next "world." This way, I will be able to maintain the scope I want without needing 300k of RAM!!! It will load to and from diskette for each beginning and end of a world. The storyline will be very prominent, as I plan for several graphic/text intermediary screens between worlds describing the quest progress and what is to be expected next. Each "intermediate section" (meaning the stuff that happens between worlds) will utilize speech to add some fun. Think of the intermediates as seperate little programs that don't carry with them any data/stats from the gameplay... After the "Forest" world, let's say, the code will "RUN" this intermediate program with speech and fancy full screen graphics--- and then the intermediate program will load the next "world" when it is complete--- the world will then load all the stats/data from the save file and BOOM.... You're right back in it. It's alot to do--- but I KNOW it will be worth the great effort it will require.

 

The battle screen will be very similar to the ones I posted earlier in this thread--- full screen, no character movement...

Hope that clears this up a bit.

Edited April 5, 2010 by Opry99er

[Opry99er]

http://www.youtube.com/watch?v=79tJBPjkbFU&feature=youtube_gdata

 

 

A little vid of the updates. As I stated before though, I will probably have to go with a larger exploration screen with no scrolling... Take a look anyway.

[+retroclouds]

Owen, I like what I see there !

Not having scroll isn't that bad if you have that kind of screens in your game.

 

Very nice

[Opry99er]

Thanks for the response retroclouds. Since the exploration screen will be much wider than this, I will have to exclude the stat bar on the screen. It'll be accessible via keypress (probably the AID function key). This will take you to a menu screen. I am planning to have the menu screen include the following options:

 

1) Inventory

1a) Use item

1b) Swap Item

1c) Drop Item

2) Map

3) Player Stats

4) Summary

5) Save Game

6) Load Game

 

these will be the options (for the most part) for the in game menu. There will be keystroke shortcuts during exploration as well for some of these options.

 

I) Inventory

M) Map

 

you get the idea. Anyway, I need a wider exploration screen since scrolling will not be taking place, so I'll have to have all this stuff in a menu or "hidden". I'll try to develop a newer update today with a menu screen and make a video for that. I appreciate you taking the time to take a gander at the video.

Edited April 9, 2010 by Opry99er

[Opry99er]

I've been able to modify a few things and I'll be posting a new video later tonight or tomorrow.

[The Codex]

Slick stuff Owen! I will definitely get Magellan finished for you. Even if no one else uses it, it can be the official Beryl editor.

 

In fact, I have no problem customising it for Beryl once you've got the machinery of that game settled. Hopefully that will help your development as well.

[Opry99er]

Wow thanks Codex!! . I absolutely love how Magellan looks and the concept is absolutely brilliant. Beryl will fly once Magellan is ready. . Thanks alot buddy. Good to have ya back, hope you had a good break!

[The Codex]

This definition is originally taken from MAME(/MESS)

 

   protected static final Color[] colorPalette = {
           new Color(0x000000), /*  0 transparent/black */
           new Color(0x000000), /*  1 black */
           new Color(0x21c842), /*  2 green */
           new Color(0x5edc78), /*  3 light green */
           new Color(0x5455ed), /*  4 dark blue */
           new Color(0x7d76fc), /*  5 blue */
           new Color(0xd4524d), /*  6 dark red */
           new Color(0x42ebf5), /*  7 cyan */
           new Color(0xfc5554), /*  8 red */
           new Color(0xff7978), /*  9 light red */
           new Color(0xd4c154), /* 10 dark yellow */
           new Color(0xe6ce80), /* 11 yellow */
           new Color(0x21b03b), /* 12 dark green */
           new Color(0xc95bba), /* 13 magenta */
           new Color(0xcccccc), /* 14 gray */
           new Color(0xffffff), /* 15 white */
   };

 

Thanks, I see the discrepancy now. When I moved the color table into my code, I only altered the red value for the two reds:

 

public static final Color TI_COLOR_RED_LIT     = new Color(255, 121, 120);//FF7978
public static final Color TI_COLOR_RED_MED     = new Color(252, 121, 120);//FC7978

 

The medium red should have lower green and blue components, as per the color table you posted. I'll make the change. Cheers!

[Opry99er]

So, once this contest ends and I get a chance to judge these badass games, I'll be turning my attention back to Beryl Reichardt... But last night, I was able to do something very cool I wanted to share with you guys...

 

I was able to sign in to The Hidden Reef, the last remaining dedicated TI BBS via my iphone!!! I was pretty excited about it... This BBS is actually still run on a real TI that runs 24/7, thanks to the efforts of Richard Bell. =)

 

 

How to:

 

Download "Mocha telnet Lite" (free from the app store)

Create a new connection

Enter "thekeep.net" into the IP field

Connect

Sign into thekeep.net

Dialout (d1) to the Reef

Sign into the Reef

Have fun!!

 

 

=)

[The Codex]

Ha, that's great! A real confluence of the old and the new, that.

[Opry99er]

Yea man... It's so cool... I get to sign in to the damn Hidden Reef anytime and at any location I please. pretty rad.

[The Codex]

Some good news with Magellan, I finally fixed the flicker (the lightweight component repaint model is such a pain at times). The bad news is that the fix might require Java 1.6 be installed. Will know for sure when I post it and it doesn't work for half the people here.

[Opry99er]

Very exciting news!!!! I'll take one in each color! I'll upgrade my Java if

I have to, I don't care!!! Can't wait to use it!!! Post that mother!

[The Codex]

I shall mate, once I get one more bit of it fixed. The flicker fix interferes with the mouse highlighting, but it should be simple enough to resolve that and then it's good for another test run.

[Opry99er]

Can't wait! My fingers are itching to get some maps designed!!!!

[unhuman]

1.6 is a bad thing? Sure, it's not as great an upgrade from 1.4 -> 1.5, but... it's good. And I'm really looking forward to some of the updates in 1.7.

 

Some good news with Magellan, I finally fixed the flicker (the lightweight component repaint model is such a pain at times). The bad news is that the fix might require Java 1.6 be installed. Will know for sure when I post it and it doesn't work for half the people here.

[Opry99er]

So, we need to celebrate the release of the new Magellan. How bout we all sit around, "fire-up" TIChronic, and design game maps. . Not to speak to my recreational activities, but we really SHOULD do a press release for it--- flood the web and the user groups with "Magellan TI-99 Map Editor" info.... You'd be surprised how fast that stuff ends up on Google!

Edited April 12, 2010 by Opry99er

[The Codex]

1.6 is a bad thing? Sure, it's not as great an upgrade from 1.4 -> 1.5, but... it's good. And I'm really looking forward to some of the updates in 1.7.

 

Personally I like 1.6, and have generally liked all the changes from 1.5 onward. I just hate forcing people to update their Java install for my apps if they don't use it often and have an older version. But given my druthers, I think everyone should have the latest version at all times.