|
Appropriate mouse capture behavior in windowed games depends on how the game uses the mouse. If the mouse controls a cursor that moves around as normal, then the window should not capture it, because it's expected that the cursor should be able to move beyond the boundaries of the window. (An exception would be if the controls rely on having the cursor "stick" at the edges of the window, a UI paradigm that would be more appropriate to a fullscreen-only game.) If the mouse controls a UI element that doesn't function like an ordinary cursor - the crosshairs in an FPS, for instance, or the camera, or directly influencing some game element - then the window should capture the mouse, because the player doesn't expect that gameplay element to be able to function outside of the game. If you've got a cursor while in menus and some other reason for having a mouse at other times, then capture the mouse when you close the menu and release it when you open it.
|
#
¿
Sep 18, 2012 20:43
|
|
|
|
| # ¿ Apr 19, 2024 16:53 |
|
|
Mug posted:I'm pretty sure I can do this, so I will. As a rule of thumb, make sure it never takes more than a single keystroke to release the mouse even if you do ever capture it. One feature of the Steam overlay is adding this behavior to all compatible games run in windowed (or, if you've got multiple displays, even fullscreen) mode.
|
|
#
¿
Sep 18, 2012 23:41
|
|
|
Mug posted:Hitting escape will bring up an overlay menu with real, uncaptured mouse that you can move anywhere. Would that be fine? This is how most games do it, in fact. If all of them did, the world would be a better place. Just make sure that menu can be brought up at any time, possibly excepting loading screens (maybe release the mouse during loading screens if they're long enough for it to matter).
|
|
#
¿
Sep 19, 2012 00:00
|
|
|
1: a ninja 2: a man is haunted by ghosts 3: the green option "A" is not selected 4: the green option "A" is selected 5: the blue option "A" is not selected 6: a ninja is reading over a man's shoulder 7: a ninja is stabbing a man 8: a mommy ninja and a baby ninja 9: a music note
|
|
#
¿
Oct 15, 2012 11:55
|
|
|
Oh, I missed the third one. That's "a crowd."
|
|
#
¿
Oct 15, 2012 11:59
|
|
|
Svampson posted:So I got myself one of them mac computers so I can make iOS games and stuff, so I started messing around with Futile about a week ago and it's so much fun to use This looks very cool. Did the pinch zooming come "free" from Futile or did you implement it manually?
|
|
#
¿
Mar 19, 2013 07:16
|
|
|
Unlimited saving is good from an accessibility standpoint. Unlimited loading risks the player coming to feel reliant on unfun degenerate strategies. (Permitting loading only from saves made at a save point is a kind of limit on loading.)
|
|
#
¿
Mar 21, 2013 03:02
|
|
|
Player behavior tends to gravitate towards the most effective strategies that they have already used, regardless of whether other strategies are more fun or even exist. (That's not strictly true. They'll do things that they know will produce feedback, and visible progress toward victory is the strongest feedback available. But it holds true in most cases.) As a game designer, your job is to make the player comfortable with the intentionally fun styles of play, even if you have to trick them. If there's a way to win your game that's easier but less fun than what you've got in mind, then you can bet there will be people out there who'll discover it, use it to the exclusion of all other strategies, and then complain that your game is boring. They will take your coloring book, color outside the lines, and then blame you for the ugliness of the result. You don't have to make it impossible to play wrong - after all, it's fun to break the rules every now and then - but giving some indication that it doesn't count can curb the worst of it.
|
|
#
¿
Mar 21, 2013 04:40
|
|
|
Gromit posted:Both of these "issues" are just players wanting to play your game how they want to play it. Their preferred method is not "wrong" - it's how they want to enjoy what they paid for. The most common use case for a game involves a player who does not know enough about it to properly decide the way they want to play. Most games are pedagogical experiences - playing the game and learning how to play are integrated into the same process. Making abuse impossible is rarely the best way to discourage it from happening, partly because there are players like you who know better than to ruin it for themselves, and partly because a heavy-handed "fix" like that only appears necessary when some other aspect of the game, which may subsequently go uncorrected, is incentivizing degenerate play.
|
|
#
¿
Mar 21, 2013 22:45
|
|
|
First of all, you need to decide what kind of data is going to be in your map. What's going to be stored in an individual hex? From the looks of it, you've got uniform empty hexes, which can be occupied by a single star-like object. In that case, I'd recommend a dictionary, with a Vector2 (or Point2D, or your own hand-rolled dumb coordinate struct, or whatever) as the keys, and any coordinate pair that is not a key in the dictionary is assumed to be empty. This will give you very good random access performance, and it will map easily to a relational database, with all the potential advantages those entail if you're willing to include SQLite or some such thing in it. On the other hand, if a significant fraction of your hexes are not empty, and you've got lots of them containing data that's not unique - say, indicating one hex as "safe" and one as "dangerous" - then you'll want to use a quadtree. (If you were working in three dimensions, it'd be an octree instead.) You're representing the whole map as a tree, where each stem node has four children and knows its own center point, while only the leaf nodes have data. The whole map is the root, and you divide it into quadrants, each as one child node from the root. Divide each node recursively, until reaching a section where all the hexes in it are the same (all empty or whatever) - all those hexes will be represented by a single leaf node. To look up any given coordinate, you simply descend the tree recursively according to which child node the coordinate falls in, until you reach a leaf node; it won't be very deep, so performance is good (though in the worst case, a very unorderly high-entropy map, like television static, it will end up being worse than just a huge 2D array). Combining these approaches is what large dynamically-generated worlds do; it generates one "chunk" at a time as needed, and that chunk is represented by an octree or quadtree. At different times in the process of dealing with the map, you might find that one of these structures is more useful than others. In fact you'll probably find that you want both at the same time. Represent the relatively information-poor terrain as a tree, and the information-rich objects located therein as a dictionary. They don't even have to use the same coordinate system! Bongo Bill fucked around with this message at 03:02 on Mar 30, 2013 |
|
#
¿
Mar 30, 2013 02:56
|
|
|
The real quality of this kind of RPG is in the interactions between its subsystems. Let each one be a feedback loop with a different radius - progress in one should open up possibilities in others. Having separate systems for party composition and character advancement is fine, but you've got to design how those systems interact and what considerations those interactions force on the player. If they're completely isolated, then you might as well just have one or the other.
|
|
#
¿
May 27, 2013 03:52
|
|
|
TJChap2840 posted:Also, what is the "clean" way for adding a large amount of a class of things to a game? In my piddling around, I have been using a inheritance (Tile Class > Grass Tile > Overgrown Grass Tile > etc), but I know that will get out of control quickly. Lots of complex games use an entity-component system. Google can direct you to more in-depth literature about this paradigm, but I can give you a brief overview. Unity uses it by default. ECS is very different from object-oriented design. In OOP, the type of an object - and its ancestor types, to which it can be coerced - are used to describe some of what that object is to be used for. Programming courses often emphasize as a core principle the difference between inheritance ("is-a") and composition ("has-a") relationships, the former of which is a defining principle of conventional OOP. ECS, on the other hand, uses only composition; it's driven entirely (or almost entirely - you can mix paradigms) by data. Everything in the simulation - every enemy, every projectile, every discrete part of the environment, all the data about the player, even the UI widgets and abstracted controllers - are Entities. Entities are distinguished from each other not by what kind of entity they are, but by what data they have. A bullet, for instance, would have X and Y coordinates, a hitbox, a graphic, a sound effect, maybe a countdown to its expiration or some data about how much damage it would do. Each piece of data about an Entity is called a Component, and an Entity is literally nothing more than an ID (you can even do without the ID, but it makes debugging much easier) and a collection of Components - and, crucially, only the components it needs. Your entire game state - not necessarily the state of the program, which also has to keep track of things like the window manager, but the simulation - is nothing more than a collection of Entities. ECS is particularly commonly used in MMORPGs, because it maps easily to a relational database. Every row is an Entity, each column a Component. If an Entity doesn't need a Component (if something doesn't make any noise, for instance, it has no need for a Component with the filename of a sound effect), then just put Null in that column. An Entity is just a collection of Components, and there are many ways to implement that relationship. It can be implemented statically, like the base Entity class is abstract, each type of Component is its own interface, and each "type" of game object is a concrete class extending Entity and implementing only those Components that it needs. Or it can be implemented dynamically, with a single concrete Entity class with a list or vector of Components, and an abstract Component class which each type of Component extends singly. You could build it sideways, and give each type of Component a static member variable (you could use CRTP in C++ for this) that's a list of which Entities have Components of this type. If your language has dynamic typing you may not even need to bother with classes at all, or you could do something exotic with variadic templates or God knows what. You just need to make sure there's a way that your Entities and Components are accessible to the third part of the puzzle, the Systems. I've talked a lot about how to structure the data of your program, but not where the logic should reside, and Systems are it. Implemented right, a System is a stateless (usually), parallelizable (but not necessarily parallel!), specialized (ideally) part of the program. A System is responsible for manipulating the Entities. You would create a Rendering system, for instance, which takes every Entity that has the Components which correspond to something that needs to be drawn (at its simplest, X and Y coordinates and a texture), and draws them. You need some way to make your Systems aware of which Entities they're supposed to be acting on. One way to do this would be with a function Register (and Unregister) that adds the Entity to the list of Entities watched by a given System; in a simpler game, you could also structure it so that there's a 1:1 correspondence between Components and Systems, and make it so adding a Component to an Entity also adds that Component to that System (the Component then of course needs to know what Entity it belongs to). Or you could just eat the overhead of querying an in-memory relational database multiple times per frame. In a platformer, you might have an Entity which represents the player character. This would be a discrete unit with lots of Components, even including the ones corresponding to the controller (depending on how abstract you want to make it). Your Jumping system would look for all the players who are trying to jump, determine whether they're able to (i.e. they're not currently in the air or something), then put the appropriate force vector in the physics Component and change its current animation state to "jumping" (again, there are many different ways to do this). Then you'd run the Physics System, which looks at every Entity with the Components representing hitboxes, positions, force vectors, or any other data needed for physics, and it would operate on them as needed, flagging any collisions, which would in turn be handled by the Collision system. The Animation system would take everything that has animations and determine which frame needs to be drawn. Finally the Rendering system would look at any Entities with Components containing screen coordinates and a texture, and render them. Any two systems that don't need to be synchronized - that is, they don't depend on each other - can even be made to run on separate threads. It's a very complex structure, and involves a lot of effort up front to implement it. It's a different way of thinking about your program. There are many ways to design them and it's hard to say which ones are better, but it's easier to change it since you can swap different versions of Systems in and out on the fly. It gives you the advantage of being able to separate concerns and not worry too much about taxonomy. But it also has some very substantial drawbacks, like if two Systems need some way to communicate with each other (as they often do - usually a message-passing system is bolted on top of it), as well as the runtime overhead of dealing with all these parts. It's possibly overkill for a one-person game. It also means you've got to think more about how other optimizations fit into it. I've just given you a very superficial overlook of how to do this, and no doubt more experienced engineers will take issue with some of my examples. The short version is: games are inherently complex programs, so no matter what approach you take, there will be complexities in your code; but you can influence how and where that complexity will manifest itself, and ensure it does so in the manner and place that it's easiest for you to think about. So, to answer your question, to represent the difference between a generic tile, a grass tile, and an overgrown grass tile - well, you tell me. What is the difference between those three? Model that difference in your program, not hypothetical differences that you won't be concerned with.
|
|
#
¿
Jul 8, 2013 04:58
|
|
|
Orzo posted:Your post is good, I just have one nit to pick: composition, which is at its core the basis for entity-component systems, is definitely in the realm of OOP. OOP does not necessarily imply deep inheritance trees--that's just how beginners tend to abuse it. Ah. Yeah, you're right. I'll qualify it: using composition only and not inheritance is neither the most common nor the most obvious way to use OOP (which is nevertheless flexible enough to support a variety of styles).
|
|
#
¿
Jul 9, 2013 01:34
|
|
|
Unormal posted:Are there any languages that use composition (has-a) instead of inheritance (is-a) as the language-primary first-class oo semantic? Seems like there should be, but I can't think of any off the top of my head. Go does this, with a statically-typed version of Python-esque "duck typing" (if it looks like a duck, quacks like a duck...). A Go class can't be inherited; instead, every method signature is implicitly an interface. So everything that has-a foo() member is-a valid argument to a function which only calls its arguments' foo() methods. You can still simulate inheritance by making a wrapper class that just forwards method arguments to the "parent" member, and there's some syntactic sugar to make this smoother, but it doesn't have first-class semantic support. On the dynamically-typed side of things, Lua (and Javascript, and several others) use a type model where everything that isn't a primitive (and also some things that are) is just an arbitrary string-(or other primitive-)indexed container, so the member operator ("." in most languages) is just an alias for the container index operator ("[]" in most languages). This effectively means that composition is the only first-class OO semantic. I don't know if that counts, but you can do some very fun things with it - including using metatables to hack together something syntactically indistinguishable from inheritance.
|
|
#
¿
Jul 9, 2013 03:12
|
|
|
The White Dragon posted:Oh, speaking of poo poo that compiles, I'm like one boss stage and around three minor cosmetic touch-ups away from putting out an actual demo that you fuckers can play. If someone can gimme a quick write-up of how to export things out of Visual Studio 2010, it'd help me a lot. I mean, I can just upload the thing that compiles when I debug, but I dunno if that's a good/smart thing to do. I don't know if this is in the express version, but the full version of VS2010 has a wizard for making an installer in Build > Publish. That might do the trick. Just be sure to check that the thing it makes is the thing you want. If that's not an option, then you can just take everything the game needs, put it in a folder with the executable and any DLLs, and release it yourself. You don't want to release the version of the executable, as it still has all the debug info in it. But if it's enough to give people a folder with the executable and all the resources, you can just set the build configuration from "Debug" to "Release" (it's the drop-down menu next to the run button) and build the project. This will create executable versions of all your binaries in the appropriate locations. Then you can make an installer for it by creating a new project, then selecting something that looks appropriate from Other Project Types > Setup and Deployment, and adding to it all the files that you want to install.
|
|
#
¿
Jul 16, 2013 08:53
|
|
|
If you're a programmer without an artist, then crowdfunding may not be for you. Crowdfunding is an appeal directly to your players - and people play video games with their eyes. If the selling points of your game are invisible, then you won't sell much by showing them. You can get by without art solely on the strength of your vision if you can come up with one humdinger of a video explaining exactly why your idea is unique and cool. Selling it effectively may require good graphic design, but in that case the art doesn't need to resemble the game, only communicate the idea, which is probably easier for a programmer to do. In the future there may be an equally liberating new funding model that's better-suited for intrinsically invisible pitches, but until that time comes, you've got to make do with what exists.
|
|
#
¿
Sep 27, 2013 03:25
|
|
|
I think the text is too small for a window of that size.
|
|
#
¿
Dec 16, 2013 22:49
|
|
|
Third Murderer posted:Can anyone relate their experiences with LÖVE2D? One of my many unrealistic resolutions this year is to complete a game, even if it's just a tiny shmup or something. I was going to dust off some old SFML code as a starting point, since I'm a terrible fool who hates using stuff like Game Maker because I want to feel like I'm "learning something," but LÖVE2D apparently uses Lua, so I was thinking I could use learning that as an excuse to use it. It sounds easy to use and perfect for small 2D projects, but I don't really know much about it. I've used Love2D, and it's a neat little library. It doesn't have much in the way of heavy features, but it covers all the basics very well, is extremely well-documented, and is surrounded by a fairly active ecosystem of libraries extending it. If your alternative was SFML you shouldn't encounter any unpleasant surprises. It has good performance because all the heavy lifting is done by the Love2D binary, which simply uses the Lua runtime to execute your script and provides bindings to the library functions it calls. You don't even write the main game loop yourself; it already calls the update and draw functions every frame, so you just have to define the callbacks. Lua is a very fun language once you get used to programming in a Lua-ey way (which you will have to, as it is idiosyncratic). Unlike some dynamic languages like Javascript and Python, Lua doesn't make it easy for you to treat it like a C-style language, so it behooves you to understand a few things about it: Every non-primitive object is a table. (This includes functions, but programming Lua code that takes advantage of the fact that functions are tables is going very far beyond what you'll need to put together a game in Love2D.) A table is an associative array, or, in C++ terms, a map. Every member of an object is an element in the table, and the variable name is the string key for accessing it, so the two following lines of code are exactly equivalent: code:code:Every variable declared not as a member of a table is automatically a global variable unless explicitly declared local. A Lua program has a single top-level global table (which you can access and manipulate just like any other table), so you may wish to be careful when declaring variables not to pollute it. On the other hand, Lua was invented for use cases where having a lot of global state is normal or at least not a huge deal, and if needed there are ways to still perform sane unit testing even in a program where everything is global. If you need to load a data file - something for which, in another language, you'd use something like XML or JSON - consider instead implementing it as a Lua script which declares and returns a table describing whatever you want to retrieve from the file. Then just load it with the "dofile" function. If you need to write a table, you may need something more robust. If you refer to the version of Programming In Lua available online, note that it targets version 5.0 of the language, while the current version is 5.2, so it doesn't cover some of the newer features. Most likely, you'll want to look at this tutorial about how to create modules idiomatically, which is important for structuring your code. You can expect to find it extremely pleasant for the sort of ad-hoc structure that very basic game prototypes tend to form, and the Love2D community has a lot of resources for common game development tasks. Also, if you use the Entity-Component-System pattern, as you should, you'll find Lua's native data structure particularly well-suited to it. Bongo Bill fucked around with this message at 13:17 on Jan 5, 2014 |
|
#
¿
Jan 5, 2014 12:55
|
|
|
No market for abstract?
|
|
#
¿
Apr 1, 2014 06:32
|
|
|
Is there a general opinion of LibGDX?
|
|
#
¿
May 13, 2014 21:15
|
|
|
The most useful Inform 7 resource I've ever seen was Inform 7 for Programmers. I don't think Inform 7's promise of a programming language that is like natural language quite panned out, and that document helped me understand the actual language semantics. However, based on the title you already know whether it'll be any good for you.
|
|
#
¿
Jul 3, 2014 00:47
|
|
|
I would blame Errol Flynn if anything cinematic is responsible for the impression, but even he was just following in an existing tradition of stage fighting, which has always been more like dance than combat. Ceremonial fighting is an art form and you have to decide how artistic you want you simulation to be.
|
|
#
¿
Apr 10, 2015 18:33
|
|
|
Chirps are good, but where does chatter fit into this?
|
|
#
¿
Aug 15, 2015 22:21
|
|
|
Omi no Kami posted:So I think I either had a really smart idea, or a really dumb one: I know that a realtime time-management game is a bad idea, especially when I want the player to carefully weigh the importance of every action without always being stressed, but the complaint I have with literal Persona chunks of time is that it feels very janky to constantly jump forward in time. Implement the fine-grained time-cost system and prototype it, then just change everything to take 8 hours if it doesn't work out.
|
|
#
¿
Aug 23, 2015 06:38
|
|
|
Omi no Kami posted:Oh hey, that would work... you're thinking there would be a single singleton/library class that actually contained all the logic, and I'd be handing the item pointers to that? It depends on the rest of your data structures. What language are we talking about?
|
|
#
¿
Aug 30, 2015 19:57
|
|
|
Line breaks are free. Maintaining code is harder than writing it and code is read more often than it's written, so write for readability. Your goal should be to make as little of your code clever as necessary. More contentiously, you don't have to worry about O(n) for small n.
|
|
#
¿
Sep 15, 2015 17:21
|
|
|
On that note, is there any sort of "guide" for using Unity solely as a rendering system but writing the entire rest of the game from scratch and ignoring all of its logical features?
|
|
#
¿
Sep 15, 2015 21:11
|
|
|
Hell, I'd even like to ignore their ECS architecture if possible and use something more suited to the specific game I like to pretend I have time to be writing.
|
|
#
¿
Sep 15, 2015 21:47
|
|
|
A farmer living in an apartment!? Now that's suspicious. Edit: it sounds like you're facing a discoverability problem. How do you telegraph to the player 1) what they can do, and 2) what effects they can expect from it? This is the only problem in game design, except for all the others. Thinking about it that way might help. Bongo Bill fucked around with this message at 07:05 on Sep 17, 2015 |
|
#
¿
Sep 17, 2015 07:03
|
|
|
Omi no Kami posted:I finished implementing investigations, so I'm on to planting evidence in the level... is there any getting out of loading the level at least once to get intelligent evidence placement? What I'm doing right now is placing a crime simulator actor at the scene of the crime, and the next time that room loads into memory it does a bunch of raytraces to randomly place the victim, temporarily enables physics on each piece of evidence, puts the evidence over the body, and applies a radial physics burst in a random direction to simulate the effect of stuff falling out of pockets/getting thrown around. Stuff that would stick to surfaces, like fingerprints, footprints, and blood spatter, is placed last- evidence of someone's presence is placed by selecting a random location on a line that connects the entrance to the body, and blood just traces a ray from the victim in a random direction and paints a decal on the first surface it hits. With a system like this, how do you account for the possibility of a vital piece of evidence being moved after the blood splattered on it, leaving a clean spot where it was? My understanding of mystery video games is that things like this occur in over half of all murders. Seriously, though: With this kind of generation, you're generating details as late as possible, but if two details need to be mutually consistent, then either you must generate them at the same time or you must cache the one that is known earlier. There's no way around it. If I'm understanding correctly, adding extra data, such as actor position, to a detail you've already cached, such as a crime scene, is consistent with the data model you already designed, which I think is a sign you're on the right track.
|
|
#
¿
Sep 30, 2015 17:13
|
|
|
Omi no Kami posted:So my quest system is done, this week I'm building the subsystem that specifically handles criminal cases and I have a really stupid problem. The whole system breaks down to generating Profiles of suspects, which get gradually more detailed as the case develops. A lot of the profile relies on demographic data, as that's super-easy to mix & match programmatically, but what I'm realizing is that the elegance of the system slams to a halt the instant you have multiple suspects. If I have two hair colors, two shoe sizes, a fiber from one shirt, and a finding that at least one of the perps had a severe psychiatric illness, how the heck am I supposed to figure out which stuff belongs to which guy? Requiring the player to manually assign which evidence goes on which profile is finnicky and a waste of their time, but if the game automatically puts the right evidence on the right profile it becomes massively easier to solve the crime, because even a couple of pieces of evidence get super-specific: anyone could have red hair and not be able to account for their whereabouts during the crime, but how many suspects both have red hair, no alibi, and a friend with a size eight shoe? A big matrix with evidence on one axis and suspects along the other, and icons indicating whether the evidence implicates that suspect or rules them out. Add extra icons for circumstantial and/or inconclusive. With this in place, doesn't much matter which cells get filled in automatically and which are filled in by the player. Click on the suspect to toggle whether they're ruled out; click on the evidence to toggle whether it's a red herring. Bongo Bill fucked around with this message at 02:32 on Oct 13, 2015 |
|
#
¿
Oct 13, 2015 02:29
|
|
|
It's almost as though art has an element of aesthetic discretion.
|
|
#
¿
Oct 13, 2015 15:56
|
|
|
Omi no Kami posted:Auto-incrementing 32-bit int sounds like the smart way to go, but here's the dumb follow-up problem with that: because my maps are built procedurally, the world logic component only knows where all the rooms are because each room broadcasts a message along with its own data when it's created, so I just have world logic listen for that event, and every time it fires the logic component checks its own map, and if it doesn't have a reference to that room, it adds one. Find the unique thing about the rooms that will be the same every time you generate from the same seed, and use that or a hash of it as the key. That isn't really a weird thing to do.
|
|
#
¿
Oct 13, 2015 18:34
|
|
|
Zereth posted:Please make it so you murderees can also be shot with a knife. You don't want to go overboard with something like this, but scrambling the murder weapons from Clue is good comedy and a good opportunity for misdirection. Blunt trauma with the handle of a knife, choked on a bullet, the knot in the noose came undone and the victim fell only to land exactly on an exposed lead pipe.
|
|
#
¿
Oct 27, 2015 00:10
|
|
|
AntiPseudonym posted:Oh, yep! Why's this video unlisted?
|
|
#
¿
Oct 31, 2015 20:00
|
|
|
Omi no Kami posted:"Hard-boiled detective balances ethics vs. efficacy to clear as many cases as possible before she's forced to retire" That's a story but it doesn't tell us much about the game.
|
|
#
¿
Dec 21, 2015 03:25
|
|
|
Murder Manor
|
|
#
¿
Dec 25, 2015 01:47
|
|
|
One time the game put the chicken hat on me even when I told it not to and I got mad.
|
|
#
¿
Jan 2, 2016 11:05
|
|
|
Super guides are absolutely a good feature, but you have to be very careful about the UX because it's going to show up at the most emotionally delicate moments. Burying it in a menu means it won't be seen by the players who need it most, but prompting too eagerly insults the ones who are motivated to finish it the hard way. This suggests that the optimal solution would be to enable the super guide prompts, but bury an option in the options to suppress the prompts right next to the option to enable it immediately. Or, from the Nth refusal onward, put a "don't ask me again" button on the prompt. Just don't do like they did in New Super Mario Bros. U and have the super guide box make an annoying noise at you until it scrolls off-screen.
|
|
#
¿
Jan 2, 2016 11:18
|
|
|
|
| # ¿ Apr 19, 2024 16:53 |
|
|
It's a new year. If I commit one change to the repository every day, no matter how trivial, it should eventually contain a game, right?
|
|
#
¿
Jan 4, 2016 07:33
|
|