Archive: 20 posts

---

Hi, this question I will have will be incredibly useful to many people I believe if it can be answered. I am working on a metroid style game. As you know, in Metroid, there are collectable items as well as needs to backtrack. The way I will have mine setup is this: I will have my "worlds" (Chozo Ruins, Magmoor Caverns, Phendrana Drifts, etc) have level links at access elevators. The reason why I have to use level links is thermo space. Morphball and Samus together will prolly take up half the thermometer. There simply isnt enough space in one level to include a full game. So, level links will be required. However, when using level links, its like you're starting new. This means all items, power ups, etc get erased when starting new. Now while it is easy enough, say, to setup bot to have all powerups when starting level, it simply doesn't work for backtracking or for collectable items (energy tanks) that are hidden and not required to be found to progress through. This means that when a player starts a new level via level link, they will either lose all energy tanks or have all possible energy tanks even if they haven't found them. I have a solution though, just not the logic ability to implement it. This can also be used for sonic chaos emeralds, megaman progress, and any other game that uses "save" abilities for saving progress of character through levels. Here's my idea: Create a way for a player to input a code upon entering a new world. The code will display depending on how many and what items are collected. There will probably be over 30 unique codes to include everything. The code input area would show up upon entering any new level, and upon entering the correct code the it would spawn the correct samus bot. The code would be displayed right before entering a room with level link, and the code would continue to change in the level based on amount of objects and what objects are collected. Example: Samus has just started and has nothing, code input to start would be 000000, this would obviously be displayed so people can start playing without difficulty. Then say, Samus finds two energy tanks, so a counter would probably go up saying two energy tanks have been collected, this would tell code to change to say 024PLD. Depending on amount of energy tanks the code will continue to change. Then, when samus enters the room before level link, current code will be displayed and player will be advised to write it down. Upon entering new level, code input will be asked, player will put code in and continue without any hassle. Theoretically, this should allow ability to "save item progress" through levels, as well as allow the ability to backtrack with current Samus. Please, anyone who has the ability and intelligence to undertake this logic project, please please please help. It will be a major benefit to the community of LBP. Thanks for your time! Note, I imagine the display will require 36 different invisible holograms for each "digit area", 26 for letters and 10 digits. I would prefer six input areas (000000), to lessen amount of people who try to cheat but trying to guess code before playing. I very very very much hope this is possible to create!

2011-02-27 19:26:00 Author: Shadow_Wolf_1987 Posts: 108

---

Please, anyone who has the ability and intelligence to undertake this logic project, please please please help. It will be a major benefit to the community of LBP. Already built this kinda thing during the beta. Used 32 of the 36 letters/numbers allowing 5-bits of data per char, and implemented an 8-digit code system allowing you to save/restore 40 bits of data in a register. It's not particularly hard, it's just very time-consuming to build.

2011-02-28 00:13:00 Author: Aya042 Posts: 2870

---

you could possibly do something with score sensors. that way people don't have to remember a code. so if you have 30 possible sackbots to emit, instead of having 30 possible codes, use 30 possible score states. Only downside would be that other than as a saving system, the score would be completely meaningless. I mean that is possible right? I haven't had a chance to play around much with score sensors but I know you keep your score going through a level link, and I'm pretty sure score sensors can be set to trigger on an exact score. (if not, why?) So thirty score sensors, 30 emitters, make sure sackboy never dies, and only give him points when necessary... wouldn't it be a lot more convenient for everyone? Like we wouldn't have to write down 30 different 6 digit codes, and you wouldn't have to program all that stuff you just said. Unless, of course, you've already programed all that, (or I'm wrong and score sensors suck) Either way, I look forward to playing it when it's ready.

2011-02-28 05:37:00 Author: Madafaku Posts: 738

---

Wait... In metroid you absolutely NEEDED certain skills and equipment and skills to advance. Even in the oldschool Super Metroid. Why not just emit the same sackbot in different states at the beginning of certain level links? Oops. A little oversight there. The insane backtracking... Jeezum Petes. Belay that.

2011-02-28 06:11:00 Author: DigiOps Posts: 111

---

Problems with both ideas: Points: In this case, using the carried points from links works. BUT, if the player wishes to quit and return, they would lose all their stuff. Code: Since each section isn't going to be very long, due to thermo, putting a code in every link would get very tedious for the player. You could always combine them. At the beginning of a "Chapter" of levels, it requires a code. Depending on the code, it would spawn the right bot and give symbolized points. Then the player plays through. If the player quits in between the "Chapter", it would be like the message in games. "If you quit now, all unsaved progress will be lost." Keys won't work in this case since you have backtracking. Now they WILL work if you just publish the same level that will be used as "backtracking". The player beats the first level of the "Chapter", and gets the key and level links to the new area. At the end of THAT area, they get a different key, and it transports them to a COPY of the first section. But in this new section, they now spawn into a different bot. OR, you can take the combination of the POINTS and CODE idea, and replace the CODE part with KEYs.

2011-02-28 11:26:00 Author: Devious_Oatmeal Posts: 1799

---

Another idea is to use stickers. Based on what you collect, you get bubbles that contain stickers to take to the next level and apply at the beginning.

2011-02-28 14:16:00 Author: Shanghaidilly Posts: 153

---

Another idea is to use stickers. Based on what you collect, you get bubbles that contain stickers to take to the next level and apply at the beginning. In this scenario stickers would probably be best since Metroid is a single player game (at least all but Echoes and Hunters anyway) and making stickers for the power ups or stages in the game wouldn't be TOO difficult. Maybe not one for every save station, but possibly one for every upgrade unless you count missile packs and battery expansions. By the way, looking forward to it. *thumbs up*

2011-02-28 17:24:00 Author: DigiOps Posts: 111

---

you could possibly do something with score sensors. that way people don't have to remember a code. so if you have 30 possible sackbots to emit, instead of having 30 possible codes, use 30 possible score states. Only downside would be that other than as a saving system, the score would be completely meaningless. There are ways around that. For instance, you only need the score to carry game state information when you are exiting one level and entering another.. The rest of the time, that information can be carried in other logic. So a very simple solution would be to make sure the player score normally can't exceed a certain limit - and then store information in player score by giving them a huge amount of points (say, a multiple of 100,000) when they're about to enter a level link, and then at the other end of the level link, subtract 100,000 points from their score repeatedly until it's under 100,000 - the number of times you added or subtracted 100,000 points carries information over the level link for you. But for this approach you need to be sure that the player's score never naturally exceeds the threshold where you start encoding data... Alternately, you could go the other route: store information in the low digits of the score, and make sure the player never winds up with a score that's not a multiple of 100. But that means you can't use score bubbles (well, not unless you round the player's score up to a multiple of 100 each time they use a level link)... This approach is a bit more complicated because to detect the low digits of the player's score with a score sensor you need to somehow eliminate the higher digits from consideration - subtract them away temporarily or something. One possibility would be to read the player's score with a score sensor and then use meter logic to pull out the low-order digits of the score. An approach like this could also probably take advantage of Tygers' recent discovery of score sensors outputting analog values greater than 1.0 - some investigation would have to be done along those lines, but it's possible you could quickly get to the desired result by using a 100-point score sensor and some logic to pull out the answer to "how far is the signal from the closest increment of 100%?"

2011-02-28 20:54:00 Author: tetsujin Posts: 187

---

If you're going to use score sensors, I'd recommend using the max value (100,000) no matter what scale you are operating on. Dealing with numbers greater than the target value are possible but a pain due to the inaccuracy of division.. I do have a circuit that will keep subtracting 100% until the value is under 100,000 and report how many times it did that. However, it might be better to "unroll" the loop since a score can never exceed 40 million. Just subtract 100% from the score 40 times in a row, and test each one to see if it's negative. Take the first one that's negative as the final count. Then take the resulting value and pass it through a series of 5 circuits to decode the decimal number for digits below 100,000. (5 stripe wide sequencer, with 9 batteries at 10, 20, 30, 40, 50, 60, 70, 80 and 90%, subtract that from the input, then multiply the result by 10 to get the input for the next decimal decoder, use the true value of the battery signal to drive the logic for what the number is, plus a NOT OR gate across all for 0.) That gets you all possible scores. To deal with rounding error, add 0.000005 to the output you are sending to the decimal decoder (A timer with its output fed into its input to disable it, set to .1s out of 2000s will do the trick). You can use the same circuit to round down the score if you want to use the low bits. Using the high part is going to be a pain because 10,000 is the max score givers can be set to; but 10-100 score givers is probably still less parts than the circuitry to deal with the low part of the score.

2011-02-28 22:27:00 Author: Tygers Posts: 114

---

As a player, would you rather: Enter a code at the start of each section, which you will have to write down and, if you play over multiple sessions, keep somewhere safe; Have your score turned into a game save status code, keeping things simple for you but preventing you from quitting and resuming later; Collect stickers that you can place on a board to unlock new and better powerups when you return to a level? One of those options puts the censorship into analog. The other is kludgy. One is littleBigPlanet's style.

2011-02-28 22:45:00 Author: munrock2 Posts: 96

---

One is littleBigPlanet's style. By which I assume you're referring to the 3rd option, but should you wish to save 40 bits of data, would you rather implement an 8-digit code system, or create 1,099,511,627,776 different stickers?

2011-02-28 22:57:00 Author: Aya042 Posts: 2870

---

As a player, would you rather: Enter a code at the start of each section, which you will have to write down and, if you play over multiple sessions, keep somewhere safe; Have your score turned into a game save status code, keeping things simple for you but preventing you from quitting and resuming later; Collect stickers that you can place on a board to unlock new and better powerups when you return to a level? One of those options puts the censorship into analog. The other is kludgy. One is littleBigPlanet's style. As a player, I don't care if something is "kludgy" as long as it works. Collecting a power-up in the first part of a multi-part level, and continuing to have it in my possession when I arrive in the second part sounds great. As a player I'd be all in favor of that. As for "one is Little Big Planet's style" - it seems to me a lot of things LBP2 allows you to do, and a lot of the things people have apparently always wanted to do with LBP aren't really "LBP's style" anyway. I'd go so far as to say that advanced movers, rocket rotators, gyros, maybe even the DCS are all decidedly not "LBP's style". One of those options puts the censorship into analog. What does that even mean? And bear in mind - there is no reason one couldn't implement both solutions 2 and 3: When you receive a new weapon, you also get a prize bubble containing a sticker corresponding to the weapon you just received. At level link points, implement the score giver/calculator logic as previously discussed. If the player quits the game and comes back later, he can put his collected stickers on switch triggers to restore his previous game state. I'm not sure if the score-giver logic can be hidden from the player (Can you give score while a movie camera is on? Will the player see the score being given?) - but for carrying information from one part of a multi-part level to another without user intervention, it's pretty much the only way to go. There is a pretty elegant solution to approach #1 as well: when you display the user's "continue code" for them, use a snapshot camera to take a photo of it. (Better yet, make this optional, let the player decide... I hate snapshot camera spam...) Then when it's time for them to resume, they can stick the snapshot sticker up somewhere and use it as a handy reference for re-entering the code. I guess another, related alternative to the score thing would be to implement your own score-keeping system via a digital counter, and then translate that into "real score" when the game ends. But then you've really killed the possibility of including score bubbles, unless you're constantly draining score from the player and sticking it into your in-game tally... (Does score-giver deduction and addition interact with bubble multipliers?)

2011-02-28 23:19:00 Author: tetsujin Posts: 187

---

There is a pretty elegant solution to approach #1 as well: when you display the user's "continue code" for them, use a snapshot camera to take a photo of it. (Better yet, make this optional, let the player decide... I hate snapshot camera spam...) Then when it's time for them to resume, they can stick the snapshot sticker up somewhere and use it as a handy reference for re-entering the code. You sir, are a genious.

2011-02-28 23:43:00 Author: DigiOps Posts: 111

---

By which I assume you're referring to the 3rd option, but should you wish to save 40 bits of data, would you rather implement an 8-digit code system, or create 1,099,511,627,776 different stickers? When you've made a persistent powerup system with so many options that make useful use 40 bits of data to save all the possible combinations, send me a PM if this website still exists, and I'll dig my LBP2 disc out of my attic and put it into my PS12 and let my great grandchildren play it edit: as for entering codes, instead of rotating through hexadecimal or decimal figures to input a code like it's the 80s and we're using gameshark codes, why not use the controller's face and shoulder buttons in place of digits? Much faster for the player to input.

2011-03-01 10:49:00 Author: munrock2 Posts: 96

---

I would vote for the score based system. Even if it means loosing the score. You know - you can use "trophies" system to score. So when player will perform some skill action (not mandaory poress in stroy that anybody have to do! - I mean killing boss under certain time, finding the secret aread etc) you will mark a "Done" bit for that achievement. (these bits will cary over in the score codes between levels). And when the player reach the end of the last level, you will substract all of his score and give him score acording his accomplisments. Unfortunatelly there wont be such huge diversity between scores. But still better players will be in the top of scoreboards. Spedruners in the low.... I used similar system in my second RTS (because points are used as money so it would be easy to just wait until you harvest crazy amount of money). I have easy situation because I did not have to transfer it over between levels. But as long as you keep lower amount of trophies, it should be fine.

2011-03-01 11:24:00 Author: Agarwel Posts: 207

---

When you've made a persistent powerup system with so many options that make useful use 40 bits of data to save all the possible combinations, send me a PM if this website still exists, and I'll dig my LBP2 disc out of my attic and put it into my PS12 and let my great grandchildren play it May sound like a lot, but it really isn't very much data, and a friend and I already made a prototype during the beta for a D&D-esque RPG system. The 40 bits were subdivided between the 6 main attributes (Strength, Intelligence, etc.), at 4 bits per attribute (enough combinations to store a value between 3 and 18), and IIRC somewhere in the region of 16 bits to store the player's XP, so (6 * 4) + 16 = 40, and we still hadn't allocated any bits to store the player's inventory, character class, checksums to prevent cheating, etc. In retrospect, we later came up with a better way to apportion the bits, by using reasonable offset ranges from known base values, but it was still kinda limiting. I think if I were to do it for real, I'd pick a far less complex RPG system than D&D, and limit the code length to a number of bits which could be passed between levels (somewhere around 15, which could be done with just a 3-digit code, plus a few more chars for checksum), implement a hub level whose only responsibility is to encode/decode the code, provide an interactive map of the game world, and then pass the information on to the sublevels which each represent one of the locations in the RPG world. The end user experience would be that, in order to restore a previously-created character, they type in a short code at the start of the session in the hub level, and can then freely move between the locations without having to do anything, and once they're done, they can get a new code for next time. Whether they choose to write it down, or just take a photo doesn't really matter much. Given that as the specification for the game, how else could you reasonably achieve it, other that waiting for MM to add in a better system for persistence (which isn't actually as far-fetched as it sounds)?

2011-03-01 17:29:00 Author: Aya042 Posts: 2870

---

Given that as the specification for the game, how else could you reasonably achieve it, other that waiting for MM to add in a better system for persistence (which isn't actually as far-fetched as it sounds)? Hmmmm..... You know something we don't know?

2011-03-01 18:12:00 Author: Shanghaidilly Posts: 153

---

When you've made a persistent powerup system with so many options that make useful use 40 bits of data to save all the possible combinations, send me a PM if this website still exists, and I'll dig my LBP2 disc out of my attic and put it into my PS12 and let my great grandchildren play it Yeah, 40 bits of information is more than anyone could possibly need, right? ...Well, most people won't need 40 bits. But it all depends on what you're making, really. For an RPG, with each character having a level and experience points, some collection of items, and possibly max hit points and max magic points stored separately... 40 bits could be woefully inadequate. For something like "Rockman X" the requirements are more modest: maybe 3 or 4 bits for the number of heart tanks collected, 4 for the armor pieces collected, 8 for the bosses defeated, 3 or 4 for the number of sub-tanks collected, 1 for weapon energy tank collected, 4 for the number of lives remaining and then maybe 1 or 2 bits for the character you're playing (if the level has multiple playable characters like X4 or X7, etc.) - so as little as 23 bits or as many as 27. If it were more like "Rockman 7" the requirements get even smaller: no heart tanks, no armor pieces, only 5 bits required for the number of bosses defeated (since you have to beat one set of four before moving on to the other set of four), no character selection - though there is the "bolt collection" thing (probably another 7 bits) but that could be left out... So 13 bits without the bolt system, 20 bits with it... "Doom"? 7 bits health, 8 bits armor, I think 7 bits for what weapons you've collected - and then 4 types of ammo (it sure is handy that you can load pistol bullets into that minigun!) - that'd hit 40 bits pretty easy. edit: as for entering codes, instead of rotating through hexadecimal or decimal figures to input a code like it's the 80s and we're using gameshark codes, why not use the controller's face and shoulder buttons in place of digits? Much faster for the player to input. That system could work pretty well - though personally I might not go for it just 'cause it doesn't make for an especially easy-to-write-down code. (Even if you give somebody a snapshot camera shot of their save code, they might want to write it down, too...)

2011-03-01 18:16:00 Author: tetsujin Posts: 187

---

Hmmmm..... You know something we don't know? Well, if I knew for certain, I wouldn't be able to tell you, of course. However, I think if MM are serious about making LBP2 a "platform for games", the concept of persistence is kinda fundamental to almost every computer game produced in the last 20+ years, so it's not a completely unreasonable proposition. That system could work pretty well - though personally I might not go for it just 'cause it doesn't make for an especially easy-to-write-down code. (Even if you give somebody a snapshot camera shot of their save code, they might want to write it down, too...) Yeah. I figured a QWERTY keyboard layout with a movable cursor might work best - certainly seems better than cycling through up to 36 different characters, and would seem reasonable to assume that most people would be familiar enough with its layout to use it fairly efficiently.

2011-03-01 18:48:00 Author: Aya042 Posts: 2870

---

Hey all, sorry about my absence, been superbusy perfecting my morphball for the metroid project. My morphball is now complete except for the power bomb addition which I'll get to eventually. The physics are about 98% perfect, as far as meroid physics go, halfpipes are still kinda choppy is all, but much better than original prototype. If you wanna check it out, just visit my planet and play my ONLY level...titled Morphball. Anyways, the stickers won't work. The 40 bits I don't understand, so I would need someone's help/demonstration showing me how it works. Score sensors seem like they would work well, but I'm not familiar with the subtracting terminology all of you are using in your discussion. The reason why stickers won't work is because some items will be hidden and not required to get to progress, such as energy tanks. They would work awesome if everythng was required to get, but that won't be the case. Stickers can't count the amount of energy tanks collected, and while you could make stickers for each individual energy tank...it wouldn't be accurate, since if player has energy tank 3 sticker, but missed energy tank 2 sticker, then the 3 sticker will give them 3 energy tanks when they only collected two. The 40 bits completely confuses me, way over my head. If anyone wishes to help me implement that into the project, I'll give them full credit, but I have no clue how to do it. Score sensors seem most logical besides code, but I will need explanation with subtract 100% thing, because again, I don't understand. For the coding I originally proposed, a keyboard with clicker would be great..I assume it would require a controllinator, but I'm not sure how to create that either. Anyways, I am still looking for help with this particular request. Please let me know if you're willing! Shadow

2011-03-02 16:22:00 Author: Shadow_Wolf_1987 Posts: 108

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.