|
Torch Dexter posted:I just added a 1920 x 1080 completely white .png (11 kb in the assets folder) If you really want to squeeze the blood from the compression stone, it can be done in 2KB. Behold! (Augh my predilections are hopelessly outdated.) On a separate note, does anyone around here have any practical experience with Godot? Every engine I experiment with these days does something to offend my delicate sensibilities, but there's a chance Godot may prove acceptable. However, the documentation is sketchy at best, and the API reference is straight up wrong in some cases. I don't mind experimenting some, but I don't want to have to figure out every function of the language through trial and error. So has anyone used it for a small project, anything bigger than a tech demo? And how well-behaved (as opposed to surprising) was it?
|
#
¿
Feb 19, 2015 19:35
|
|
|
|
| # ¿ Apr 26, 2024 00:04 |
|
|
I'm not sure what Unity does to your PNGs after it repackages them, but there's still an opportunity for you to save a lot of space by compressing them more shrewdly. Consider It's visually identical to the image you posted earlier (layer the two with XOR overlay settings and you'll spot no differences), but the original was 13,906 bytes and this version is 5,791 bytes (41.6% as big as the original). The main savings comes from the bit-depth. You saved the original as a 24-bit image (the default in most programs), meaning each pixel could represent any of 16 million different colors. But then this specific image only uses 100 different colors. PNGs support 8-bit palettes, meaning that for any image file which uses 256 colors or less, it can be stored in ~1/3 as many bytes. If you're comfortable with command line applications, check out PNGOUT.EXE (not PNGOUTWin -- that one's not free). A quick invocation of "pngout.exe -v -c3 [input file] [output file]" will usually save tons of bytes on a visually identical, fully compatible output PNG. Do this to all your files (which can be batch scripted, but is a little tricky in Windows. Make sure you've got backups before getting too experimental in the command prompt) and you should shrink your source assets considerably. No guarantee that whatever madness that Unity is doing won't excessively inflate them to the same size, though.
|
|
#
¿
Feb 24, 2015 20:57
|
|
|
While we're on the topic of dimensionality, it's always bugged me how the radar in FPS games is 2D whereas the levels are generally 3D. I'll follow a blip, sneak behind it, get right up next to it, and... they're on the floor of the building above me. Great, how was I supposed to know that? Color coded information is how. Pick some neutral color, tend toward one visually distinctive different color the further they are below you, and a different color if they're above you. 2D radars in 3D games are absolutely crippling for the geometrically-impaired.
|
|
#
¿
Apr 12, 2015 16:35
|
|
|
But it's so satisfying to make an engine. No more forced crappy abstractions, no more wild inefficiencies, no more mysteries! Of course, as others have said, it's the bane of demonstrable productivity, but if you ever want to go on a journey of self-discovery... More practically, there are a glut of engines out there these days. Not everything has to be in Unity or UE. I'd say it would be extremely worth your while to shop around until you find one whose design paradigms match your intuitions. I'm extremely let's say ideological when it comes to game development (clearly it's a hobby and not a career), and there has been something about all the major game engines I've tried that has offended my sensibilities. Every year or so I'd go back and comb through whichever engines were hot and muck around in a few. Recently I stumbled upon Godot, which is not for everyone (its lack of documentation, even an accurate API ref, imply that it's not for almost anyone at present), but this last month with it has been very encouraging. It feels like the logical extension of the engine I was trying to make: object oriented from the ground up, Python (close enough) language, built-in layout editor (I was not looking forward to coding my own one of those). I can't say what'll be good for you, but it really doesn't take very long to determine that you're uncomfortable with an engine (or a framework), and we're living in a buyer's (freeloader's) market these days. Spend an hour with a tool, make a first impression, judge the heck out of it, and never look back. At some point one of them will be judged worthy.
|
|
#
¿
Apr 29, 2015 19:37
|
|
|
BigRed0427 posted:Thanks for this. Since you brought it up, something like To The Moon is what I wanna go for. A game that is more story driven overall. RPG Maker just seems like the perfect starting point for making something like that. I know gently caress all about coding though. I am starting from square one on all this. Do it. I remember stumbling across an English translation of RPG Maker 95 when I was like twelve and it wasn't too hard to churn out something default, generic, and oh-so-blissfully mine. Also, if you want to improve your writing abilities, Creative Convention actually has a wonderful system for that in the Thunderdome. Too-short deadlines, criticism from grumpy strangers, and the fear of failing an anonymous collective are all incredibly good (albeit intimidating) mechanisms for improvement. Don't debate this kind of stuff; dive right in. The satisfaction that comes from pursuing one's dreams is downright nourishing. Merely intending to do things is no substitute.
|
|
#
¿
Jul 10, 2015 18:07
|
|
|
Nition posted:It took me a while to find a track that was both decent and Creative Commons licenced. Are you familiar with the NINJAM AutoSong Archive? I believe all of their recordings are under CC BY-NC-SA (Creative Commons Attribution + Non-Commercial + Share Alike). It's been a while since I've listened regularly, and a lot of the stuff is junk, but there are a few real gems in there. Basically, NINJAM offers a public service for people to anonymously jam online (and solves the issue of latency by delaying everything N measures). Some of the public servers come with the caveat that their contents will be recorded and shared under the above license. Then AutoSong goes through and uses some fancy maths to put together "songs" out of various jam components.
|
|
#
¿
Aug 18, 2015 21:15
|
|
|
I've been thinking a lot about how to populate space in an interesting manner; a few months back I started on a prototype of something that in my head was Star Control 2 + FTL. It's turned into a different beast entirely (massively combinatorial weapon system that currently has thirty or so mechanically different weapon properties and... half of an actual weapon. I like making flexible systems more than I like demonstrating them). But a few of the thoughts I had still seem relevant. Exploration in Star Control 2 was fantastic because there was this gigantic but somewhat-known universe that you could explore only very slowly initially, and as your character (ship) progressed you became increasingly mobile. You never had to go somewhere entirely empty on the map, although many of the locations had nothing of interest. But the places that were interesting were often very interesting, and in ways that one is generally unprepared for on the first encounter -- you don't know if these aliens are friendly, hostile, or weird, and you're not often sure if flying in a certain direction will make it worse or better. There were a lot of plot related and inter-species interactions that they could create because they used a curated system. But that also means that it's the same on every playthrough. FTL had much more dynamically created content, and you essential hop from point of interest to point of interest. This is fine, except that it allows very little relation between jumps. The longest quest involves maybe four separate beacons, and because there are so few such quests, you quickly know what they're going to be. The randomized content gives the gameplay a lot of longevity (breadth?) at the expense of depth. Purely procedural generation isn't really good enough to provide interesting locations or events at any kind of a scale; I've yet to find an example that didn't feel washed-out rather quickly. But Dungeon Crawl Stone Soup has the best solution to this problem I've encountered -- the levels are mostly procedurally generated, but there are a lot (a lot!) of pre-defined sections that can be procedurally placed. Some of these sections are as small as a room full of bees, whereas others are level-wide gnoll forts. These human-curated additions add spice and variety to the competent-but-bland procedurally generated levels, and gives it some of the greatest longevity of gameplay I've encountered. Spelunky also does this to a smaller scale. So my thoughts with regard to space: create a lot of points-of-interest. A lot of them. Then come up with a procedural system for placing them while maintaining a sense of progression. Finally, allow the player to change the density of points-of-interest -- have a default make the universe as sparse or as cluttered as you like, but since it's procedurally-placed, don't restrict the player from doing silly things, since it's no extra work to expose some variables. If they want a universe that is jam-packed with events but the difficulty's turned down, let 'em. Conversely, if they want sparse but intense encounters, more power to 'em. I say this, but I'm still light-years away from the procedural aspects of my game. Right now I'm still making it into an arcade game so I can make sure the fundamental mechanics are entertaining before spinning it into something bigger. Plus this way I'll still end up with an arcade game if the theoreticals don't pan out.
|
|
#
¿
Oct 6, 2015 01:36
|
|
|
StickFigs posted:Couple pages late for source control chat but I'll ask anywyas. A couple pages late to the chat but I thought I'd toss Mercurial out there if you're the other person who hates The Internet. It's a distributed SCM (similar to git), it's written in Python (which I suppose would be something you'd have to install if you didn't have it already), and I've had good experiences running it off of a USB stick (which also served as my off-site backup, because I don't like The Internet).
|
|
#
¿
Oct 14, 2015 02:04
|
|
|
The Cheshire Cat posted:I forget the name of the game (someone else will probably remember) You talking about PsyOps? That game was fun-as-hell, and I would've paid double for the exact same game but that a second player could control another protagonist. Emergent physics gameplay out the wazoo. Pre-edit: I guess the $$70 a month I'm paying Comcast for dicey, shaped internet traffic isn't enough to cover a few MB of web hosting anymore. Monopolies are awesome. Unironically, Neocities might also be awesome (we'll see how things go). Is it clear-enough from this video what's going on in my game? Forgive all the programmer-art (which is easily-replaceable), but I'm trying to see how well my UI tracks before the code gets too complex (which is a little less easily-replaceable). 
|
|
#
¿
Oct 18, 2015 20:31
|
|
|
I had a friend over for beers last night and finally got around to showing him my prototype. Despite being unfamiliar with the engine nor technically the language (a Python derivative), he immediately started messing around with the code. After a couple of other silly experiments he asked me if he could make the projectiles come to a halt. "No, no, their speed is based on the ship's at the time of launch and I don't want to introduce special code for one-off use cases." Then he configured a couple of variables, not actually writing any new code, and this happened:  I was quite pleased with the result. Not only is it pretty (especially at higher velocities), but the fact that someone without expertise was able to come up with weapon behavior that I hadn't even conceived of really gets my hopes up for the future of my game. I'm going for stupid-amounts of modularity and user extensibility.
|
|
#
¿
Oct 19, 2015 22:27
|
|
|
I know I'm in the minority with regard to level scaling and popularity, but I always loved the way the original Guild Wars (and its expansions) handled things. The maximum level was 20, and you could easily hit that within a day of dedicated gameplay. You would also hit that about 20% into the game, plot and content wise. After that, the game continues to get harder requiring you to improve as a player (and maybe find slightly better gear, although max-stat stuff wasn't too hard to come by). That's not to say there wasn't plenty of room for character progression after hitting the level cap. They also let you switch your attribute points and skill sets around freely outside of missions, so you could completely re-tool yourself to prepare for some specific quest or just to try something different out. And the party composition you took into a given mission made a difference; sometimes a team full of Rangers was exactly what the doctor ordered while other times they'd get slaughtered. I suppose what it really boils down to is that I prefer it when a player's skill must progress to go farther, as opposed to their character's numbers. But there are ways to achieve that and still have a sense of character progression. Conversely, consider dynamically adjusted games like Oblivion: sure my character's stats went up all the time but the fights were scaled to always be the same relative difficulty so as soon as I the player had no problem at that difficulty, the game became an effective cakewalk thereafter, regardless of the circumstances.
|
|
#
¿
Oct 21, 2015 21:18
|
|
|
I need to make more friends so they can design my weapons for me: Now I need to identify the performance chokepoints...
|
|
#
¿
Oct 23, 2015 20:26
|
|
|
xzzy posted:There's a game in there somewhere, give players a sandbox with some number of enemies and and a hero, all controlled by rudimentary AI. Their only interaction is a bunch of sliders to design a gun that will allow the hero to kill the enemy. That's, well, that's kind of the plan. At some point I'll have enough gaminess on top of my stupid-modular weapon system and then I'll be shipping it with a tutorial and sliders and asking for feedback. Except that the sliders will be Notepad. TooMuchAbstraction posted:I really do think there has to be room somewhere for a game where the cleverness of the AI is based on tactics used by previous players. So like, level-1 AI is a rudimentary hand-written AI, level-2 learns from telemetry submitted by players who were playing against level-1, level-3 learns from players playing against level-2, etc. The tricky thing is figuring out a game where the rules allow for a "learning" AI but that the player can plausibly continue to come up with counter-strategies for for some time. Presumably eventually the top-tier AI will be so good that even top-tier players won't be able to beat it reliably. I'd be in hog heaven if somebody would implement a system like this for Smash Bros. Fighting games in general have enough opportunity for varied gameplay, and for those of us that don't have an adequate play group, an AI that learned against you specifically would be wonderful. Provided you didn't end up going in circles with it. I that concept would apply decently to any game that has a heavy one-on-one component. It's harder to detect nuance against squad-based opponents.
|
|
#
¿
Oct 23, 2015 23:12
|
|
|
supermikhail posted:Finally, when I started I thought I'd make this very quickly, and therefore uncomplicated, so the gameplay and motion right now is like an infinitely scrolling shooter. The player character walks forward by itself. The idea was that most npcs would fear and escape the player, so I thought it would be best to prevent the player from stopping so it doesn't end up in a vacuum. But at the same time it's probably less satisfying with this limit on control. However, storywise the resistance should grow in the wake of the player (a.k.a. cops), thus also forcing the player to always keep moving to avoid being overwhelmed, thus basically having to keep the forward key constantly pressed, which is another of my reasons to force forward movement. Any thoughts? The more general problem you're trying to solve is how to keep the player progressing through the game without actually forcing them forward. There are a couple of solutions to this, and I've been thinking about them recently for my own top-down spacegame. There is, as you mentioned, forced movement. This is fine for arcade-style games but it does remove the sense of freedom and agency (the feeling that one's decisions had an impact) from the game. Having a solid wall-of-death trudging forward is effectively this approach, although a little more stylistically presented. There's also the Cruisin' USA model, as I like to call it. Hunger in Roguelikes. You have some resource that is necessary for gameplay to continue; fuel or food or whatever makes sense. If the player runs out of it, they lose. And the only way to acquire more of it is to go forward. This system adds for more leeway, as if you burn through the first areas quicker than expected you'll have a surplus of whatever the resource is and be allowed to spend longer in later areas. You can still math it out such that it's balanced the same as forced movement (the player loses if they're not past Area 5 at the ten minute mark), but there's much more freedom for the player to control the pacing. There's also the approach of increasing danger, which seems like it might fit you best thematically. You have secret requirements for pacing -- there's no danger for the first minute in each section, and you should absolutely be past any section by the five minute mark (make up pacing rules as you see fit). Give the player a warning that they've started to linger too long, either via the UI or by a wimpy unit spawning behind them. Then, as time progresses without them moving significantly forward, spawn increasingly harder enemies. If you spend a little too long in an area it's not a big deal, and there might even be slight rewards for the danger of extra combat, but eventually the endless enemies will overwhelm the player unless they move onward. This feels nice thematically (first the motorcycle scouts show up, then the small squads of beat cops, and eventually the tanks), without feeling unfair like an automatic wall-of-death would. It also allows the player some freedom in how to spend their time, yet allows you to control the tempo of your game just as well as the other two options.
|
|
#
¿
Oct 27, 2015 18:27
|
|
|
TooMuchAbstraction posted:So hey folks, assuming that I'm not tied to any particular engine, what's the current recommended path for me to get a 2D platformer up and running with a minimum of fuss? It's more confusing than Construct 2 / Game Maker, but if you're not tied to anything yet give Godot a look-see. I've been around the block with game creation middleware (and even written my own a couple of times), and this is the only one since the original Klik 'n' Play (great-granddaddy of the visual game makers) that has legitimately impressed me. It's rough around the edges UI wise and the documentation is lacking, but my god is the underlying design philosophy beautiful if you're comfortable with object oriented composition. They do have a platformer example, but it'll take some time to wrap your head around general project orientation. Still, I'm happy to answer any Godot questions and continue to proselytize for it; after trying to grunt through Unity for a simple 2D platformer it is oh so refreshing to work with something sane.
|
|
#
¿
Dec 26, 2015 18:01
|
|
|
FTL did inventory limits right: you had very few slots and no guarantees about when you could next visit a shop, so when you encountered something and you couldn't hold it it was Decision Time. Of course, that one thematically made sense as to why you couldn't come back for it later. Speaking of outer space:  It's not obvious from the picture, but I've got: Tracking: Pick a target, and you'll know which one it is on the radar and off-screen blips. Targeting: Hold a button to automatically rotate to face your target. Weapon Rotation: Change the angle a weapon fires at relative to the ship's facing. Fire-When-Ready: Automatically activate a system the next time it's off cooldown (good for bombing runs). Auto-Fire: So you don't have to hold different buttons down with your fingers. Space Brakes: Come to a stop regardless of which direction you're facing. I've gotten complaints for this in the past but having to turn around and try to accelerate to a stop is no fun (much like certain me-too inventory limit systems). Strafing: I don't care if it doesn't make any sense. If I'm auto-rotating to face a target, I want the up button to move me toward the top of the screen. Doesn't come across well in the .gif and I'm not going to attempt to explain it in-game, but whew is it a relief to have convenient controls. It was a good extended weekend.
|
|
#
¿
Dec 29, 2015 00:38
|
|
|
xzzy posted:It obviously worked because it kicked off the MMO genre in a way that UO was failing to pull off, but it was still basically a mud. Which irks me to no end, because Ultima Online was clearly the superior game when it came to multiplayer interaction. I won't rant about it here, but it's a shame that what most successors aped from EverQuest were the restrictive elements: classes, quests, and levels. On a related note: Binary abilities are bad design. Talent trees are the Devil. Graduate everything. Argh, now I'm all fired up. The roommates better hope they're not around, or they're gonna get an earful.
|
|
#
¿
Dec 30, 2015 02:03
|
|
|
Fangz posted:??? Expand on this? I'm not so keen on talent trees, but binary abilities seem awesome to me. Spending points to buy levels of +5% in damage is the most boring thing in the world. Compare say the new XCOM where every level you get a cool new thing to play around with. In my book, a good ability adds something mechanically that you can do that you couldn't before. If fireball and ice blast essentially reduce to Do X AoE damage of [Elemental] Type, then as far as I'm concerned they're the same ability. So I agree that something that just gives you a damage modifier is a pretty poor ability. But it kills me when say there's a locked chest that could be picked. But you don't have the Lockpick ability and, when you encounter it, you often don't have recourse to the Lockpick ability. Games frequently arbitrarily say You May Not do This (because you lack some binary all or nothing prerequisite), instead of saying You Can Try but You'll Likely Fail (say a 5% chance of picking the lock untrained with some sort of consequence for failure; destroying the loot or triggering a trap). They literally lock you out from gameplay choices. I think now that I've calmed down the brunt of my beef is still against talent trees and smiilar systems that don't let you respecialize in a reasonably convenient fashion. I'm okay with limiting access to gameplay options as a form of character progression or differentiation, but so many things are too rigid (you didn't start as a Wizard so you'll never be able to cast Telekinesis to get that one shiny bauble) to the point that they either lock you out from gameplay experiences or expect an unreasonable amount of mundane time investment (starting over) just to get the broader experience. If you come up with something cool, make sure your players have a chance to experience it. As mentioned earlier, the original Guild Wars did wonders in this department. If you were out of combat for 20 seconds, you were healed. If you went to town, you could pretty thoroughly respec for free. Fast travel to anywhere you've previously been. Really distilled away all of the aspects that weren't engaging.
|
|
#
¿
Dec 30, 2015 08:19
|
|
|
Somfin posted:The other is a skill check, which takes the form of a dice roll- 2 six-sided dice plus skill modifier (from -1 to 3), with a 10+ being an unqualified success, a 7+ being a qualified success, and anything less being a failure. The way this works is, a 10+ means that the player gets whatever they wanted, a 7+ means the player gets what they want if they pay for it in some way, and less means that they don't get what they want and something bad happens. For example, the Fighter can use Bend Bars, Lift Gates if the party encounters an obstruction of any kind- on a 10+, the party gets past the obstruction, on a 7+ the fighter has to pick two drawbacks, and on a six or less, something bad happens. The GM has a list of something bads that can happen, including wandering threats, loss of equipment, characters take damage, or a more general 'the situation gets worse.' No matter what, the player did something to change the course of the game with that single roll, and that happens every roll, which is loving rad. It keeps the pace up and prevents players from rolling checks against a stuck door for half a session. Very much this. It's much easier to do in a pen-and-paper system, but failure shouldn't be a roadblock, it should be a thing that propels you forward in a slightly unintended direction. That's a little harder to translate to the world of computer games. There are plenty of times where death, thematically, feels like a requirement. But take Rogue Legacy for example: when you die, you come back with a different set of amusing and gameplay-affecting character traits. You don't really start over, instead you just proceed differently. In a more statically oriented game, if the player has the ability to load (which is almost always) and they really want the thing they failed to get, they'll just keep trying and getting more frustrated until they succeed. Dynamic difficulty is one approach to that, but to some people it feels like cheating or hand-holding they don't want. Imagine instead that the ghosts of all of your alternate-dimension dead souls possess you every time you respawn, granting you temporary superpowers and maybe some spooky UI skinning. That addresses the problem of locking people out of content that they've clearly indicated they want, but one would be much more likely to feel intoxicated with power than to feel like the game was dumbing itself down, even though it's effectively the same thing. Bert of the Forest posted:In TellTale's case they seem to be hanging on to death = game over screen basically out of habit at this point, rather than include it in a way that makes sense with the rest of their games' design. It's galling how often people do things without even stopping to think why they're doing them. What do they hope to accomplish, and is their present course of action a reasonable way of doing so? And I'm not just talking about computer games.
|
|
#
¿
Dec 30, 2015 18:49
|
|
|
Is it clear how my shield system works? Explain it back to me, if you'd be so kind.  It makes sense to me, but I designed it. I think all of the visual elements come across, though I'm delighted to say I was too busy shooting ships in space to pay adequate attention to the UI.
|
|
#
¿
Dec 31, 2015 00:55
|
|
|
Greatbacon posted:Also I noticed those charge bars underneath the shield indicator, but at some points there was more than one. Why is that? Why not just have the charge bar reset if you get hit again? Because in this particular example I had two shield systems acting independently. In this case they happened to have identical stats, but one of the gameplay decisions I want to allow is the ordering and stacking of shields: if you have something with low shielding power that recharges quickly, by all means put it in front of something that has a higher shielding capacity but longer delays. Fangz posted:If so, please don't put one of the most important pieces of info (the shield indication) in the most out of the way part of the screen. I'll certainly look toward making it more obvious. But I already feel like I'm taking up too much screen real estate with UI. Dr. Stab posted:Looks like a recharging shield with a delay before it starts recharging. If that's it, I'd do away with the recharging bar, and either replace it with nothing or maybe just an indicator for each of the states the shield can be in (such has having the shield change color or blink when you take damage). It's the sort of things players get a feel for, and the added ui element to indicate what is happening is just clutter. Also, why are shields and health represented in such a different fashion? Why not just a bar below the health bar, or overlayed on top of the health bar? I think the health bar is a little too large at present; I'm probably going to retool it in some fashion. I'll find a way to make it more consistent with the shields display. It's going to be a little harder for players to get a feel for shield recharging when multiple shields are employed, and I expect frequent pausing at high level play, so I do want the information to be more precise than waiting/recharging/charged. But maybe I'll put those progress bars underneath each shield system, like I did with the cooldown bars for weapon systems. Also, would brief screen-color-flickers to indicate shield damage vs hull damage be a good idea for communicating information without moving the player's eyes, or would that be too distracting?
|
|
#
¿
Dec 31, 2015 18:18
|
|
|
I do something similar with the shields already, and will keep the particle bleed in mind when it comes juicin' time, but I'm still in the proof of concept phase. And that rant earlier about how death shouldn't be a setback but instead a continue-but-differently situation?  I just ate my own dog food, and it feels good  (It's a bit jumpy, but when you get killed by an enemy ship you become that ship. I'll have to figure out how to work that into the narrative.)
|
|
#
¿
Dec 31, 2015 22:45
|
|
|
I'm also fond of metroidvania and have vague intentions of making one, but most modern game creation middleware is not ideal for non-physics-based pixel-perfect platforming. Stupid Box2D. But I've thought a fair bit about procedural generation. Most games still can't do it right in a manner that feels satisfying for any length of time. Very quickly the Oblivions and Mega Man X6s begin to feel bland, whereas the Symphony of the Nights still stand out in my mind as awesome. The best compromise shows up in roguelikes, specifically Dungeon Crawl Stone Soup and FTL. They've got in general randomly generated content, but a large selection of vaults/events -- things that were designed very deliberately to be interesting. These vaults/events show up according to the rules of the level generation and serve to keep things fresh when the patterns of the generation algorithm have become internalized. So my current grand experiment is in procedural placement. I want to have a butt-ton of deliberately crafted content, but then only a certain algorithmically determined subset of it is available on each run-through. The hope is that in doing so I can maintain the deliberate, cohesive, and awesome feel of well-designed levels with the exploratory and replayability boons of random generation. As an added bonus, if you make the external modules sufficiently moddable, your fanbase can drastically extend the lifetime of your game. See Knytt Stories as an example of this. In fact, play Knytt Stories. It's a well-designed ambient exploratory free metroidvania with a huge collection of user generated levels and awesomely chill music. Seriously. Play it.
|
|
#
¿
Jan 2, 2016 18:22
|
|
|
DeathBySpoon posted:SIMPLE SYSTEMS, COMPLEX COMBINATIONS: Elements are defined in the simplest possible manner. Game depth comes from multiple elements interacting in interesting ways. This right here is not getting enough love. UNIX greybeards will defend it to the death, and it's becoming my overriding obsession for game design. Here's a snippet from my weapon interface: code:Four million meaningfully unique weapons. Right now I have two lasers.
|
|
#
¿
Jan 7, 2016 21:20
|
|
|
Somfin posted:Two things here. Thanks for the code review. It caught me by surprise, and illustrated some good points. #1 was partially by design, partially by laziness. All of those effects are already implemented (minus a few that I think I'm going to remove for thematic reasons), and the code's not too unwieldy: ~100 lines for the code common to all Systems, ~100 lines for the code common to all Weapons (more than half of those being variable declarations), ~230 lines for the code common to all Projectiles (which are really what utilize most of the Weapon properties). But I wanted it to be braindead-easy for players to create their own weapons. Just drop a text file in a folder and it'll appear in-game. For example, the laser I generally use: code:For #2 -- yeah. I should redo those. It's kind of painful to revisit. That was literally the first section of code I wrote for the entire project, and I did it immediately after getting back from a five-day camping/rave in the wilderness, with 20 hours' travel time. My wires were kind of scrambled. Shalinor posted:Really, please, always put a console into your game that can do stuff like this. Half-Life 2, Jedi Knight 2 AND Academy, Skyrim, Fallout, etc - all games that it's really, really fun to just spawn a bunch of dudes and witness the chaos that ensues. I think the debug mode in Sonic the Hedgehog games, which let you fly around and place any of the level's objects on the level at runtime, was actually what got me interested in designing games as a kid. There's something wonderful about creating stupid situations that a game hardly knows how to handle. Really extends the longevity of the game, too.
|
|
#
¿
Jan 8, 2016 20:54
|
|
|
DeathBySpoon posted:I put out the first gameplay video of Roggle today, after months of gifs I figured I'd share Day-um! Roggle's gotten really pretty in the last couple of weeks. I've also outlived the usefulness of animated GIFs. I think since my last one, I've added: * Black Holes. * Ion Clouds. * Bunch of UI improvements (still gonna move the shield bubble eventually, but the bars have been standardized now). * Asteroids. * Golden Asteroids, with a spawn rate way higher than normal. * Ships can (and currently do) drop systems when they die. * Pick up systems. * Scrap systems. https://vimeo.com/151270589 It's somewhat unfortunate that the Little Game Jam hit now instead of last month, because I do not want to lose this momentum.
|
|
#
¿
Jan 10, 2016 04:29
|
|
|
I agree with the above sentiments -- if you're not using every column every time, CSV is not the way to go -- but:Somfin posted:In a raw .txt file, what you see is what you get. Not true! Do you have any idea how long it takes to discover that someone put a rogue '\r' on the database connection string of an otherwise UNIX-formatted text file? I'll give you a hint: it's inversely proportional to the amount of rage induced by Hibernate's same-stack-trace-for-every-error.
|
|
#
¿
Jan 10, 2016 13:53
|
|
|
I just realized I've never implemented a conversation system before. Trying to distill down the rather heated wisdom from earlier, I'll need to support: * Go Forward * Go Back * Skip Forward * Skip Entirely (or until next unmade Choice) * Revisit at one's leisure Anything I'm missing?
|
|
#
¿
Jan 11, 2016 19:32
|
|
|
I'm sure this wouldn't suit your game at all thematically, but I'm alliteratively attracted to the idea of Bonus / Bummer.
|
|
#
¿
Jan 15, 2016 06:31
|
|
|
TooMuchAbstraction posted:Lunatic Fringe + FTL This was exactly what I was thinking when I started my current project. And, just like Unormal's post, Star Control II crept in immediately after. It's evolved a bit since, though. Thanks for reminding me about the screen fuzzing up and all that stuff. It's a bit anti-player asymmetrical, but I'll probably add some of those effects. Actually half of them (forced turning/accelerating/weapons firing) are already in place as applicable debuffs, I just need to cause them to occur. TooMuchAbstraction posted:Plus, uh, I'm probably never going to actually work on this. But it's fun to daydream, and who knows? This currently is my big project. And my prototypes and proof-of-concepts are already fun to play, so I'm confident the idea is viable. I also intend to make it open source, I just haven't decided on the specific license. Here's a video I posted a little while back: https://vimeo.com/151270589 I'd be happy to share builds or the source if you're interested, and I'm always down for Talking Design, though I'm busy as beans right now and find the majority of popular communication mechanisms objectionable.
|
|
#
¿
Feb 8, 2016 23:25
|
|
|
TooMuchAbstraction posted:Haha, awesome, glad someone is working on this. I honestly haven't given the idea much thought beyond that basic kernel. It seemed to me though that to make the ship/crew management "compete" with the flying and combat, you'd need to constrain your environment such that the player can't easily just fly away from things and buy the time they need to handle coordinating repairs and so on. You really don't want the game to devolve to "get into a fight, get damaged -> fly away, effect repairs, return -> repeat". This has implications for how the rest of the game gets designed, because some things work a lot better in small constrained spaces than others do. I've shied away from the minigame / ship internals route as I've found that there's already too much to manage in most cases, but one of the things I am stealing from FTL is the urgent sense of progression. I haven't coded it, but essentially you'll have to keep moving outward from the origin or the equivalent of the Rebel Fleet will catch up with you. Maybe if you've made good time you'll be able to run from a fight, heal up, then come back, but healing is going to be mighty slow so more often than not I'd expect a situation you returned to to be more difficult than the one you left. Also if you fly somewhere else you're likely to run into something else, so fleeing a situation is not without its risks. I still ought to redesign the sector system. Right now, everything secretly Cartesian, but I'll want different spacing between "events" (prepopulated scenes) and areas of different sizes. But that gets into all kinds of messy algorithmic territory.
|
|
#
¿
Feb 9, 2016 21:59
|
|
|
I was playing a collaborative storytelling game with some friends a while back. It was an interesting but mostly aimless experiment. One thing that did come of it, though, were the werewolves. Our fantasy society was behind technologically, but ahead in terms of bio-manipulation. A man was hybridized with a dog in an attempt to create a better soldier, but the attempt failed; he remained fully human. Then a full moon hit and he broke out. Modern werewolves in that world are extremely corporate, secretive, and professional. The alpha male calls the shots for a given clan, and unless you're accepted into their umbrella you might never know that they aren't fully human. I liked the idea of applying mythology to modern society so much that I decided that all the alien races in my space game should be created as such. So yeah. Mobster Werewolves in Space. I'm workin' on it.
|
|
#
¿
Feb 22, 2016 19:15
|
|
|
This probably isn't appropriate to your game but I just had a thought that struck me as pretty nifty. What if while it were good 'n' dark, motion and collision generated light waves around their source? Sort of a visual representation of an auditory process. That would allow for some interesting gameplay situations where you don't want to move for fear of dangers but can't remain still for fear of forgetting. Plus you could get a mighty good jump scare when the previously motionless/invisible shrieking bat suddenly swoops down and illuminates everything with its death-yowl. And I like the idea of generic wandering enemies revealing the structure of the platforms they're on. I should try to hold that thought for next time I'm involved in a game jam.
|
|
#
¿
Mar 5, 2016 17:39
|
|
|
dhw posted:Waggle-drivin' I legitimately thought he was just doing that to go faster. I may have played a little too much F-Zero GX back in the day.
|
|
#
¿
Mar 23, 2016 18:20
|
|
|
dhw posted:If anyone would like to join the beta for our game Cruise Control This may be the first time that there's something I wanted to do but couldn't because I didn't have an iPhone. Don't suppose there are future port plans?
|
|
#
¿
Mar 26, 2016 16:07
|
|
|
I've been working on a platformer engine just for yuks recently and I've come across a conundrum. I want the controls to be tight, meaning nigh-on-instantaneous acceleration. And I want the ability to jump off of walls. What I don't want is the ability to jump off the same wall repeatedly on order to scale it; wall climbing shall be a separate power-up. But I can't think of a good way to intuitively prevent same-wall jumping other than by forcing the player to get a minimum distance from the wall before returning horizontal control to them. To me this looks awkward: https://vimeo.com/160467384 Does anyone have any ideas as to how to still have wall-jumps but prevent this kind of scaling/stalling?
|
|
#
¿
Mar 26, 2016 23:13
|
|
|
Hoo boy. Them's some responses.Fangz posted:Make it so that you need to make a running jump to get into the wall jump-capable state. Nah; I want both chained wall jumps and the ability to maintain the running state in the air (already present). rarbatrol posted:Edit: or alternatively just make it push you away from the wall instead of upwards at higher falling speeds. You could then play around with fall speed affecting/scaling how much wall jump height you'd get, in general. I might consider that. I did something like it a long time ago and it had its own tradeoffs, but they were more fun than awkward (wall jumping when you were falling just slowed your fall, but you could really launch yourself out of quick jumps in a narrow corridor). I'm not sure if the player's current velocity is actually available to me with a KinematicBody2D. I'll have to check. al-azad posted:Nah, you're doing it right. It'll look less awkward with a little bit of tweaking to the physics but take a look at one of the New Super Mario Bros games to make the momentum look more natural. I'll check into one of those. I did at least math it to the point that you can't gain height (and can only maintain it with good reflexes). swamp waste posted:Don't let the player control their guy's velocity in the air, let em add a little horizontal acceleration but not so much that they can get back to the wall at a higher point than they kicked off of it. Those games have loose air physics. I'm going for a tighter Castlevania/Megaman feel. I didn't demonstrate it well in the video, but I want you to be able to reverse direction instantaneously in the air. Except immediately after wall jumping, for the originally mentioned reasons. Nude posted:How about you have it so when the player jumps on the wall they just stay there? And you can't climb up or down unless you have that climbing powerup. Press jump again to jump off, but when you jump off you can't change your direction or if you can it's on an arc so you end up in the same spot. I also like the running jump idea though. I intended Wall Stick, Wall Jump, and Wall Climb as separate powerups. While I could make Wall Stick a prerequisite for Wall Jump (it certainly is for Wall Climb), I want the same Wall Jump mechanic to work for well-timed jumps off of enemies. The wall jump detection boxes are slightly to the side of the player's hit zone, whereas Wall Stick would visually require them to be immediately adjacent. But if you're required to stick to a wall before jumping off it, you'll never be able to jump off of the side of an enemy because it'll hurt you. And I also don't want you scaling the larger enemies. Dewgy posted:Instead of a minimum distance from the wall, have the player pause when they keep holding the movement key towards the wall and after the jump give them full horizontal control back once they're moving downwards again. It'll give you a feel of "popping" away from the wall, and you can play with just how much control you take away from the player when it happens. Maybe add like a boom or a poof by the bottom of the player sprite to make it make sense when you lose control for a moment. The effects are definitely a good idea visually. I intend Wall Stick to be separate from Wall Jump; see my above response. HappyHippo posted:If you know how your physics works (acceleration due to gravity, horizontal acceleration due to player input) you can set the initial velocity off the wall such that it's impossible to get any higher off a wall jump. I'd work it out but it doesn't look like you're using "normal" physics (the character appears to stop accelerating downwards and fall at a constant rate after a second) so I'm not going to bother if it wouldn't help your scenario. I've already done the math such that they can't gain height from the current implementation (which went out of its way to override normal physics; keen eye on the fall speed). I could prevent consecutive jumps from the same solid by tracking which object was last jumped from, but I worry that that would create too many frustrating surprises where as a player I expect to be able to wall jump again (maybe it's a really big wall), and I'd rather silly gameplay than unpleasant surprises. Also this all goes to hell once the player gets Double Jump. But I'm fine with them effectively scaling walls at that point; I'll just have to employ crafty level design. Spek posted:In Metroid Fusion you cannot single wall wall jump, or at least you cant gain height doing so. It just takes away horizontal control for a while and gives you a big hit of acceleration away from the wall so by the time you have enough momentum back towards the wall you've fallen too far for it to be useful for climbing. That's exactly what I've done. And yeah, I want to avoid arbitrary frustrations even at the cost of visual jankiness. al-azad posted:I want to believe the developers didn't intend for it to happen but yes, in Super Metroid there's a one-frame period before Samus tucks and rolls that lets you instantly change direction and reverse velocity while maintaining her jump height. I can manage the math to prevent a net gain of height but stalling in that fashion looks silly to me. It does provide the Wall Stick capability in an indirect, skill based way, so I suppose that gets chalked up as a "feature". ape posted:The android version is not too far behind. Just a few extra bugs to work out before we can beta test that as well. Bitchin'. SUMMARY I might make the y_velocity after wall jumping relative to the current y_velocity instead of absolute. I'll see how that plays out. I also might fake deceleration only during the wall-jump-input-override period, so that you keep going at full speed if you hold the away direction, come to a stop if you hold no direction, and don't reach full reverse speed until you've lost the height gained from the wall jump if you're holding the opposite direction. That'll be more math but I think create the most natural result. And when I get to the graphical phase I need to make sure little dust clouds (or object-specific detritus) spew out from the point of impact. Thanks for all the feedback.
|
|
#
¿
Mar 27, 2016 01:35
|
|
|
Here's the culmination of my selective interpretation from all that platformer feedback: https://vimeo.com/160794701 Selective acceleration prevents wall climbing while maintaining an adequately natural feel. Unless you want to get really technical with selective sprinting, which I demonstrate is possible but also difficult. Took me an entire day to figure out why Slide Kicking wouldn't transition into Falling when I did it off the vertical block; it just continued at a fast and funny diagonal. Fixed that bug then immediately re-implemented the behavior but deliberately 
|
|
#
¿
Mar 29, 2016 21:12
|
|
|
andipossess posted:If you mean my game, it currently looks like this (except the gif is playing back way too fast): Are you sure the video playback is too fast? Because after watching that I'm worried that my game is to slow and floaty. Also, I totally saved that GIF for reference material. It's oozing with juice; probably delicious pomegranate. How far into development do you think you are? And how many of the design decisions were deliberate versus reactive?
|
|
#
¿
Mar 30, 2016 18:17
|
|
|
|
| # ¿ Apr 26, 2024 00:04 |
|
|
I know a while back someone said that Capsule was the preferred character-physics-shape for 2D platformers because it helped with slopes, and that seems to be true. I feel like someone posted a lengthy discussion on Ducking but I went a dozen or so pages back and I couldn't find it. Now I'm running into a problem that's a combination of the two: https://vimeo.com/161205209 What's the conventional wisdom for preventing a capsule-shaped player from sticking on edges like the small midair one I've got in the video?
|
|
#
¿
Apr 1, 2016 17:38
|
|