The Legend of Beryl Reichardt

[+adamantyr]

Awesome! Glad to see you're still working on it!

[+adamantyr]

Hey Owen, now that you're back, is this one getting resusitated?

 

Adamantyr

[Opry99er]

God, man... you know there wasn't a single week (and many times a single day) this game wasn't in my mind over the last 2 years. I am still very much in love with the game idea and story but I made several mistakes in the initial development.

 

*I focused too much on graphics/presentation and not enough on content/engines

*I wrote several versions of code without dating them... I do not know which is the most current

*I relied on others for assembly routines which I cannot duplicate or manipulate

 

Add these things up and I've got an unfolded lawn chair of a development history. Had I paid more attention to your tips in Tilting at Windmills, I would be in a much better place. The story and project excited me so much that I barreled (no pun intended) into it full force and focused on the wrong things. I never really gave much thought to limitations--- the guys who were kind enough to help me get some of the cooler elements of the game going were so talented that I couldn't accept limitations in my head... I just thought "I'll make Final Fantasy 4 on the TI-99!!!" =)

 

Each time I would build up to something good, I would stand back and look at it and say "wow, look at that" as opposed to following a set line of pre-designed steps towards completion. If I re-ignite development, it will be a very different pace, and a very different mindset. More measured, less erratic. As much as I loved the flashy side of pushing the envelope and making beautiful graphics, it was counterproductive.

 

All that said, I think about this game nearly every day. It will be virtually impossible to NOT restart work on it.... It will just be a very different kind of work. About a year ago I started working on the inventory handling engine and battle statistics... Spent about a week of free time toying with different stuff... It's all over my HD though and I don't know where I was going with half this stuff. =)

[lucien2]

Each time I would build up to something good, I would stand back and look at it and say "wow, look at that" as opposed to following a set line of pre-designed steps towards completion.

 

I think it's the fun way of programming versus the "professional" boring one. When I came here the first time, I read this thread from top to bottom, and it was really enjoyable.

 

If you read how the original Macintosh was developped, it's more "wow, look at that".

[Opry99er]

Yea... and with guys like matthew and sometimes99er helping me out with graphics and effects, it was an EXTREME "Wow" experience. Those guys made it fun for me time and time again.

 

I really want to get this going again, but I'll have to re-familiarize myself with the code.

 

Reading back through this dev thread has re-opened my eyes as to where I was and what I had and hadn't done yet. =)

[+adamantyr]

Yeah, it's a common thing for starting game developers, to over-reach and focus too much on the appearance. Don't worry, you're in good company.

 

It's good that you still HAVE all your old source code, at least. Nothing worse than losing it. Plus, it actually helps you restart the design process.

 

My suggestion is to start with a design document. Write out everything you want the game to have. Number of game screens, type of gameplay, etc. Focus more on the engine to drive the game than the story in this document. Then based on that, do up some checkpoints and milestones. Engine work can get really boring at times, but you have to get through it before you can get to the story crafting.

 

IF you decide to go 100% assembly, it will definitely be a trial when it comes to debugging. I've found that the cleanest code I've written resulted from me writing it down on notepads away from the computer first. And there's plenty of assistance here on the forum if you need help with assembly work.

 

Adamantyr

[S1500]

I would say make a solid game engine first, worry about graphics & presentation layer later.

[Opry99er]

Luckily I have the original code... all of it. Looking back at it, I have more meat and potatoes in there than I thought. Exploration, inventory, item usage, status display, etc... I'll need to complete a few of the unfinished routines like battle and world-item generation, but for the most part, what IS there is good.

 

There is more good stuff in there than I remembered. =) That's promising

[matthew180]

*I relied on others for assembly routines which I cannot duplicate or manipulate

 

Yeah, but those others are still here. :-) Plus, I know you have the desire and ability to learn, so this won't be a problem for you for very long.

 

As for your approach, as others have said, it was typical of anyone getting started and we have all been there. This is a learning experience after all. However, there is something valuable with that approach as well, mainly that you don't limit yourself during the creation process. More experienced old-timers tend to the other extreme. This is a classic young vs. old, exp. vs. brute-force and applies to any walk of life. Sometimes not knowing or understanding your limitations allow you to achieve things others thought impossible.

 

My opinion on game development is, it has to be fun. There is usually a core mechanic that is fun to play even with block graphics. You prototype that mechanic quickly and make changes often until it feels right. During that time your code is going to look like crap, and you should work in whatever environment / language lets you be the most expressive and work the fastest. I read an article a long time ago about the original Diablo (Blizzard) and they had the core hacking and slashing of monsters done in about a week, which is basically what the game is about. It then took them a year or so to *finish* the game. You should be able to sum up your core game play in a single sentence.

 

You have to have some goals for sure, but I would not recommend a "design document" per se, since you will never finish it (the document or the game). They are kind of like business plans, very academic and "step 1" in any business book, but some people do them and some don't, and lots of successful businesses are started without them (and those who do write them never go back and keep them updated as the living document that they are supposed to be).

 

Anyway, for such a resource limited machine as the 99/4A and others of the era, it is hard to make something *too* big, IMO, that would require a full-blown design *yawn* document. Write down the core mechanic, make it work, make it fun, add your goals / rewards (the things that motivate the player), then anything you need to support the core mechanic. Make a huge list at first, then narrow it down. It is better to have lots of ideas that you can eliminate than to have too few. Very much like good movie editing.

 

My two-cents, take what you want, leave the rest.

[+adamantyr]

True, design docs are mainly just to organize your thoughts. And it looks like, reading over this thread, I gave this advice three years ago too.

 

My new bit of advice is, get your baseball game done first. Get your feet wet with that.

 

Adamantyr

[Opry99er]

That's why I love this forum...

 

Thank you Matthew. You have, once again, made me excited to work on this lil' ol' project o' mine. =)

 

I will need to go back and re-examine the game code... specifically the primary exploration loop... before I really can start again. If I remember right, the loop code for that routine is only 10-15 lines of code. Just mainly scanning for keystroke, and GCHARs for collisions/acceptable moves. One thing I remember I needed to do is rework the map data in Magellan to group the character sets together which will be "acceptable" tiles for motion. I remember trying to use Magellan toward the end there and something was broken. I think Sometimes has made some upgrades since then, so I'll need to re-DL.

 

I like your thoughts about a single sentence defining the game. =)

 

**In this game, you and your company travel through (and interact with) multiple worlds, battling evil enemies, gaining experience, and collecting items while working toward the goal of the completion of your quest.

 

Sound good? =)

 

 

 

@Adam **Yes, you DID give me that advice before. =) I just basically got cocky. hehehe.....

[Opry99er]

Yea... baseball game first. I'm not even looking at Beryl code right now. I'm focusing on doing this baseball engine right now... It's alot more complex than it seemed at the outset, but it's a good re-entry into coding... The rust is nowhere near worn off yet!

[matthew180]

**In this game, you and your company travel through (and interact with) multiple worlds, battling evil enemies, gaining experience, and collecting items while working toward the goal of the completion of your quest.

 

Sound good? =)

 

To me, collecting items and traveling through worlds are just support for the core. Something more concise maybe?

 

"Battling monsters to complete quests"

 

Where you battle (worlds), what you get (items), gaining exp (leveling up), are not core, they just support the core game play. In this scenario you would get the ability to hack-n-slash monsters (fun) working first, then the ability to get quests (the reason to kill stuff). Adding reward items leads to inventory. Then add the places you will romp around in (the world).

 

[Opry99er]

Sounds fair... Battle engine is tricky because of statistic handling and carrying. I had something I was working on which would draw these from disk, but I don't remember how I was doing that. I'll have to go back and look at my commented code to try and remember. If nothing else, just getting one enemy with static statistics to battle the party would be a great step.

[matthew180]

Don't over complicate things until you figure out how it will all work. Make it an iterative process and you will have more fun. Make one player and one monster. The player gets a sword or something and the monster has claws and teeth. Make the combat work. Then it is a lot easier (and more fun) to say something like "now all I have to do is change this hard-coded number into a variable and I can change this or add that", etc. Sooner than later you will have a functional combat system, and if something is not working it is easy to rip it up and start over or at a point where you liked what was happening.

[Opry99er]

Yes, thank you again, Matthew. I'll start toying with it this week, probably sans-graphics for now, to see what I can come up with. I think one of the problems that I kept running into in earlier stages of development was that I could see too much. By that I mean I knew one or more of the issues that would/potentially could arise during the writing of an engine or a routine and I tried to create preemptive solutions for problems that didn't exist yet.

 

This was a frustrating way to try to develop and a mistake that shouldn't be repeated again. =)

[Opry99er]

Adam's "ground-up" advice is seeping back into my recalcitrant skull as we speak... =)

[Opry99er]

Got back to looking at the code for this game... I am pretty shocked at the simplicity that is there... It is kind of surprising... The baseball simulation has 3 times the amount of code!!!

 

Now, with the awesome updates to Magellan, I will be re-designing the Forest world SLIGHTLY to get rid of a couple bugs and plug everything into the assembly "DRAW" routines and get back to it!

 

First step is to make a few adjustments to the ITEM menu to make things a bit more intuitive.

 

Next step is to re-do some stuff in Magellan to make the bugs go away... I need to re-order my character sets to allow for faster, more accurate boundary checks in the exploration mode.

[Opry99er]

Developing the baseball game has given me a few new ideas I wanted to share here.... The statistical "versus" engine in the baseball game is very similar to how battles are handled in RPGs... Each side has a statistic (or statistics) that are compiled and compared with slight randomization to determine the winner of the "battle". The logic is essentially the same there, with perhaps different resulting values, but comparative statistical analysis with some minimal AI and enhanced user interface is the heart of the RPG battle engine. =)

 

I have looked over the commented code and docs I was using before I put Beryl away for a while (specifically at the battle engine part) and it was pretty muddled and convoluted with unnecessary statistical values and equations which did nothing but eat space. A far simpler approach will be necessary at the outset. I have decided to scrap the original battle engine development and start, as matthew and adamantyr have suggested, with the simplest of methods... "Get a monster with teeth to attack Beryl, who has a sword" =)

[Willsy]

A bit of advice from me: Don't be afraid to throw code away.

 

Ideas will develop and mature *as* you code, and you'll implement them. 99% of the time, the code ends up being total crap, and you have to have the gonads to take a deep breath and say "Well, we'll call that prototype" and ditch it, and re-implement it. You'll end up with much neater code.

 

If you use XB, USE SUBs!!!!!!!! I can't stress that enough. It makes your code SO much more readable 5 years later.

 

Which is clearer:

 

1040 GOSUB 2060

 

or

 

1040 CALL DROP_ITEM(ITEMS())

 

[jacquesg]

I agree with using Call SUBs because it improves readability. One offset is that if you want to use prescan for the whole program then you must apply prescan separately to each subroutine as well as to the main program section.

 

Jacques

[Opry99er]

Yea, there are a few things hanging over this project which will have to be fixed to continue development.

 

 

1) The map data. I noticed during exploration testing that there are a few screens where the character can get into an unescapable position--- I tried to do some map editing in Magellan, but the older version I had skewed the map data for some reason, rendering a giant mess when I tried to plug the exported DATA into my program. I don't know why it did this, and it may be fixed now, but when I was working on the ITEM menu last year, I could not change the MAP DATA and export it.

 

2) Character sets. In the exploration mode, the boundary checks are GCHAR(PY,PX+1) or something of the like. If the user presses D, the program checks for the character in the position requested and returns the ascii code. It works beautifully. HOWEVER.... The real issue is that the acceptable range does not exist in sequential character sets, so it is impossible to check for "IF ASCII CHARACTER IS WITH X TO Y RANGE, ALLOW".... I have to check multiple character codes and character sets because I was not fore-thinking when I put the graphics together.... The unacceptable tiles are all over the map, so to speak. This slows down even further the ALREADY slow GCHAR function to an unplayable level.

 

3) Battle screen switching... senior_falcon may have solved this for me already with XB256 (or at least one or two routines in that suite)... I need to be able to switch character definitions and screen display in an instant--- which is impossible in XB without assembly support. Right now, it takes roughly 12 seconds to switch my character sets and draw the battle screen in XB... an UNACCEPTABLE amount of time for an interactive RPG... I need to cut that number into a quarter, if I'm to be happy with the result.

 

 

Some of this stuff is going to be fairly simple to "fix", but there are some things, like the delay of redefinition and screen draw, that may be tougher. I don't know which area of VDP senior_falcon is utilizing with the XB256 CALL LINK(SCREEN1/SCREEN2), but it MAY interfere with the current scroller I'm using in the Forest exploration. (STILL LOVING THAT ZELDA-STYLE SCROLLING EFFECT!!!)

 

In any case, I'm going to need to just trash the current .mag file and start over... I hope to retain some of the shapes and designs of the current world, but unless we can now swap entire character sets (without changing the layout of the individual graphics in the Magellan editor) then I'm going to need to do a full-on restart with the maps...

 

 

Owen

Edited May 7, 2013 by Opry99er

[sometimes99er]

I think the current XB Compiler will give you almost everything you have today, and you’d be able to do it all yourself in the comfort of XB. That’s including Zelda-like scrolling. I understand that a few things are coming to the XB Compiler, and with that, it appears as if all of your needs will be covered, including automated song playing.

 

What I’m saying is - if you want to continue to use the assembly support you already got, you will otherwise be stuck with the slow speed of XB. With the XB Compiler, you can swap character sets in less than a second, and everything else with the speed of assembly. You'd have to redo the scrolling, but that's about it.

 

From what I’ve seen (videos), I’m not sure you need more than one XB character set, but of course, I don’t know where you’re heading.

I could take a look at your .mag files (incl. the damaged ones) and see what fits where.

 

In any case, I'm going to need to just trash the current .mag file and start over... I hope to retain some of the shapes and designs of the current world, but unless we can now swap entire character sets (without changing the layout of the individual graphics in the Magellan editor) then I'm going to need to do a full-on restart with the maps...

 

Magellan has supported the ability to swap characters, graphics etc. for a long time (Tools menu). Only one character at a time though.

 

Edited May 7, 2013 by sometimes99er

[Opry99er]

Hmmm... thank you for that info. And I would be VERY appreciative if you'd take a look at my .mag files... I'll try to get you them tonight.

 

As far as XB character sets, I'm referring specifically to the exploration screen and the battle screen... two completely different character sets, top to bottom...

 

This is the .mag map encompassing the entire forest world

 

 

 

And this is the .mag image for the battle sequence

 

 

 

This would be the battle screen for the LAVA world, but is inconsequential at this point... The map for the lava world isn't completed yet.

 

 

 

 

 

But as you can see, there are many redefinitions that need to take place between exploration and battle screen.....

Edited May 7, 2013 by Opry99er

[Opry99er]

The "blue arrow" is missing in the above-posted forest battle pic... See the one below... That arrow will sit atop the enemies and you can toggle between them to select your target... also, for some magics, all three enemies (in this case) would be targets.

 

Edited May 7, 2013 by Opry99er