Archive: 23 posts

---

So, I'm working on an RPG level. And, as I'm putting things together, it's becoming apparent that the combat system is gonna take up too much of the thermo to be in the same level as an exploration area. So, my solution is, when you trigger an encounter, you get dumped into a sub-level that has the combat system. The big problem there is, of course, that it's hard to transfer information across a level link. AFAIK, the only information you can send across a link is score. The tricky thing here is that you're pretty limited in what you can transfer across! You basically have 4 different pieces of data you can send as far as I can tell, one for each digit tens through ten thousands. Your score goes up to four million but unless there's some logic trickery that's not immediately apparent to me, the score sensor can only pick up numbers up to 100,000, so the hundred thousands digit and the millions digit is useless. I have more than four pieces of data I need to send though! By my count I have like six or seven at the bare minimum: -What enemy you're encountering -Which two party members you have with you -Your level, from which your current stats can be determined in the combat level itself -The current HP value of you and your two party members -The party's current MP, which is shared and pooled. Obviously items, weapons, and armor, which I had been on the fence about, are right out since the bare minimum amount of stuff is already more than I know how to handle. Is there some way I can consolidate these things into only four values? Like some sort of arithmetic I could use to combine them and then separate them again once I'm through the link? I know this is a problem people have had since the game came out, so that means people have either figured out some really clever solutions or there is nothing that can be done and I'm stuck trying to figure out how to cut what are essentially necessities, or else making the exploration sections much less decorated and interesting than I had been planning. I am really hoping it's the former!

2011-07-12 01:37:00 Author: Speed Racer Posts: 156

---

The best idea I could give is to use the score as a code system, instead of as an actual score. For example, you could use 1 or 2 digits to represent each of the 4 values you need. When the player enters battle, use a score giver to set the score to a code, say, 34,739 for example (you can use signal combiners to get the 1's place whatever you like) 3 for enemy, 4 for party members (these are all figurative, I don't know how your system works yet), 7 for level, 3 for HP, 9 for MP. Then when the player enters the sublevel, use a Series of score sensors to decode the score and create the outcome accordingly. After the battle, give another score code to be decoded when they enter the real level. I know this sounds very confusing, but it's really the best idea I could come up with, I don't think any data but score can be transferred right now, so you are pretty much limited to a score-based system, and coding is the next best option. To make it worse, It sounds like the score sensor doesn't count as high as the score could be. I hope this helps you out, although I understand if it doesn't.

2011-07-12 02:26:00 Author: sp0ngyraver Posts: 407

---

I didn't do a good job explaining but that's basically what I was trying to say. Still the fact that I can use the ones place helps immensely. How exactly does that work? Like if I want to give 1 point, I have the score giver set to give 10, put it into the positive side of a combiner, and then what do I stick on the negative side to subtract 9? How do the scores sync up with analog signals? Also I did figure out a way you can arithmetically split a digit into two or more unique pieces of data. Say that two party members have max 5 HP apiece. Give the player 0-40 points to represent the first character's HP, and then give him 10-50 points to represent the second's. When the combat sublevel loads, have a score sensor that checks the tens place of the score. if it's 90, character 2 gets 5 HP, if it's 80, they get 4 HP, and so on down to 50. Then, subtract 50 points from the score. A new score sensor looks at the tens place again and does a similar process. If it's at 40 points character 1 gets 5 HP, etc. The only issue with that is that it really limits the amount of granularity you can get with health values. You could use values from the next digit over, but only by stealing potential values for whatever data you wanted that digit to represent, which sort of defeats the purpose. That said, it's the best compromise I've thought of yet. I can easily do a little futzing around with my system to have it work with very small numbers so that it's not really noteworthy that you only ever have single-digit HP. EDIT: Bah I'm dumb, the scoregiver has an input not an output. Okay so a battery set to one percent with a scoregiver set to 100 and "scaled every second" spits out 1 point every second. Don't suppose there's some trick to speed that up? Don't really want to have to make the player stand around doing nothing for up to 9 seconds, though I guess there are ways to mask that wait time.

2011-07-12 02:43:00 Author: Speed Racer Posts: 156

---

Ah, it seems you were talking about a code system already, I apologize. I actually read on a tutorial here on how to get single digit scores. I know it involved a signal combiner, which acts as a subtracter, I just can't remember what input you use for it. It may have been batteries with varying amounts, then hooked up to a score giver. I'll post the tutorial link here if I find it.

2011-07-12 02:52:00 Author: sp0ngyraver Posts: 407

---

that'd be great! EDIT: Nevermind I managed to find it.

2011-07-12 02:58:00 Author: Speed Racer Posts: 156

---

Awesome! Does it seem like it would help with the coding at all? What you're trying to do sounds pretty intense, you will have to let me know if you get it working right, sounds like you had a fair bit of work ahead of you.

2011-07-12 03:23:00 Author: sp0ngyraver Posts: 407

---

Yeah it'll definitely help out, just insofar as it gives me nine more numbers to work with. It's definitely been very intensive! I've been working on this idea off and on since February, and it's only just recently that I've actually started making progress.

2011-07-12 11:36:00 Author: Speed Racer Posts: 156

---

I would really consider and pursue the effort to combine said combat system into the exploration level if combat is of a regular occurrence. possibly at the expense of graphic detail to save thermo. The loading of a separate level is quite an obstacle in the user experience, IMO. Consider splitting the exploration part into a separate level instead (with its own copy of the combat system) if thermo budgeting is not an option.

2011-07-12 11:54:00 Author: Antikris Posts: 1340

---

Yeah, that's definitely something I'm concerned about. Perfect world I'd be able to to squeeze everything I want into a single level but that's just seeming more and more unlikely. What really surprised me was just how much thermo sackbot costumes eat up! All combat logic + "stat sheets" for every party member only ate up about an 8th of the thermo. I put in 3 party members with fairly simplistic custom costumes and the meter doubles! I really don't get why those eat up so much space. That fishbowl helmet takes up like an eighth of the thermo all by itself! What exactly do you mean by "Consider splitting the exploration part into a separate level instead (with its own copy of the combat system) if thermo budgeting is not an option."?

2011-07-12 18:08:00 Author: Speed Racer Posts: 156

---

What exactly do you mean by "Consider splitting the exploration part into a separate level instead (with its own copy of the combat system) if thermo budgeting is not an option."? If you cannot emit parts of the exploration level to save thermo, cut it in half and put that into another level. It would mean a lot of duplicate content in both levels, nasty to maintain, but ease of maintenance could be a good goal by itself.

2011-07-12 18:17:00 Author: Antikris Posts: 1340

---

Oh you're just saying break the level into multiple levels haha, I am way ahead of you there! I have... a LOT of content planned. Which is why I'm trying to load up each level as much as possible. does emitting parts of a level conserve thermo? I was under the impression that the thermometer measured an emitter's impact by assuming that it has emitted what it emits times the max number of emissions it has. I could certainly design the level in such a way to destroy and emit chunks of it if that would help though. EDIT: Huh! I just checked the LBP wiki, I guess the emitter thing was only true in LBP1? So, you can have WAY more than a thermometer's worth of stuff in your level as long as you destroy old things as you emit new things? That is incredibly handy.

2011-07-12 18:25:00 Author: Speed Racer Posts: 156

---

Yes, you can emit and destroy sections as you need.

2011-07-12 19:29:00 Author: sp0ngyraver Posts: 407

---

The thermo's limit is more to do with what the console can physically handle at any one time. The entire level you make is always there regardless of what you see with your local camera, it's not like sections are loaded as you move closer to them. In essense, this is what the emitter method achieves, they load the relevent parts of the level when needed so you can pack far more into a level this way. What isn't physically being rendered takes up very little space. A good demo of this is when in create mode how the level can lag if zoomed out (or you get exclamation points all over the place) but when in preview with all the mechanics hidden there's no lag at all.

2011-07-12 19:53:00 Author: Xaif Posts: 365

---

Yeah I mean that makes perfect sense I was just thinking back to messing around in LBP1 where I would have something complicated coming out of an emitter, and the thermometer would go up and down as I adjusted the Max Emitted at Once. I just didn't realize they changed that for 2.

2011-07-12 20:20:00 Author: Speed Racer Posts: 156

---

There have been threads about this before, here's one: https://lbpcentral.lbp-hub.com/index.php?t=53260-How-to-transfer-data-from-one-level-to-a-sub-level It contains several video's, lots of theoretical discussion, and me being dense. It's an interesting thought, to have a sublevel for the combat, but you're forgetting something. After combat ends, you'll want to return to the exploration level in the exact state you left it in. As far as I know, that's not possible, so you'd have to send the entire state of the exploration level in the score to the combat sublevel as well.

2011-07-13 13:40:00 Author: Rogar Posts: 2284

---

There have been threads about this before, here's one: https://lbpcentral.lbp-hub.com/index.php?t=53260-How-to-transfer-data-from-one-level-to-a-sub-level It contains several video's, lots of theoretical discussion, and me being dense. It's an interesting thought, to have a sublevel for the combat, but you're forgetting something. After combat ends, you'll want to return to the exploration level in the exact state you left it in. As far as I know, that's not possible, so you'd have to send the entire state of the exploration level in the score to the combat sublevel as well. Well, the thinking was that you would just send the same info back to the original level that got sent to the combat level. Health, level, mp and the like would be conserved, and based on which encounter it was you'd spawn in the appropriate location, and any changes to the level that had to happen to get you to that point would happen. That said, it would've demanded that the level be very linear, and while I would've been okay with that I'm much happier to just emit the level in chunks and allow for a bit more exploration. It

2011-07-13 16:33:00 Author: Speed Racer Posts: 156

---

Oh yeah, I hadn't thought of an ultra-linear RPG, I'm being dense again. Yeah, you could totally do FFXIII this way! But out of curiosity, let me run some numbers: What enemy you're encountering: could be determined from your position in the linear story Which two party members you have with you: let's say out of 5 total members, that's 5 (for the first) x 4 (one less to pick from) = 20 posibilities Your level, from which your current stats can be determined in the combat level itself: I'll be cheap and assume 20 posibilites, but in order to advance in level you'd either need to transmit XP's too (max XP 999?), or scrap XP and determine it from the progression in the story The current HP value of you and your two party members: this eats into your data space really fast, just having max HP 99 means there's 100 x 100 x 100 posibilities, so you're better off auto-healing after battle like some RPG's do The party's current MP, which is shared and pooled: with max MP 99 that's 100 posibilities (or you could go the auto-replenishment route again) So with auto-healing that's 20 x 20 x 1000 x 100 = 40,000,000, which is one zero too many and leaves nothing for story progression. We might suffice with max 99 XP instead, if we make the amount of XP earned dependent on the current level, and auto-replenish MP to free up data space for 100 story positions. Or drop XP's and levels entirely and keep MP's. Or did I forget something? Yes, it seems viable. Limited, but viable. Interesting idea, this. I may have to steal it.

2011-07-13 23:34:00 Author: Rogar Posts: 2284

---

If the level is super-linear, then you don't need to transmit level/XP, because it can be derived from which encounter you're doing. I'm taking a lot of cues from Paper Mario and Mario RPG, so I was going to have a level cap of 30. I'm thinking approximately a ten level series, and when you reach the end of one you can either take a level link that determines your XP from score, or get a sticker with your current XP that you can place if you come back to the next level in the series later. Which sounds like a lot of possibilities until you consider some things: -Even if the level isn't especially non-linear, there are a certain amount of fights that will be unavoidable -Each fight will give a set amount of XP so you can determine XP from looking at which fights you completed -I want to make sure that the player doesn't outpace the enemies, so there will be a sort of "level cap" in each level in the form of a finite maximum amount of XP. If the level cap is 30, there are 10 levels, and I want the player to hit the cap around level 9 or 10, then that's only 2 or 3 level's worth of XP per level Put all that together and it shouldn't take THAT many stickers to save a player's level.

2011-07-14 01:28:00 Author: Speed Racer Posts: 156

---

I actually didn't consider stickers, but for the sole reason that they are reusable, leaving replayability up to the honor of the user. I'd just use my stickers from the last playthrough if they were better, I'm shameless like that, like most video gamers are. CHEEEEAAAAT!!!

2011-07-14 02:26:00 Author: sp0ngyraver Posts: 407

---

Listen if my levels are good enough to encourage people to replay them to get better stickers for future levels I am going to consider that a victory

2011-07-14 02:36:00 Author: Speed Racer Posts: 156

---

Yeah, I don't know why I said that like it was a bad thing.

2011-07-14 03:37:00 Author: sp0ngyraver Posts: 407

---

EDIT: Bah I'm dumb, the scoregiver has an input not an output. Okay so a battery set to one percent with a scoregiver set to 100 and "scaled every second" spits out 1 point every second. Don't suppose there's some trick to speed that up? Don't really want to have to make the player stand around doing nothing for up to 9 seconds, though I guess there are ways to mask that wait time. There is a trick to this, not sure how it would work for individual amounts awarded multiple times, but if you capture the score giver the microsecond before it gives a score, and then emit it it will give score straight away. As the game captures the timing of the signal also. You could then emit it 9 times, making sure that the emit lifetime is less than a second you could mask it. It takes a bit of trial and error to get the timing down though. And as I said not really sure how you could have it emit exactly 9 times versus 5 times... Unless you have some sort of dynamic counter tracking tags. However the more I read about feedback loops, I think that this may be a better way to do things. You store the analogue signal at 1% and trigger it to instantly give out the amount. Means no fiddly timing to mess with. Othe the other emitter front, because you have a clear vision and are planning I really do think that it is prudent to build your battle arenas thememd to zones/areas and emit them when required in the same stage. Destroy when the battle is over and make sure that you destroy previous towns/zones when you have passed through them. This also gives you the ability to revisit a town at any stage by emitting it as the next area. Taking this further you can alter each instance slightly. Example: Make a town and it's all picturesque, but the church tower is underconstruction you leave (the section is destroyed) you keep moving along a linear path and then you need to revisit the town, but a new version gets emitted and this time the tower is complete. Later you go back and this time the place is burned down. Having them 'on file' ready to be called whenever will use so much less thermo than having them sitting in the stage the entire time.

2011-07-14 07:43:00 Author: Mr_Fusion Posts: 1799

---

Yeah, there's really no downside to the emitter thing. I'm not QUITE to the point where I'm ready ready to start designing the overworld areas, but I'll definitely be using the emitter method once I do. Right now I'm stuck in that awful bit where you've got everything figured out but you have to go back and obsessively bugtest everything and fiddle arpuns to ensure that all the individual parts come together and work right.

2011-07-14 12:10:00 Author: Speed Racer Posts: 156

Posts: 1077139    Threads: 69970    Members: 9661    Archive-Date: 2019-01-19

Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.