Jump to content
InfernalKeith

Dead Station

Recommended Posts

Any thoughts on whether I should stop now and go to a text-string-based system for storing that information, or forge ahead with my DIM'd array?

 

Numeric variable = 8 bytes

String variable = 1 byte per character

 

Strings are much better. It does add an additional operation to convert a string back into a numeric value, but the trade-off is worth it. Plus, you have 11k of stack that you can't use for program space.

 

One question I had was, how are you maintaining different maps for each player?

 

Adamantyr

Share this post


Link to post
Share on other sites

Any thoughts on whether I should stop now and go to a text-string-based system for storing that information, or forge ahead with my DIM'd array?

 

Numeric variable = 8 bytes

String variable = 1 byte per character

 

Strings are much better. It does add an additional operation to convert a string back into a numeric value, but the trade-off is worth it. Plus, you have 11k of stack that you can't use for program space.

 

One question I had was, how are you maintaining different maps for each player?

 

Adamantyr

 

There's only one map, it stays on the screen constantly. When you move, the area you move in does NOT reveal itself. Your robots have no visual sensors. You only see map area when you find "light switches" (there'll be a more elegant term for this by documentation time) to restore your overhead visual (i.e. the game map). So if you use the sonar ping, and determine you can move four spaces south, and do so, the screen is still a solid white mass. Finding the switches will illuminate some of the map, and there will be other tricks your bots can use (at a considerable cost in power) to "light up" part of the screen... which is then visible to both players.

 

Point well taken on the string usage... I'm wondering there'll be a price to pay in speed though. I don't want to get so spoiled by the overdrive mode in Classic99 that I make the game unbearably slow on a real machine.

Share this post


Link to post
Share on other sites

Point well taken on the string usage... I'm wondering there'll be a price to pay in speed though. I don't want to get so spoiled by the overdrive mode in Classic99 that I make the game unbearably slow on a real machine.

 

Numeric variables are just as slow, most of the time, since everything is pushed through the ROM and GROM floating-point routines.

 

Adamantyr

Share this post


Link to post
Share on other sites

Point well taken on the string usage... I'm wondering there'll be a price to pay in speed though. I don't want to get so spoiled by the overdrive mode in Classic99 that I make the game unbearably slow on a real machine.

 

Numeric variables are just as slow, most of the time, since everything is pushed through the ROM and GROM floating-point routines.

 

Adamantyr

 

OK. And having everything already in string form would probably make I/O a lot faster for saving games, too. I'm sold -- I will redo it tonight and ditch the array.

 

I really appreciate the input. I'm pretty low on the totem pole around here, skills-wise, so it's nice to have advice from people who've been doing it longer and are willing to share their knowledge. Now I'm off to see if I can make some 8x8 "artifacts" that actually look like what they're supposed to be... :)

Share this post


Link to post
Share on other sites

Strings are much better. It does add an additional operation to convert a string back into a numeric value, but the trade-off is worth it.

It might not be necessary to convert a string (a character) to numeric value. Strings can be compared with "equal", "greater than" and so forth. Even though DISPLAY can not reach as far left and right of the screen as can HCHAR, DISPLAY might even be made to be quite efficient since it can display many characters horizontally in one go. Also one has to remember the power of SEG$ and RPT$. Here's an example:

 

100 L$=RPT$("ABCDEFGH",5)
110 FOR A=0 TO 31
120 DISPLAY AT(A+1,1):SEG$(L$,(A AND 7)+1,28);
130 NEXT A
140 GOTO 140

Note how we use AND 7 to keep A in the range 0 thru 7.

 

:)

Edited by sometimes99er

Share this post


Link to post
Share on other sites

Okay, thinking out loud again here...

 

Say I have thirteen possible things a square in the map could be. (empty hallway, battery pack, transporter pod, wall, etc). Let's say I assign those items the letters A-M. N-Z, then are the same thirteen items, only obscured by darkness (invisible on the displayed map).

 

So one horizontal row of the map, if it was all clear hallway, but invisible to the players, might be "NNNNNNNNNNNNNNNNNNNN".

 

Then, if the first three vertical rows are illuminated, the string would be "AAANNNNNNNNNNNNNNNNN".

 

The game will react the same to an A or an N -- it's a usable square of hallway. Sonar pings and laser shots can travel through it unimpeded. A robot can enter and traverse it. The only difference is, an A shows up on screen as a clear section of map, while an N is still obscured visually.

 

I think I'm getting my head around doing it this way.

Share this post


Link to post
Share on other sites

What you're talking about here is quite cool.... Seems like it will be excruciatingly slow in XB though...

 

How is it playing on your end? I'm sure it plays great in Overdrive mode... Wonder what we could do to speed up the logic... :) This game concept is so cool, I hope it plays fast. :)

Share this post


Link to post
Share on other sites

What you're talking about here is quite cool.... Seems like it will be excruciatingly slow in XB though...

 

How is it playing on your end? I'm sure it plays great in Overdrive mode... Wonder what we could do to speed up the logic... :) This game concept is so cool, I hope it plays fast. :)

 

All I'd gotten done so far was with the array version of the map (DIM MAP(15,20)) and a few random things, like the sonic pings from where the robot was to the nearest object. Those didn't seem too slow to me, but I hadn't gotten too far yet. If I gut that code and go with the map as a set of strings, and have to do a lot of SEG$ work, my gut feeling is that it will be slower. But I'm gonna try it now, before I'm halfway finished and married to one concept or the other. Got some uninterrupted game-time set aside tonught so I will work on it more then. And I'm leaving overdrive off entirely (although I am coding in Classic99 at the moment) -- I wanna make sure this game doesn't suck on real hardware. :)

Share this post


Link to post
Share on other sites

Keep in mind, too, as a turn-based game, it's not as dependent on blinding speed or precise keyboard response. And in most cases, the manipulation of stuff on the screen will be in small pieces, so there won't be any grindingly slow waits to redraw half the map at once, or anything like that.

Share this post


Link to post
Share on other sites

Well, I've played plenty of games that were "slow"... But a good strategy game won't be killed by that... Typically, as long as the user input is responsive, the processing time isn't that big of a deal. I assume you're using GCHAR to check the tiles in each direction? I could probably find/roll an assembly routine that replaces GCHAR... Instead of CALL GCHAR, you could "CALL LINK GCHAR/O".... Although with passing parameters, the speed difference would probably be minimal... I don't know for sure. If your map is in low memory, it would simply be a CPU check for a particular ASCII character. I'm not very good in assembly yet, but I've been studying pretty heavily lately. I'm sure others could weigh in alot more decisively than I, but it wouldn't affect much in your code... Just a LINK to a routine replacing a subroutine like GCHAR. I actually reproduced your Example map in assembly yesterday. Check the "Assembly BYTE" thread to see what it looks like in assembly.

Share this post


Link to post
Share on other sites

Well, I've played plenty of games that were "slow"... But a good strategy game won't be killed by that... Typically, as long as the user input is responsive, the processing time isn't that big of a deal. I assume you're using GCHAR to check the tiles in each direction? I could probably find/roll an assembly routine that replaces GCHAR... Instead of CALL GCHAR, you could "CALL LINK GCHAR/O".... Although with passing parameters, the speed difference would probably be minimal... I don't know for sure. If your map is in low memory, it would simply be a CPU check for a particular ASCII character. I'm not very good in assembly yet, but I've been studying pretty heavily lately. I'm sure others could weigh in alot more decisively than I, but it wouldn't affect much in your code... Just a LINK to a routine replacing a subroutine like GCHAR. I actually reproduced your Example map in assembly yesterday. Check the "Assembly BYTE" thread to see what it looks like in assembly.

 

 

I appreciate the offer, but I'd prefer to keep the game 100% XB, since that's where I'm at right now, and I wouldn't feel comfortable releasing a game where I didn't know what some of my own code was, or how it worked. Once I finish up this particular batch of game ideas I've had brewing for years, I plan to devote some time next year to learning assembly -- I have ideas for some games that I *know* won't work in XB, so I've sat on them all this time, till I have the skills to tackle them properly. At some future point, I may revisit my older stuff and redo it, but that's planning WAY farther ahead than I'm comfortable with. :)

 

Off to the warehouse for a quick order pull, and then it's coding time!! Hoping for a nice late night and a lot of progress this evening.

Share this post


Link to post
Share on other sites

Good luck to you. :) I know what you mean when you talk about intimately knowing your code... Makes you proud to pound out a program with a hammer, anvil, and fire.

 

I have this vision in my head when I think of InfernalKeith coding a game... Sitting there in a dungeon plunking away on original steel, listening to some dark metal while screams of small woodland creatures waft through the air.

 

You're truly an inspiration to us all. :) Stay real, man...

Share this post


Link to post
Share on other sites

Good luck to you. :) I know what you mean when you talk about intimately knowing your code... Makes you proud to pound out a program with a hammer, anvil, and fire.

 

I have this vision in my head when I think of InfernalKeith coding a game... Sitting there in a dungeon plunking away on original steel, listening to some dark metal while screams of small woodland creatures waft through the air.

 

You're truly an inspiration to us all. :) Stay real, man...

 

And coffee. You forgot the coffee. Empty cups littering the floor, cup rings on the console and all over my graph paper...

Share this post


Link to post
Share on other sites

Just a progress update - had to take a few nights off from coding to stay caught up with work, but I'm doing some work on features tonight.

 

One I am wrestling with right now is a sort of 'land mine' that bots could leave in a corridor, to be triggered by the next robot (friend or foe) to step on it. The plan was for the mine to not only blow up the bot, but blow a hole in the station floor, which any passing bot would then fall through if it passed over.

 

For the sake of storyline, that seems a little silly, since there's a vacuum outside a space station. Besides, I think having a floor in multiple states (passable, "hole in the floor") that affected bots one way, but didn't affect the laser blasts or sonic pings, would add more calculations and possibly be overkill.

 

There's already a "chain reaction" possible - if it is triggered (either by throwing a switch or shooting a reactor core), red antimatter spreads randomly throughout the rest of the game, taking over one or two spaces per turn and rendering them impassable and fatal to the touch. That's still ridiculous in a pulp 40's sci-fi kind of way, but better than turning the space station into Swiss cheese... and the properties of the antimatter squares will be easier to check for (they'll block laser blasts and sonic pings like a wall).

 

But I *love* the land mine idea, especially given that you can't see where you are for a portion of the game cycle. I'm picturing people leaving booby traps for each other along corridors, then backtracking and forgetting they dropped a mine... boom!

 

I think my solution is gonna be to leave land mines IN, but not have them so strong as to blow a hole in the station. They'll cause an amount of damage to any bot that hits one, and that'll be the end of it.

 

Back to work...

Share this post


Link to post
Share on other sites

Any new screenshots for us, broseph?

 

Nothing yet. Screen will be pretty static for a little bit, till I can implement all the features. Added a little bit of what I think is cool atmospheric stuff, like the user prompts having a "teletype" sound effect, and worked more on the logic of modifying the strings of the map for player moves and actions. Gonna try to do a big chunk of coding tonight since I've pretty much decided to take the night off from work and do an all-nighter tomorrow... always a great idea. :)

Share this post


Link to post
Share on other sites

ARGH!!! One of those 'so obvious it took me two weeks to see it' moments just happened.

 

I made this big deal about having two values for every square on the map. Say, if 3 meant that square was a corridor with a battery pack in it, -3 would be the same corridor, only "invisible" to the viewer.

 

Then it hit me. The TI doesn't need visual cues... only the players do. The map onscreen starts out as a solid 15x20 block of white, and is only gradually revealed... but it's never UN-revealed and covered back up.

 

So the blanked-out white spaces on the screen don't HAVE to represent a damn thing! I can just print a bunch of solid white characters! I only have to draw in portions of the actual map as the players illuminate parts of the map.

 

I dunno if that makes sense to anyone or not, but it just saved me a whole bunch of variables and screwing around, and I feel like an idiot. :/ Off to go beat my head against the wall some more...

Share this post


Link to post
Share on other sites

Makes perfect sense... =)

 

My head is flat from all my "head-banging" against the proverbial wall while coding... You're not alone, my friend...

Share this post


Link to post
Share on other sites

Okay... small title sequence finished, some glitches chased down, display elements working properly for top status indicators. Ping still slow, gonna work on that and a better system for populating the station with artifacts tomorrow, and then get to work on the other player moves and inputs. Lots of progress tonight!

Share this post


Link to post
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.

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