Jump to content
Double Fine Action Forums

Ryukaki

Members
  • Content Count

    11
  • Joined

  • Last visited

About Ryukaki

  • Rank
    Action Newbie

Converted

  • URL
    http://ryukaki.com
  1. Okay, so, uvRect did fix the issue with the black bar being drawn when you hack the object. Changing it very slightly eliminated that problem. It was helpful! The variables that are invoked to fix this problem are actually pretty simple. hitboxTracks = { body = { { duration = 0, frame = 1, rect = { 22.5, 64, 160.5, 188 }, }, }, }, jointTracks = { }, pivot = { 160.5, 0 }, soundCueTracks = { }, }, This is where all of the magic takes place, really. "Pivot" is an offset from the 0,0 coords where the info pulled from the uv map is placed. Adjusting the UV map actually causes stretching/tearing with any major changes, so fixing it there didn't seem to be a good way of doing it. However, the hitbox, and with it the associated sprite, can be moved by adjusting rect= in the hitbox tracks. These values are additional offsets from 0 which define a rectangle, simple as that. Using a combination of the Pivot and Hitbox Track, as well as modifying the origin point of the objects, I cleaned up the two objects and now the room is sparkly clean. These two files fix every issue with the Glyph Room layout: http://ryukaki.com/HackNSlash/GlyphRoom.spritesheet http://ryukaki.com/HackNSlash/GlyphRoom.layout Feel free to diff those against your current ones to see exactly what I changed and where, it takes a bit of fiddling to get used to what each of the values do, but I'm writing up documentation for myself so that I can come back to it in the future \o/ Thanks for your input on the matter, Smash! Getting back in and digging around finally provided some workable results, and now I get how all of the object placement works. It's very, very clear that the guys at DoubleFine use a tool for placing objects in-level, and do not do it by hand. It's very clumsy to do that way x.x
  2. The problem isn't a graphics issue, though. The graphics in the file are just fine. These are the areas defined by the "rect" variable in the spritesheet file (roughly, this is not exact, but it's close.) http://i.imgur.com/uf6ld7C.png If you assume the bottom-left of each rectangle to be the 0 coord (the point where the game starts drawing the sprite into the game world from the origin point of the actual placement of the object in the layout file) then you see these exact offsets are being applied in-game. This is what is happening in-game: http://imgur.com/qkYtZet There are further offsets to these placements because of the variable "pivot" which offsets the sprites by a number of pixels from the origin point. Because those are the areas defined by the spritesheet. (The values in "rect" represent pixel-points on the spritesheet and form a rectangle over that area.) My understanding is that the values in "rect" are just not set correctly-- even if it were the case that it only controls the draw area, I could modify the values in the spritesheet and fix the issue, but modifying the values in "rect" don't do ANYTHING. At all. No matter how much I change them. I've checked every single other avenue, lua file, etc. on this one, and the only place I can find a discrepancy is how they're being accessed through the spritesheet :\
  3. So, there's a problem with the GlyphRoom spritesheet. ['Port 1'] = { dimensions = { 321, 246 }, eventTracks = { }, frames = { { colorRect = { 0, 0, 321, 246 }, imageIndex = 1, rect = { 0, 1698, 321, 1744 }, size = { 321, 246 }, uvRect = { 0, 0.8291015625, 0.15673828125, 0.94921875 }, }, }, hitboxTracks = { body = { { duration = 0, frame = 1, rect = { 22.5, 64, 160.5, 188 }, }, }, }, jointTracks = { }, pivot = { 160.5, 0 }, soundCueTracks = { }, }, ['Port 2'] = { dimensions = { 370, 474 }, eventTracks = { }, frames = { { colorRect = { 0, 0, 370, 474 }, imageIndex = 1, rect = { 0, 1220, -370, 1694 }, size = { 370, 474 }, uvRect = { 0, 0.595703125, 0.1806640625, 0.8271484375 }, }, }, hitboxTracks = { body = { { duration = 0, frame = 1, rect = { -160, 290, -31, 406 }, }, }, }, jointTracks = { }, pivot = { 185, 0 }, soundCueTracks = { }, }, Specifically, the issue is that the "rect" defining these two ports are grossly mis-aligned with what they should be, and due to this, there is some graphical artifacting and vfx playing incorrectly when you attempt to hack these blocks. (These are Port U and Port V for aligning the text offsets.) The rectangles defined here, include very large areas of the spritesheet where there is only the transparency layer, and along with this, whoever set up the level used a silly hack to make the room work, specifically, { dir = 5, loc = { 716, 174 }, name = 'Port 2', path = 'Content/Game/DweebKeep/Entities/GlyphRoom/Port', }, { dir = 5, loc = { 745.5, 172 }, name = 'Port 1', path = 'Content/Game/DweebKeep/Entities/GlyphRoom/Port', }, This line here, sets the origin points for these two ports erroneously at the bottom of the map: http://cloud-3.steampowered.com/ugc/433783980817770738/6674484A5B85CAF646234A5DB377F5FF0F39CC9B/ You can see their origin points are right next to Alice, but the actual blocks collision/sprite components are located where they are intended. This causes the following effect: http://cloud-3.steampowered.com/ugc/433783980817811321/6660F976AB7082AB375C9A6E15A00708E942646C/ As you can see, the "hack" sparkles are located at the bottom of the screen, where the actual origin point of this sprite is, rather than on the object being hacked. Additionally, there is a large black bar cutting across the screen which is the "top" of the rectangle defined above, accidentally cutting into the black chunk which is above this sprite area on the spritesheet. Using the following coordinates for the origin points: { dir = 5, loc = { 618, 531 }, name = 'Port 2', path = 'Content/Game/DweebKeep/Entities/GlyphRoom/Port', }, { dir = 5, loc = { 846, 310 }, name = 'Port 1', path = 'Content/Game/DweebKeep/Entities/GlyphRoom/Port', }, Puts the origin points for these sprites in the correct place, but because of the rectangles defined in the spritesheet, this offsets the sprites by a large amount: http://cloud-2.steampowered.com/ugc/433783980817859246/F26273C5F30DB3DE6869A5CAF37A006D5732E864/ So, after all of my yammering about HOW this setup is broken, I'm actually writing this all to inquire about why making edits to the "Rect" component of the spritesheet entries seems to yield no changes at all in-game. Is there somewhere else I'm supposed to go to edit what sections of the spritesheet are reserved for specific sprites? I feel like I'm missing something simple here, again. Perhaps this is just broken right now and is also in need of fixing? I'm just not sure. I've tried fiddling with every component I can think of, but have come up dry. Thanks a bunch for your time!
  4. It's my intention to maybe possibly be of some use to the guys over at Doublefine, mostly out of interest in learning more about applied Lua, but also because I think this project is really something special. Figured a good way to go about it was to be able to find and offer fixes to bugs, instead of just finding them. Thanks for the link, I'll have a look at it!
  5. Should be a known issue. It's on my bug list, anyways. If you're outside a cell and the orbit of Bob happens to pass over the trigger volume inside the cell, it'll close and lock the doors and trigger the whole "locked in" event, locking you out of the cage. Pretty neat, actually. The approach I will probably be taking is just to dig in and figure out how the game decides who can trigger a trigger volume, and find a method of preventing the function call unless Alive is the invoker. I'm not 100% familiar with how all of their stuff works yet, so I've got a lot more research to do, dun dun dun. Probably also need a separate function for handling if Bob needs to trigger something, though I haven't seen any instances where that's true. I've cleaned up a bunch of other bugs, though, and had a lot of fun doing it. Making it a pet project to clean up all of the bugs on my buglist and making the lua edits available, and hopefully I'll understand enough of this stuff to make my own levels/puzzles soon enough, most of it's really not actually that hard to work with, even without tools. Thanks a bunch for the feedback!
  6. So, there is a known bug in the game where you can sometimes get locked out of the cages in the CodePuzzle rooms. It turns out, this issue stems from the fact that for some reason, Bob is counted as a trigger point for interaction with trigger lines/volumes, and his orbit can occasionally bump into the trigger volume inside the cage upon approach and lock you out! I've been searching around in the lua for an easy way to fix this problem, and so far, haven't really been able to determine what it is that decides that Bob is an extension of the player's hitbox. It occurs to me upon searching, that maybe these trigger volumes don't care what invokes them, so I tested it, and I'm right. Bob can trigger ANY of the trigger volumes in the game. However, I can't seem to locate a non-arbitrary method of identifying between the player and bob as a callable argument. There are plenty of ways to do it arbitrarily, but I am having trouble finding a non-arbitrary one. By arbitrary, I mean I can search for, for instance, Bob's name, and check it against the player name, and then NOT trigger the volume if it finds Bob's name, but do if it finds the player's. Or I could search for a certain sprite, and only trigger it if I find Alice's sprite, rather than Bob's. But these are arbitrary! Is there a function I can pass as an argument to an if statement that will cleanly identify between Bob and Alice that is NOT arbitrary, or am I missing something super simple? In the long run, though, this probably requires a deeper fix that stops letting the attached sprite trigger volumes. Thanks to anyone if you can help out!
  7. First off, thanks for the feedback! I appreciate your time and your criticisms both. In general, the idea was to focus on the puzzles and game experience, there were things that got missed that are probably worth going back over, even just re-visiting the document now. In part, I do actually take sides because the exercise was partially feedback, as well as analysis-- kind of hand in hand, wanted to provide my opinion and my observation, because they asked for it! I've been studying (And working in) game design for a good deal of time, now, and player experience is kind of a central focus of that; how is the player going to be impacted by this decision or that choice. The infinite health thing was just a point in particular where it felt to me that opportunity was lost with little gain. That said, I might have made it more clear that either choice, to have it be a defining characteristic or not, is actually a fine choice, just that the current design of the game seems divided on whether or not tension-by-threat should be a device for leveraging an experience out of the player. I think we may agree on that part, because it's very clear, even if it's not terribly objective. (If the game did not have moments where it seems like the player should be paying attention to their health, the infinite health thing would be absolutely excellent-- it does provide very positive learning and experience in the context of a strictly puzzle-based game.) I will have a look at that bit of literature. I've read through a couple of books on the subject of design already, but have not come across that one. (A book of Lenses, The art of Game Design. Few others.) It would probably be a good experiment on my part to try and do a wholy objective analysis in addition to having notes laying about in another area, might assist in clarity as well. Some formatting issues arose with trying to make the documents web-friendly, but I could probably clean them up and make it into some other filetype without losing much. Thanks again for your feedback!
  8. Links fixed! Sorry, Double Fine's forums actually parse html code so my % 20 became a space and broke the links!
  9. I put this on the Steam Forums, but I figured I would share it here, too. So, what is contained within is part labour of love, part of a personal exercise in testing my own design analysis skills, part walkthrough, and part giant suggestion document. It's really big, but I've done my best to make it legible and enjoyable to read, and was a few nights up late well spent, I think. Without further Ado, Ryukaki's Hack 'n Slash Design Analysis Document. http://ryukaki.com/HackNSlash/HacknSlashDesignAnalysis.docx http://ryukaki.com/HackNSlash/HacknSlashDesignAnalysis.rtf I'm more than happy to receive criticism or feedback from anyone willing to brave it, and hopefully this can open some discussion about some of the less clear elements of the game from everyone. Thanks again for an amazing game, DoubleFine
×
×
  • Create New...