Jump to content
IGNORED

LGB


Bones-69

Recommended Posts

I was invited to start a thread on a game that I have been working on now for about 2-3 years. I find that my interest in this project comes and goes as I seem to work on it for a few months then take a few months off…. This approach has not resulted in quick progress as it is difficult to pick-up where I left off upon each return. I also seem to return with “better ideas” after a break – maybe that part is good, but if I never get it finished all the good ideas in the world won’t count for anything.

 

I was a little reluctant to start this thread because realistically my game is probably still at least 12 months from completion and several aspects of the idea are still very much in development. However, after finding the AtariAge TI forum I have been infected with new motivation after seeing just how active the TI community still is (which is so great to see).

 

Basically, my game known as LGB (Little Green Bastard), will be a text adventure game written with the Win994a Simulator and Rich Extended Basic. For a long time I contemplated what version of BASIC I should write it in before finally deciding that RXB was the most suitable. Now after using RXB for some time I am left wondering how I could ever return to XB as some of the RXB features are fantastic and I think compliment the standard XB language very well.

 

Like most adventure games, your task is to save the world (or the entire universe in this instance). You as the player are awaken from a deep space sleep aboard your spacecraft to the sound of your ships security siren. Suffering hibernation sickness you stumble around to discover that while you slept your spacecraft has been boarded by aliens (hence the title Little Green Bastard). Your spaceships computer shows that the hyperdrive fuel source (an incredibly rare material that has not been manufactured for over 1000 years), has been removed leaving your ship without light speed engines.

 

This rare fuel source, in the wrong hands, can be used as a weapon against all life in the known universe. Video footage from your computers security log confirms the worst, you have been boarded by a hostile alien race that has a violent dictatorship history. Your mission is to track down and stop these alien bastards, retrieve what has been stolen from you and save the known universe.

 

Your adventure takes place on your spacecraft, different planets plus a moon –however, most of your adventure is conducted on an artificial planet similar to Earth that was originally created for international space tourism. Corny huh? 

 

A few things I wanted to achieve with this game. I didn’t want it to be one of those games where the main challenge was to use exactly the right word to achieve a task and due to this a large flexible vocabulary is built in (although only two word commands are accepted). Also, I didn’t want to create a game that ends in death because a player took a single wrong turn or fell over in the dark, in this game it is impossible to die. I also wanted to create an adventure game that could be finished with or without performing every aspect of the game. This game will keep score so when/if it is completed you have a target to beat the next time around. Final score is determined by secret locations found, achieving missions along the way, remaining health and energy plus the state of your finances at game completion.

 

For a text adventure I think my project is pretty ambitious. The LGB world consists of 1225 locations made up of a grid 35 x 35. While this probably sounds a little absurd and overdone, the player can not (nor has to), visit this many locations. For example, a player might be walking down a hallway with a wall on either side. Their current position is classed as one location, as is each opposite wall. So in this particular example 2 game locations are never actually used. In time I will try and post some graphics to make this point a little clearer. I chose this method because it gave me a lot of flexibility in my game design, as well as being able to easily change the game map during creation and also during actual game play.

 

Each of the game 1225 locations is described by 5 different files which each consist of a 10 digit variable. These location variables are located in a single disk file know as GROM (Game Rom) which is 220K in size with a total of 6125 records. As I make progress I am looking at using this same file to store other GROM data so this file will likely increase in size and records.

 

Obviously with this amount of data, 32K was never going to cut it so there is a second file used known as GRAM (Game Ram). Gram is used to store the variables of each location that can be altered during game play. The GRAM disk file consists of 3675 records (3 records for each location) and each record is also a 10 digit variable, the file size for the GRAM file is 133K. The 3 records in the GRAM file are updated each time the player leaves the current location so nothing about individual locations is stored by the TI memory, every ounce of TI memory is used for the actual program with limited stack used for variable values. While there is only one GROM file for LGB, each unique LGB game slot will require its own GRAM file. The GRAM file is effectively a snapshot of the complete saved-game world at any given time while the GROM file sets the location physics and characteristics.

 

For each 10 digit variable found in the GROM and GRAM files, anywhere from 4-11 variables are hiding in each 10 digit record (I managed to squeeze more variables out of the single number-string by giving them a positive or negative value, and also a decimal point in some instances). I chose to store them as a "string-number" rather than a string due to the reduction in file size between saving numbers and text. I found I could save a number such as -.123456789 in a FIXED 9 file yet to store the same characters as a string the file size was MUCH larger. Therefore, combined GROM and GRAM files represent around 60,000 different game variables.

 

GRAM and GROM files will each occupy one open DSK file. A third open file will be used to access several files for all the game text, character definitions, screen draw data and the objects found in the game.

 

Because of the nature in which the program data is stored the DSK#.LOAD program must always be first executed prior to starting each game. During the LOAD program the player selects the game slot (from previously played games or “blank games slots), LOAD also checks the integrity of the selected GRAM files to check it has been correctly closed during the last game play (this will only take a few seconds). The LOAD program also loads most of the graphics in advance to keep as much unnecessary code out of the main program.

 

Originally I wanted my game to fit on a single emulated 1.44mb disk but it is looking like this will now not be possible. Upon completion I expect the game to use two disks, the second will hold the save game slots (the GRAM files) along with any other data required for saving program variables.

 

So there you have it, a snap shot of my project. Speed of the program and the available memory have played a very large factor in the way I have designed my program and the DSK files used. I am aiming for “thinking time” between commands to be around 5 seconds but at this point can’t confirm this.

 

Currently there is no program to speak of that I can post and even if there were it would be useless without the large GROM and GRAM files used during the game. I have developed around 20 routines for the game engine(and re-written these over and over and over to make them as small and as slick as possible), I have developed the structure of all the files plus have a game map that I am still making small changes on. I guestimate close on 500 hours have been invested over the last 2-3 years to get to the stage I am currently at.

 

Excel has been used extensively during the game design so when the time comes the data will be exported to a word document and then imported as required. This is something I am looking forward to, once this is done the actual program should then come together quite quickly. Probably one of the reasons my motivation has come and gone is due to the lack of programming required at this stage, so far it has mostly been preparation of the enormous amount of data required for the game which compared to programming, I find quite tedious and a little frustrating. All I want to do at the moment is start throwing the game together (building the program), but until the data in the files is finalised there is not much else I can do at the moment.

Link to comment
Share on other sites

I kinda sorta got my head around the idea, in my sleep-deprived state, and it sounds cool as hell. Very ambitious engine for interactive fiction (text adventure) -- sounds like if you put the bones of it together for LGB, you'll be able to fairly easily adapt it to other games, should you ever want to build another world down the road some time.

 

Let the wave of enthusiasm keep you going -- there's a TI renaissance going on, and I'd love to see this project be part of it!

Link to comment
Share on other sites

sounds like if you put the bones of it together for LGB, you'll be able to fairly easily adapt it to other games, should you ever want to build another world down the road some time.

This is actually something I was also thinking. Once the game is complete it wouldn't be impossible to build an editor. In all honesty I don't think this is something that will ever happen, but it would not be all that difficult.

 

Below is a small sample of a map which better illustrates how the locations (where a player can't go) are used in the program. Looking at the centre location in grey which is a spaceship wall, it can be seen how one location can be multi-sided and used as a blocker when the player is in different parts of the map, this is also good for me because I don't have to double up on the data during map creation. In certain parts of the game these types of locations can be renamed, or destroyed, or unlocked allowing the player to move into secret or new locations - all that is required is the 5 GROM files and 3 GRAM files for a particular location need to be replaced with different data, in fact - the GROM files themselves carry event tags that instruct the program which file numbers to replace the data with, so it becomes all very automated within a single IF/THEN statement within the program, rather than having special lines to cater for each individual event in each location (which would mean numerous additional commands and excessive processing of IF/THEN commands throughout the game).

Link to comment
Share on other sites

Fascinating stuff mate! I look forward to updates and if there's anything we can do to help, let us know. BTW, the newest version of Magellan is out. From what I understand, it's still BETA too--- so I believe Codex is still looking for quite a bit of feedback and suggestions for the "real" first release. :) your program is quite interesting, and it could really turn into something wicked now that you've got the attention of all these great TI thinkers here and with Magellan--- you could make this as graphic as you wanted. :) Interesting how you're using the terms GRAM and GROM... Is your definition/use of these terms in any way related to cartridge Graphics Read Only Memory and Graphics Random Access Memory? My meaning is, are you actually creating GROM in the classical sense of the term, or have you customized it to fit your game development needs? Just curious... Thanks for the map (above). It really helps me understand where your program is heading. :cool:

Link to comment
Share on other sites

I think he's using the terms himself to mean "Game RAM" and "Game ROM", and they are not the TI GROM or related GRAM devices.

Yes, this is correct. In earlier versions the files were called LOCROM and LOCRAM. Then when I tore them all apart and took a different approach I renamed them differently just so I wouldn't get confused amongst all my notes. I suppose calling them GRAM and GROM is quite misleading in regards to discussions.... might have to rename them again!

Link to comment
Share on other sites

I took a break from building the game files to do something a little more creative (and much more fun), and started finalising some of the player screens. Have attached a screen sample for a feel of the games appearance. It doesn't include the sprites which will be added later.

 

Using Magellan for this has been incredibly useful. I have found it a little slow with some of the more delicate work (but I acknowledge the way I am using it is probably a little odd), but being able to work out the text placement, characters and colours using Magellan has been incredibly helpful. Prior to discovering Magellan I have been using Excel for a similar purpose and while it is quicker you just can't get a true appreciation of how you hope the finished screens will look. I suspect Magellan will get a real work out while LGB slowly comes together!

post-26079-127211878117_thumb.jpg

Link to comment
Share on other sites

Wow, that looks really good! I can't wait until you have something playable. Are you going to make alpha and / or beta versions available?

 

Matthew

Really not sure at this stage. Maybe when I get closer to a working version I might look at the idea a bit more.

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...