Jump to content
Double Fine Action Forums

Ritchie.Thai

DFA Backers
  • Content Count

    151
  • Joined

  • Last visited

About Ritchie.Thai

  • Rank
    Noble Psychomaster

Converted

  • URL
    http://dozydagger.com
  1. Mobile's definitely huge these days, and HTML5 provides very powerful tools for working with mobile, and good mobile support is an eventual planned feature, though it's currently low priority compared to more fundamental issues like not walking through tables and just plain getting the game done. Just to give you an idea, HTML5 can do touch support, offline support, game saves, and with some additional tools like PhoneGap, even make the game available on the relevant app stores (though I'd really prefer people just play the web version, which can already have offline support anyway). Furthermore, with responsive web design, the same app can be made to work on devices of any size just by providing proper rules for different screen sizes, adjusting the UI accordingly as opposed to just scaling the whole thing up or down. It's already working on iPad, so the basic touch functionality is there, though I've discovered one of the design complexities of touch devices is the lack of a hover state. It's still possible to play the game though. I'm more a PC gamer myself, but I hear a lot of people saying that they only play games on their phones these days, so it's something I'd really like to get done. Are you interested in giving this engine a go once it's further along? I could bump up the priority of getting this working for mobile. Some image scaling; maybe bigger hit boxes for dialog options, make sure the text is still readable, and I think it's set to go.
  2. I posted about this on Reddit as well, but thought there might be some interest here. This post is copied but slightly modified from the Reddit post. The source: https://github.com/ritthai/changing-heads The game (in development): http://ritchiethai.com/games/changing-heads/ As the title says: I'm developing a Free Software / Open Source JavaScript classic point and click adventure game engine. Rather, I'm developing a game, but it's free software / open source, and I'm making the engine re-usable to the extent that I can. I've already looked for a JavaScript adventure game library framework engine I've found the results disappointing. Of all the links on the first page, only one is actually an adventure game engine, and I find it lacking for a couple reasons. One: It doesn't seem to work. In their demo, I see the start screen, and that's it. Two: After looking through the code, it is written in an old style of JavaScript which pollutes the global namespace, and likely has other practices that are no longer considered best. My main focus right now is just to actually get a game I can be proud of finished, but I'd also be terribly happy if the engine itself took off as something people had an interest in. I intend to write documentation for it later on, but for now there is at least an example of a game implemented in the engine. As I said though, it is in development, and there are many features that I'll need to include before it's ready. For example, right now the character can walk right through walls and tables and whatnot. On the plus side, I've recently gotten some basic touchscreen compatibility; it works on an iPad. Although I plan to write documentation later, here's a bit of an overview now. The "/js/adventure-engine/" directory contains the core engine that is not specific to a single game, while "/js/adventure/" has contains conversations and scenes (or rooms, or pages, or screens) as plain JSON objects. Any game logic needed beyond the basics provided by the static JSON objects can be added through "scene functions". The code is all written to only add a single global variable "adventure", while everything else is implemented through private variables implemented using JavaScript closures to enforce encapsulation. I've also decoupled the modules, taking in the dependencies through the functions used to create them (I'd call them constructors, but technically they're not) which should keep the code maintainable and perhaps unit testable if I ever get around to that. I've got a bit of a developer mode where I can click on the screen to generate JSON for hotspots that I can copy and paste into the code. A word about the game The game is called "Changing Heads". It is meant to be a classic point and click adventure game with no inventory and a focus on conversation and story as opposed to puzzles.
  3. Question about the compression. First thing that comes to my mind hearing the word compression is reducing the file size, but in this case it sounds like it's referring to two things. One is doing things like swizzling and getting textures into the format most suitable for the GPU to make reading the data more efficient, and the other is reducing the file size (which is what I imagine people typically think of) using things like GZIP and the adjacent texels being similar colours trick. That's not the question. My question is, doesn't compression of the type that reduces the file size also require decompression when the asset is initially read before it is sent to the graphics memory? Which is one of the things you try to avoid by not using standard formats like PNG, which would necessitate compression (the read data more efficiently type) before sending it to the graphics memory. I guess the obvious answer would be that there's no benefit to be gained by keeping the texture saved as a PNG, whereas saving the texture as one of these other formats means you can skip things like swizzling, and the file size saved by compressing for space is a worthwhile trade off for having to spend some extra time decompressing, and the decompressing is probably very fast anyway. But isn't memory and storage generally considered cheaper resources than CPU cycles? Or maybe reading that smaller file from disk actually saves enough time that despite requiring decompression, it's still faster overall disk access being as slow as it is. I'm also wondering about how the data is represented on Graphics RAM vs I supposed general RAM (is there a technical term to differentiate it from the Graphics RAM?) vs disk. So on disk it can clearly be represented in whatever file format you like. Once it gets to memory, does the graphics card require a certain representation, or can the way the graphics card reads from the general RAM be programmed? I would imagine that there isn't much choice in the matter of how the image data is represented in the Graphics RAM, and that it has to be in a certain format for the Graphics Card to do its job. Can the Graphics RAM even be directly manipulated? Now that I think of it, everything written never talked about the non-graphics RAM or the disk. So those diagrams of memory layout were for the Graphics RAM. Are these layouts decisions made by Double Fine, or is this an explanation of the decisions the graphic card designers made about the memory layout, which in turn mean it makes sense to store the files in a similar format? Edit: Also, a more practical less low level question. Are there programs/tools/libraries available out there designed to do all this mip-map generating, and sharpening, and chunking, and compression, or is everybody just writing their own? Can we have yours (I ask that in a joking way, though it would be cool if the answer is yes.)?
  4. Ugh, matrices. I knew they were involved in graphics somehow, but I was still surprised to see them pop up here. I was wondering how exactly matrices were getting involved in this graphics nonsense so I looked it up in case anyone doesn't know yet and is interested. http://en.wikipedia.org/wiki/Transformation_matrix#Examples_in_2D_graphics I guess they're probably more fun when it's not all being done by hand or being used to write proofs.
  5. This is interesting. So I figure the key difference between what one might call Flash animation and what one might call skeletal animation is that the parts in a Flash animation can be deformed through scaling, stretching, and skewing, while in the skeletal animation there are only rotations and translations. I also get the idea that the parts in skeletal animation are attached to a skeleton, but I figure while that is used to assist with the animation, most of time time one would want the pieces attached to that skeleton anyway even in a Flash animation, and in other cases there would be ways to get around it. That leaves the scaling, stretching, and skewing as the only difference. I figure that even though it has not been demonstrated, it would not be too difficult to also incorporate this into an engine. Scaling and stretching of textures can be done without too much difficulty (and I suppose I'm uncertain about the skewing), so I don't see why they couldn't just incorporate that into the engine. I'll admit that I'm aware that Flash animation doesn't necessarily use a skeleton and I somewhat combined the terms to emphasize the similarities and ignore the differences, but I don't see why the DFA system couldn't do anything a Flash animation could do.
  6. Yes. Yes it does. The people who aren't a fan of this animation style don't feel great about Rayman Origins either, but they feel it works a bit better there since the characters are at least very simple.
  7. Really? I thought this is exactly what iMuse was preventing. I thought iMuse had an understanding of music composition principles and would automatically create the ending for different points in the musical piece. If this is how they do it, I now fail to see what is so impressive about iMuse. It seems most of the work is done by the music composer. The programmer just has to make the music wait until the right moment at the end of a bar then start playing a different piece of music. I appreciate the work a composer would have to do to make that work, but I thought iMuse was also an impressive feat of programming. Perhaps you've over simplified it now? What's iMuse doing that's so hard from a programming standpoint? I took a look at the videos in your article. You've made the endings sound unimpressive to me now, and while the layering is interesting from a music and design perspective, it also sounds pretty easy to do for a programmer. The only impressive thing left is the seamless transitions. Are they just done the same way as the endings with many different transitional pieces written? All of these are things I suggested in my big long post above, and they seem to me like things we can still do without using MIDI. I don't want to discredit the programmer too much. It would still actually take work to implement all this, and including information about bars and the correct endings and transitions to use and when to use them, but I thought there was more. I thought iMuse understood something about music composition. Why can't we do this with non-MIDI music? I know for a fact that the layer can still be done because as I wrote in my post it's been used. And is there more to iMuse you're not saying that will impress me again?
  8. We Can Make Our Own Like System This gives me an idea. We don't necessarily need Double Fine to implement it for us. I or someone else could write this up. These forums are private, but that won't be a problem. I could write a GreaseMonkey script which adds a like button to each post makes a request to my server when a like button is clicked. While the forums are private, I could still easily have a mySQL database on my site with a table having the columns be post_id (from the permalink), and like_count. When the page is loaded, an iframe could be included on each post with a page from my server displaying the number of likes for that post. Even better would be if just had all the likes for that thread on one page on my server and displayed the likes using AJAX instead of an iframe, but I'm not clear on how cross domain AJAX requests work, or whether they are allowed at all. Problems Of course this would be nowhere near ideal. Anyone who wanted to like things would have to find out about my script and add it, learning how to add GreaseMonkey to their browser being part of that. It would be a very unofficial sort of thing, and if multiple people decided to implement something like this the users could become fragmented. If it were hosted on my server, you would also all have to trust me to not take advantage of my powers tamper with likes and dislikes. I also just realised that I would need to record not just the number of likes, but the people who did the liking, because otherwise someone could like multiple times. This means that while I could make the likes anonymous when displayed on the thread, I would be able to see who liked in my database. The only solution I can think of at the moment is to hash the usernames before the request to my server is made, but while unlikely if I use a very good hash function, there is still the possibility of collisions where user A and user B's usernames have the same hash and therefore when user A likes, user B is no longer able to also like. Furthermore, I might be too lazy to include the hashing. Or the likes could just be considered not anonymous like on Facebook. That would work. I Can Do It Making something like this would be no problem, as far as I can see. If you guys think it's a good idea I could do it. Someone else could do it too, but if you don't give me credit for the idea I'll be sad. I'll also be sad even if you give me credit because I still won't get credit for actually making it, nor would I have the experience of actually making it. I can't start work on it until the weekend though. The only lingering issue is that I'm not sure how my web hosting provider (I'm not cool enough to actually run my own server) would feel about all this. Anything on my web host needs to actually be part of my website. I guess the solution to that is to actually add a part of my website that allows you to view likes and dislikes on the double fine forums. Wait. Maybe Not. I Can't Authenticate. Unless... Hold it! Crap. I just realized I have no way to authenticate users. Well. This was... embarrassing. Unless... I've got it. Instead of sending the request to my server when a like is made, likes could be done through either a private message to a Double Fine account or a post in a Double Fine thread. Even More Problems That raises new issues. If private messages are used, my server would need to somehow log into Double Fine forums, parse the messages, and also delete them so that the account doesn't run out of space. I actually don't know how I'd do this using just my web host. Maybe I could do it using Lynx on a unix machine, but I don't have that much power when it comes to my web host's server. It's logging in that's the problem. Maybe it's possible. I've never investigated logging in. If it's done in a thread it's much more viable. In fact, we could even use the existing polling feature to make things anonymous. This is probably a bad idea too though. If it were used, there would constantly be a thread with no interesting content in some subforum, and it would always be on the first page near the top if this got popular. It might be worse if polls were used. Can polls be edited? If the can't be, we would need probably at least a second thread for each thread which has a like in it, and then multiple poll threads per thread if the number of posts in the thread being liked grows too much. Conclusions. One Workable Idea. Probably Not Happening. I hope someone at least finds this interesting. Maybe someone has a better idea. The private message idea still seems viable, but it doesn't seem worth my time. Maybe on a rainy hacking day, but it's probably just a pipe dream.
  9. Dialog Trees What you described is something I considered, but I always hesitated because it lacks some flexibility that I might've wanted. One thing is including variables in the dialogue like, "I see you've found [sheepFound] sheep. Just [totalSheep - sheepFound] to go!" or "I saw you at [placeSeen]. The food there's [descriptionOfFood], [if isFoodGood != isViewGood, "but", else, "and"] the view is [descriptionOfView]." But realistically I suppose I'd never bother with anything as fancy as the second example. How about conditionals in the dialog tree like certain options becoming available or unavailable, or the same dialog option having different responses depending on what's been happening? How about if I want part of the response to a dialogue option to always be the same, but the second half to change? Something like "Hello, welcome to Seafood Nirvana! We have a selection of fresh seafood cooked by only the best chefs. [if heard rumour about cooking skills "Not that someone of your skill needs someone else cooking for you."] [if heard rumour about the fish event "Please just eat the fish. We don't want you scaring away the other customers"]. The biggest issue I see is how conditionals in the dialogue tree would be handled. If you're just checking whether a list of events have happened then certain branches just need an array. If you want more complicated conditionals though with either complicated nested boolean logic or numerical comparisons it gets more complicated. Including variables in the dialogue might not be so hard, though you'd have to decide exactly how to do it. Maybe all variables are surrounded by square brackets, but then you need to give a way to escape square brackets. You'd need to do some string parsing too. None of this is necessarily hard or a problem, but it's work you'd have to do. Or maybe you just use an array whose elements can either be strings or keys for a variable in a map, and and the end it all get concatenated. But maybe I just worry too much. Most of the time the type of dialogue tree you describe would be enough. Maybe nodes of the tree could have the option of basically passing control of the conversation over to incidental code for those special situations, and the incidental code could pass control of the conversation back to the dialogue tree once it's done. That's not how I used storyEvents. storyEvents is a map with strings for the keys, and soft typed values. JavaScript and ActionScript, which are both actually types of ECMAScript, don't require you to specify the type of a variable so I could use a map which stores strings in some elements, booleans in others, and then again numbers in others or anything else including even another map as an element of a map. In Java, I used a map with strings for keys and strings for values because strings are the most flexible. They are descriptive, and if I needed a boolean, integer, or double, I could write "true", "42", "3.14". I wasn't too concerned about efficiency as I wasn't doing anything too intense, but I also considered using enums or constants instead of strings if I needed descriptive qualitative values, and I considered having multiple maps like textStoryEvents, booleanStoryEvents, integerStoryEvents, realNumberStoryEvents. It was a while ago and I can't remember clearly, but I might've actually included a numberStoryEvents and textStoryEvents map. It's confusing, because I mentioned my GameObject class which also had a map, and there I definitely included both a textValues map and a numberStoryEventMap. I didn't want too many maps for all the different types because it made the generic GameObject too complicated when most objects probably wouldn't have that many different values. I included the number map because I think I made health a value. I didn't want health to be an instance variable because many game objects wouldn't have health. In retrospect, it might've been smarter to implement an interface which included health accessors and mutators. I had regenerating health which increased a bit each frame, and when health was a string, the string to double to string conversion every frame was killing performance. I also considered using a more generic map with string keys and Object values. In Java, Object is a parent of every class, so that map could store anything other than primatives, and even then primatives can be wrapped in classes like Integer and Double. For some reason, maybe because of a bug and not an actual problem with the idea, this was also slow. I also didn't like the idea of being able to store any type of object in this map when I really only wanted simple qualitative and quantitative values. For storyEvents, I might've just used strings since I probably wasn't checking them every frame, or I might've included numbers for consistency. The act method game objects had could've been implemented better. When you mentioned the "can I do it smarter" moment, I thought you'd call me out on the act method, not the if statements. Like I said, I didn't have performance concerns, but I could've probably done that part in a smarter way. A lot of game objects like doors basically had an empty act method, but they were still game objects and had to be looped through, and they just did nothing. Or maybe there are cats that start running toward you when you take out the fish, but the rest of the time they do nothing. I think I could've included a list of all the game objects, and a second list of game objects that are actually doing something. The cat example illustrates a situation where it might be more complicated though. How do I add the cats to the list of game objects doing something when the milk is taken out? I could put that as a check the milk does when it's taken out, or something the player character does since he's taking the milk out, but it seems like that should really be the cat's job. What I probably need there is an observer pattern, where all the cats add themselves to a list in milk of milk's observers, and milk has to call a function of milk like actOnEvent, where the cats would do a check to see if the milk has been taken out then add themselves to the list of acting game objects. So I guess it's not a problem I don't know how to solve, but it's all this extra design work and programming work that really wasn't necessary. I also figured making every object act all the time was justifiable because having the cats remain inactive for now might speed things up, but at some point they're going to be moving anyway, and being more efficient now doesn't matter if it lags then. Room Sensitive Player Character In a game I made that was more specifically adventure instead of action, I think I made it so that the act method of the player character actually changed from room to room. I could've included context sensitive code in the room specific objects, but I just found it more convenient to code it from the player's perspective instead, so there's something else to consider.
  10. Nobody's brought this up so far. I'm unsure of how to think about the question. In another thread someone asked what voice actors people would like to see in the game, and while a lot of suggestions were famous voice actors, there was also the opinion that Double Fine should just use any voice actor that sounds good, not necessarily famous expensive ones, and save resources that could be spent making the rest of the game better. I don't see any reason anybody would not want an iMuse style system to be used if we're just making a wishlist where we magically get anything we want, but from a practical standpoint, I'm not sure the difference in the experience would be worth the time and effort implementing such a system. But I'm not sure what you meant in the poll. Making a wishlist without considering real life constraints is something worth doing just to get an idea of whether people want something at all. While I personally think the answer is too obvious here, I could understand asking if people want a hint system, disregarding the extra work it would take to implement one. So my answer is yes if we're just making a wishlist, not sure if we're considering the time to implement it, and the poll answer I actually picked was "I don't care!", which doesn't at all properly represent how I feel. Now I'm going to talk about how music is used in games these days. SurplusGamer has mentioned that the soundtrack could be much more interactive and dynamic in this interactive medium than what is usually done. I'm not sure how much a player would actually notice and appreciate it, but it would definitely enhance the experience to some extent. A game which did something interesting with its music is Closure, the Flash game. I haven't played the non Flash release. The song had different tracks which were added or removed depending on which level of the game the player was in, and they all harmonically worked together. I could imagine an action game having 2 songs, one for when the player is just walking around and one for when an enemy is encountered. The 2 songs would be synchronized and perhaps have a counterpoint relation or something like that so that at any time the game could switch from one song to another and it would be somewhat smooth. A simple example of this might be to have all the same notes, but one version played on violins and piano legato (or is that just a piano term), then a second version with drums, brass, pizzicato violins, more staccato with the piano. Something like that. While this might take some effort on the composer's part, I figure any person who writes scores is probably already comfortable writing variations on a theme anyway, and the transition I imagine would be much easier for the programmers to do. Another idea that would probably be a lot more work for the composer but less work for the programmer would be for the composer to write an ending for the song every 4 bars. Basically a person doing the work of iMuse manually. If the song is short or the different parts or similar enough or repetitive enough so that the same ending could be used, this might actually be practical. Another idea might be to take a more DJing sort of approach to transitions, whereas I think iMuse is more often about playing the role of a composer or improvising musician forced to suddenly end the song. DJs use cross fades, but synchronizing the tempo is another aspect, playing 2 songs at the same time and making sure those songs actually work together when played simultaneously, perhaps changing the pitch of a song so that they are in the same key, using filters to maybe include only the bass of one song and whatever you call the middle registers of another song or the treble or something. I'm not a DJ. A game could also use music sort of like sound effects, such the strings playing a sudden short loud note when an enemy is hit (I suspect there's a technical term for that but I'm not sure what it is. Maybe an accent?), or playing pizzicato when for example you have 2 swords clashing and they're pushing back and forth against each other. Admittedly that seems more suited for an action game, and I'm not sure what sort of applications it would have in an adventure game. Superbrothers: Sword and Sworcery sort of does this though in a different way. Musical sounds are used like sound effects, but they're for what I consider the player interacting with the user interface as opposed to things happening in the actual game world. I also think games could also start going more beyond playing music depending on which area the player is in. Perhaps music could play depending more on events in the story than where the player is. I think I'm simplifying it though, and figuring out a way to do music like that might not be so simple. Spore did some pretty interesting things with procedural music. I'm done. I'm out of ideas.
  11. I've run into the same design problem working on games, and I'll suggest some of the ways I've done things. I've always assumed that creating puzzles would require coding of some sort, whether in a scripting language or the same language as the engine. For JavaScript, ActionScript, and PHP games, I've stuck with the same language since JS and PHP are already basically scripting languages while with ActionScript I don't think I would be able to easily use a scripting language without writing it on my own in ActionScript. In a Java game I never finished, I could've used a scripting language and considered using JavaScript for a while, but I eventually decided it wasn't worth the trouble for what I was creating. Usually I'll have some sort of map called something like storyEvents. The key would be a string, and in soft typed languages like JavaScript the value could be anything, and for Java I'd probably just use string. For any sort of interaction I would write code with an if statement checking story events. A problem with that system is that every story event's key is basically using the same namespace, so I'd have to be careful to always use different unique names. A better idea might be to split them up into quests, or perhaps split them up by area. I would also often have some sort of GameObject or GameActor or just Actor class for any sort of thing in the game like a table or a person. I'd loop through all the game objects, and they would have an act function that is called every frame where I could include some game logic like if I am colliding with the player, show this dialog or play this animation or make this sound. Each game object would also have its own string string map and string double map to store relevant values. I used these maps instead of just adding more object variables to reduce dependencies between objects and to make a clear distinction between variables used by the game engine objects like the image to use versus variables more directly related to the game world like isFlammable. I'm not sure about this decision, and maybe it would've been better to just have a lot of dependencies, but that was the reasoning. So another option for storing the current state of the puzzles would be to store values with respect to objects instead of a quest, area, or just having everything in one global namespace. Now I'm going to make a suggestion that I haven't tried before but that I've considered. I think most of the time you could get away with storing nothing but booleans. I find that numbers very rarely play a game in adventure game puzzles. If you're trying to drug a dog, you could use something like isMeatInDish, isTranquilizerInMeat. Even if you need numbers, assuming you don't have too many you can use something like has1Apple, has2Apples, has3Apples, or maybe hasApple1, hasApple2, hasApple3. Of course, if you know your game will be number heavy you might as well explicitly include numbers, but if it's rare, this isn't so bad. Now that you've only got booleans, you can simplify things to just use boolean logic. You might even be able to simplify the boolean logic to only have something of the form: if (isA && isB && ... && isN) { do something } else if (isC && isD && ...) { do something else } My point is that you could just include an array of the relevant boolean keys which will all just be anded together, and have an array of these arrays to form an if else structure. You'd still need a way to do something and do something else though, but perhaps you could generalize those do somethings as only changing the values of booleans, displaying some dialog, and playing an animation or scene. You could just include an array of pairs of keys and values for, a pointer to some sort of dialog tree object, and a pointer to some sort of object specifying an animation or scene. Figuring out how to structure a dialog tree is tricky too though, and I've never created any sort of code or structure for that. Any dialog has been written in code with if statements everywhere. Another thing I've tried that's even simpler than what I just described is creating a system similar to what is used in the game Echo Bazaar. I don't know exactly how the game works, but I've created my own version of it. The game has different locations. Each location at any time has a list of actions that can be performed. The player also has a list of values which have numerical values associated with them, so basically a string to integer map. Whether the player can perform a given action is determined based on the numerical values just using less than or greater than operators. So you'd have a list of triplets for each event indicating the values, whether the operator is greater than, less than, or equals, and the number against which the value is compared. Once the player selects an action there's also a Dungeons and Dragons style skill check, but I don't think that's relevant to adventure games. Well, I hope this has helped, and I'm interested in seeing if anybody else has suggestions talking about how they've done things that might make more sense than what I've suggested here.
  12. I know for a fact that they were. I don't know why you could say something like that without providing some evidence or arguments. How do you know? I tried looking into it myself, but I'm not convinced either way yet about whether they were done pixel by pixel. I'm interested in hearing from you what the differences are between how traditional animation is being done in games compared to television. I've seen all the posts you made on Programming Update #4 as well, and you mentioned that Skullgirls was animated by T.V. animators so I've looked that up too. BlazBlue Animation Process Edit: Well said, DOUGLAS. I took a while writing my response and didn't see yours. I do have some reason to believe Frogacuda might be right after looking at some images, but I'd like to see what Frogacuda has to say.
  13. I don't think that's true. I think skeletal animation can be good (the reason I made the thread), but here's a list of somewhat recent games using traditional animation. Games praised for their use of traditional animation: Skullgirls, Blazblue, The Whispered World T.V. resolution games using traditional animation: Disgaea 4, Braid Low resolution games using traditional animation: Castlevania: Order of Ecclesia, Kirby Mass Attack The praised games make traditional animation seem like a special exception in video games, and they do have particularly good animation, but there are other games that just use traditional animation without much fuss being made. The lower resolution games use traditional animation in a way reminiscent of animation from 8-bit and 16-bit games. It's less common, but I think traditional animation still has a fair presence.
  14. What you say is fair. If you don't like it, then you don't like it. But when you say "Yeah, we get it," I suspect there are people who saw the pre-visualisation and don't realize skeletal animation can look much better than that. I don't think they get it. I'm sure there are also people like you who get it, but I think those who don't might feel better after seeing this. Then if things go well, we get to the awkward situation where the majority of people are happy with the animation, but a portion of people are left unsatisfied. If things go bad, the majority are unsatisfied and Double Fine cries itself to sleep. If you're still around, I mentioned that real episodes of My Little Pony similarly do a mix of frame by frame and cutouts, though I suspect the amount of frame by frame is far greater than what's used in this fan animation. Any opinions on the official cartoon's animation that you wouldn't mind sharing?
  15. Holy crap, you're using Game Maker Language (GML)? I was going to give you all this flak about how this code is nonsense whether it's C, C++, JavaScript, or Java which seem like all the things it could be with a casual glance, and I was guessing C or C++ since camel case is preferred in the other options. The irandom_range gave it away. Game Maker Language is the only thing that uses it. It looks like the syntax is correct, and I'm not familiar enough with GML, but there are still some things that bother me. Why is placeholder_insult() returning what is presumably a boolean? It looks like GML has some annoying naming conventions, but even if you don't use something like is_using_placeholder_insult() which might be a bit wordy, how about something like placeholder_insult_check()? myinsult should probably be my_insult. I'm unsure about this next point because I don't use GML, but why are you just assigning an integer to myinsult now? Don't you need to use that number to index into an array of insults and use draw_text again to actually say it? None of those are big problems though. If this weren't GML, you'd have some serious syntax problems, but this is GML. I just felt the need to write something after having to erase my whole other post. Good comic.
×
×
  • Create New...