|
I've been noodling at a project to do procedurally-generated Metroidvania games for a bit. Still very much in the planning phases; I have a script that generates high-level map layouts, but it doesn't fill in the map contents yet and I don't have a game engine, monsters, etc. yet. I want to make certain I have the most difficult aspects figured out before I dive into details; I've written my own 2D game engines in the past so that shouldn't be a problem, but prior projects have gotten bogged down in minutiae, and then after a few months' work I realize that I'm no closer to actually implementing a game. I'm just gonna lay out my thought process here; I'd appreciate advice from y'all. 1) Generate high-level map layout. This consists of "locks" (i.e. impassable terrain), "keys" (powerups that enable bypassing locks), "trapdoors" (terrain that locks you into a given section of map until you find a key), and the corridors and rooms that connect them. This is where I am now (well, no trapdoors yet, but otherwise). Sample output:  Start at 0, navigate to the 1 key, then you can bypass 1 locks, etc. 2) Decide on a selection of powerups. This will inform some aspects of the level layout (e.g. if a certain lock requires a large vertical or horizontal stretch leading up to it). 3) Fill in the contents of rooms and corridors. The plan here is basically to replay / rewatch a bunch of Super Metroid ROM hacks and steal (ahem, "adapt") everything that looks like it could go in with a minimum of fuss. Platform layouts, fixed puzzle rooms, etc. My game won't have the same powerup set as Super Metroid (for one thing, I don't think I can really get away with blatantly stealing the morphball, which is a shame because it's so genius), but most straight-up platforming should be adaptable. 4) Throw together some lovely programmer art. 5) Steal the game engine from one of my previous projects and drop it in; throw together a lovely protagonist that can run, jump, and attack. Make some basic enemies. 6) ??? This is far enough out I haven't planned that far. Presumably start recruiting artists and work on adding more content (more room types, more enemies, more powerups, bosses, etc.). So two questions:
|
#
¿
Nov 19, 2013 00:14
|
|
|
|
| # ¿ May 22, 2024 02:12 |
|
|
seiken posted:The biggest thing that jumps out at me is that naively defining a powerup as a specific key that unlocks a specific set of doors might result in a shallow or overly linear experience. Half the fun of metroidvania is nonlinearity. Maybe the RNG will balance this out and happen to create a nonlinear things, but maybe keep it in mind? (Especially sequence-breaking, which doesn't seem like it can come about under a system of absolute lock-and-keys) If you look at the map image I linked, it's fairly nonlinear. Obviously each newly-unlocked sector has to connect to a previously-accessible sector, but it needn't connect to the sector you're in when you find the key. Likewise, you can throw around minor powerups that are behind arbitrarily-"hard" locks (The Super Metroid equivalent would be like the E-Tank in Brinstar, behind the charge beam, that requires powerbombs and the gravity suit to access) to give some point to later exploration/retreading. Sequence-breaking is mostly tricky in that it requires you to be careful in how you design regions, to ensure that the player can't get stuck. The actual breaks are mostly just a matter of setting up your locks so that there's more than one way to tackle them. That said, high-level map design is obviously vital to making a good gameplay experience. If the game places locks so you keep having to travel back and forth across the entire map every time you get a new powerup, then that's no fun. One of the ways I'm trying to address that is by adding shortcuts to the map, so that once you have a given powerup you have a faster route from point A to point B. I'm not entirely satisfied with the results yet, but I'm aware of the issue and am working on fixing it satisfactorily. Yodzilla posted:I feel like I've been a part of a "can procedurally generated Metroidvanias work" in another thread and I'm still a bit skeptical. I don't think you're missing any obstacles other than "how can I make this fun and is it a compelling gameplay expeirnce?" Rogue Legacy got away with being a sort of procedurally generated Metroidvania since there was no actual blockage to progression other than being unable to kill enemies and not surviving. Excellent question. I'm approaching this basically from the mindset of "Super Metroid was an awesome game, but there's only like a dozen good ROM hacks of it and I've played them all, wouldn't it be awesome if you could generate a new hack on demand?" Which is probably a bit too niche of a target, since most players are going to need some broader goals and/or some kind of meta-progression to keep them motivated. It would be straightforward to add permadeath or a limited-lives approach, and the game will have to have some degree of challenge scaling (since the combat abilities of the player will increase over the course of the game, so too must those of their opponents). So it's easy to imagine a progression of "Beat the game on level 1 with 5 extra lives; beat it on level 1 without dying; beat it on level 2 with 3 extra lives; etc." It would also be straightforward to set up challenge modes that would weight the game in various ways, e.g. by leaving out a specific useful powerup, or making maps that are unusually heavy on either combat or platforming. Getting back to sequence breaking, you could also set a par (in terms of number of key items collected) for a map and then challenge the player to beat the map under par. I think I'd want to tend more towards the Spelunky type of metagame than the Rogue Legacy type, i.e. the player shouldn't necessarily expect to make any "progress" in any given game (where Spelunky's progress is defined as buying off shortcuts or at least making it further). Mostly that's just because I find Rogue Legacy to be pretty grindy. Finally, as for the "oh it's THIS room again" thing, I definitely agree that can be a major problem. A lot of time is going to have to be spent on not just adding different room configurations, but also on breaking each one down into building blocks that can be placed in more variable fashions. E.g. a specific room might consist of several platforms each with an enemy spawner on it; depending on the RNG and the local difficulty setting the platforms could change size, the spawner could change frequency, the type of enemy spawned could change, etc. I'm fine with the player recognizing patterns in room layout, as long as the specific circumstances are different. After all, people play Angband and NetHack and so on even though they have very simple dungeon generators. EDIT: Corbeau posted:Step one is to make sure that not all keys types and door types are present in each playthrough. If that means shortening the length of a single playthrough, that's fine; after all, it's probably meant to be played repeatedly if it's procedural. That way the player will be confronted with using different types of keys (I'm assuming that "keys" in this context are powerups that allow progression but also modify normal gameplay) from the start of one game to the start of the next. I don't think a game like this can have the sheer scope of powerups that Binding of Isaac does, since the powerups must necessarily be individually distinct and "momentous" in terms of what they let you do. But the more the merrier. TooMuchAbstraction fucked around with this message at 02:35 on Nov 19, 2013 |
|
#
¿
Nov 19, 2013 02:33
|
|
|
The Cheshire Cat posted:When in doubt, look at Spelunky for a good example of how to do randomly generated platforming. It's actually VERY repetitive - you'll start to notice some of the more obvious "puzzle pieces" the game uses to construct levels pretty quickly, but because of the way everything fits together it doesn't get old. It does pretty much what speng31b describes here; it presents you with a variety of obstacles that follow a consistent set of rules for how they operate, and gives you multiple tools you can use to get past them. quote:Actually one thing that might be interesting in a Roguelike Metroidvania is a Spelunky style bomb as the last key; essentially giving the players the freedom to blast their own path wherever they drat well please. By that point they should probably also have some means of unlimited vertical travel too, so they don't end up stuck in a pit of their own making. quote:One thing that can also help break up the monotony would be to use different tilesets to create differently themed areas. So even if you end up with two rooms with very similar layouts, they'll at least be different looking enough that they won't FEEL the same. It would also serve as a navigation aid since it's very easy to get lost in a bunch of same-y looking corridors, but easy to remember "I'm in the library so I go west from here to get to the clock tower" or whatever. Forer posted:shortversion: You also need to make bypasses for your locks not through "do you have X item" but "or do you know that there's a secret trick to allow you to walljump and you can BARELY walljump up there if you have the mechanical ability." This basically aligns with the "how to apply sequence breaking" note from earlier. The main trick with trying to do something like this is in figuring out what the player's mobility is and how that informs room layout -- and then making certain that if the player sequence breaks in the "wrong way" they still don't get stuck. IIRC Super Metroid only has one example where you can get well and truly stuck: if you get into the Spring Ball room without Gravity Suit, then you can't get out again. Otherwise, while it may not allow you to proceed without the right powerup, you're always at least able to backtrack. The simplest way to handle this is to generate rooms under the assumption that the player has no powerups, and only require the powerups at the locks. I suspect this will create somewhat boring gameplay though, as much of the interest of sequence-breaking is in navigating rooms that would be trivial if you only had another item (e.g. the grapple-climb room in Maridia). So the real trick then is in creating rooms/scenarios that have multiple possible solutions, only one of which is obvious. And that sounds hard.  Regarding advanced movement techniques, any thoughts?
|
|
#
¿
Nov 19, 2013 16:07
|
|
|
xzzy posted:Jumping in 2D platformers is one of those sacred cows you just don't gently caress with. Games have died because of it. Oh yeah. If your jumping doesn't hit that right blend of responsive and floaty, but not too floaty, then people will complain about how the controls suck. There's a little wiggle room in there (look at the Super Smash Bros. games, where every character's jumping physics mirror their source games, when applicable), but there's also a ton of room to get things horribly, horribly wrong.
|
|
#
¿
Nov 19, 2013 19:39
|
|
|
I'm poking at a basic design document / brainstorming list for the procedural Metroidvania concept. I put a rough draft up here. A few questions: 1) Given the desire for a very basic physics system (ballistic trajectories, gravitational attractors, and rigid tethers), should I go with a commercial game engine, or are these things that are reasonably straightforward to roll myself? As I said earlier, I have sufficient programming chops to implement most things myself, but at some level there's a question of how much my time is worth. I don't want to have to deal with stuff like the "frozen zone" in Spelunky (i.e. weird engine limitations) if at all possible. 2) Obviously I need more ideas for different region types, and the regions need to be more fleshed-out. How am I for variety in other areas? Does anything strike you as being particularly onerous to implement? 3) Does this sound like it could make a fun game? Do I have a combination of concepts and ideas that work well together and would result in something that people would be willing to sink a lot of hours into? 4) Obviously, if you have any suggestions for the various idea lists (items, monsters, regions, advanced techniques), they're more than welcome. Thanks for any feedback!
|
|
#
¿
Nov 28, 2013 01:56
|
|
|
The Cheshire Cat posted:Unrelated: Why did his head explode? Looks like he ran into a bird mid-flight. Either that or that explosive potion is nitroglycerin and he drank some earlier.
|
|
#
¿
Dec 5, 2013 21:54
|
|
|
BottledBodhisvata posted:So, I wanna make games. But I'm also incredibly bad at drawing and I don't have millions of dollars and I don't know anything about programming. You don't need to be able to draw to make games; that's what "programmer art" (i.e. crappy placeholder art) is for. You don't need money (but you do need time). You can learn to program on your own. For actually trying to design games (i.e. come up with rules that create interesting challenges for the player), you don't even need a computer. Design board games; all you need is some paper and maybe $15 worth of generic tokens. But realize that designing games is not what 99% of people who "make games for a living" do.
|
|
#
¿
Dec 6, 2013 17:27
|
|
|
Apple Jax posted:I'd also agree with everyone saying that going to school for game design is a terrible mistake and would just be a massive waste of your time and money. Teach yourself what you're interested in or find single classes you can take for specifically what you want. If you go into a game design or general design program you'll likely have most professors teaching out of a textbook and having you learn from it anyway. I majored in general graphic design and ended up learning far FAR more from what I taught myself. Well said. And think about this another way: say you go to a "game development" school and get your BA/BS in game development (or whatever they call it), and then either can't get a job with a game company, or work in games for a year and discover that it's not what you thought it was and you don't want to work there any more. Where do you go from here? Traditional industry jobs aren't likely to be interested in someone who can make games; they need web developers, systems engineers, graphic designers, etc. On the flipside, if you get a more generic degree that can then be applied to game development (like a CompSci degree or graphic designer or even maybe an MBA), then you can still work in games, but you also can work in other industries if games don't pan out. So at the very least, if you want to go back to school, go to a traditional school rather than a game development school. But really I'd say try to make some games in your own time first, so you'll have some idea of what you're getting into before you dedicate a lot of time and money to the effort. Get yourself a copy of GameMaker or Macromedia Fusion (check out the Humble Sale!) or something, figure out how to make it dance, make yourself a stupid little puzzle game or platformer or whatever. It'll take a lot of work, and it'll be frustrating, but it's also pretty close to what you'd have to deal with daily in a game development job.
|
|
#
¿
Dec 6, 2013 18:08
|
|
|
Ulta posted:Also don't play D&D. Well do play it, but realize every version has some pretty glaring flaws. The current indie rpg darling is Dungeon World, which is fantastically designed. What? Yes, you should play terrible games! How else are you supposed to learn what doesn't work in game design?  Seriously, though, it's a lot cheaper and faster to learn from the mistakes of others than it is to repeat those mistakes yourself. If you want to be a game designer, you need to play a lot of games, but most importantly, you need to be analytical while playing those games. What works? What doesn't? Why doesn't it work, and how would you try to fix it? It's a lot easier to make a bad game than a good one. There are tons of ideas that sound good but don't work in practice, as well as plenty of ideas that are good but weren't implemented quite right. Figuring out how to get everything to work together neatly to make a cohesive, fun game is probably one of the hardest parts of designing games.
|
|
#
¿
Dec 6, 2013 19:09
|
|
|
The Cheshire Cat posted:It's not the only game to suffer from that design flaw though. Play public games in pretty much any team-based multiplayer shooter and 9 times out of 10, one team will just steamroll the other the whole way through. The problem is you can't just end the game early because of the edge case where the losing team actually DOES make a comeback, and it would be unfair to deny them that opportunity, even if in the vast majority of games it's just a waste of time. One way to work around this is to have short matches. If you play, say, Altitude (a 2D airplane combat game), the matches usually don't last more than 10 minutes or so, so even if your team is losing you aren't out that much of your time. Similarly, I won't play Bang! but I will play Shadowhunters; they're both boardgames with hidden identities where the players want to figure out who is on which team and then team up with their buddies to kill everyone else. The difference is that in Shadowhunters, usually once one player is revealed the rest of the game falls out in short order, while in Bang the game can drag on for quite some time. That's no fun for the eliminated players. Generally, the last thing you want in a multiplayer game is for the player to feel like their actions don't matter. Whether that's because their team is hopeless, or the player themselves is hopelessly worse at playing than their competitors are, or because the player has been knocked out of play, it's just generally a bad idea.
|
|
#
¿
Dec 6, 2013 20:52
|
|
|
So how would you change Monopoly? Some random ideas: * Replace the territories with toll roads -- instead of paying when you land on them, you pay when you pass them. Toll roads are grouped by color, but the distribution of those colors varies (e.g. one color might exist on only one tile on the board, while another shows up three times, but scattered across the board). * At the beginning of the game, and at regular intervals afterwards, control of all tolls is auctioned off; the entire board is thus always owned (unless everyone passes in the auction). Tolls are sold in blocks (i.e. all tiles of a shared color). * Players choose how many tiles forwards to move each turn (up to a limit?) * Money paid to tolls is placed on the toll tiles; in order to collect you must a) own the tile, and b) land on or pass the tile. Money stays on the tile when auctions occur! * Chance / Community Chest must be landed on to gain the benefits, as usual. * The game ends either when one player hits a money-in-hand goal, or after a set number of turns (at which point the player with the most money in hand wins) I couldn't figure out a good way to work in jail, nor the tile upgrading system, given that the tolls have to change hands regularly (which I felt was necessary both as a money sink and to introduce some risk to leaving money on tolls). Obviously this would play very differently from Monopoly, but it's still recognizable. The taxes and most of Chance and Community Chest could work as normal, as would the allowance from the Go tile.
|
|
#
¿
Dec 6, 2013 21:10
|
|
|
The Cheshire Cat posted:[The lack of catchup mechanic is] something that's so common that it's REALLY hard to find good counterexamples. Power Grid mucks with the turn order each turn: the player with the best board position (most houses / strongest power plants) gets the worst turn order, and vice versa. This is reasonably effective; you have to be doing extremely well to be able to just barrel ahead and win despite always having the worst turn order. Players can still get boxed in on the map though, leaving them with a great turn order but nothing to do with it. More social games like Settlers or Chinatown (a trading game) provide catchup mechanics in the sense that players who have a strong position will have trouble finding people willing to make trades with them, or will end up having to make unfavorable trades. This doesn't so much boost the losers as it does penalize the winners, but the net effect is similar. Unreal Tournament has a mode where the better your kills:deaths ratio, the fatter your model becomes. Players who are sucking at the game become stick figures that are nearly impossible to hit (outside of splash damage effects) while the godly players look like the Michelin Man.
|
|
#
¿
Dec 6, 2013 21:38
|
|
|
The Cheshire Cat posted:Can anyone recommend some simple Blender tutorials for someone who knows next to nothing about modelling? I'm not expecting to ever be really good at modelling (I just don't have the artistic talent for it and I'm not really interested enough to develop it), but I'd like to at least be able to put together some really simple stuff that I could use in Unity for practice projects. In addition to whatever guides you end up using, I strongly recommend going to #blender on irc.freenode.net; in my experience the guys there are quite helpful for questions like "I want to chop an edge in half; how the hell do I do that?" and so on. Stuff that's hard to google for if you don't know the right terms, especially since last I checked you can still pull up obsolete documentation (for versions from before they completely redid the UI) in Google.
|
|
#
¿
Dec 10, 2013 17:48
|
|
|
Something that will help is to make certain that most things you do have some kind of visible "reward" when they're completed. For example, the reward for implementing your basic physics is getting to control a guy who runs and jumps around and hits walls and so on. The reward for implementing your first enemy is having a dude in the game that chases your guy as he runs and jumps. Break your tasks down into things you can reasonably implement in a few hours, and try to have regular goalposts where you can sit back and "play" your game for a bit.
|
|
#
¿
Dec 10, 2013 21:03
|
|
|
poemdexter posted:Do you have the project on github or any way I can take a look? I eventually want to start looking at cellular automata as a way to generate caves in 2D games and this might be a useful tool for visualizing. Reminds me of a project I kept an eye on for awhile (seems to have died though; pity). Check this out.
|
|
#
¿
Dec 11, 2013 21:39
|
|
|
Yeah, I'd say just snap from one animation state to the other. You might consider having a "skid to stop" state to transition from running to idle, though. The nice thing about skidding is that it only takes one frame of animation anyway.
|
|
#
¿
Dec 13, 2013 17:27
|
|
|
Pollyanna posted:Say I want to make an in-browser game. Will Javascript suffice? What library(?) should I use for 2D game development in Javascript? You can probably do things in Javascript, but as far as I'm aware it doesn't have the usual event model that most games rely on. If you want to do a menu/button-based game (e.g. a board game or most RPGs) then you'd be fine, though. Your alternatives are HTML5 and Flash; I guess you could do a Java applet but anyone remotely sane should have disabled Java in their browsers years ago.
|
|
#
¿
Dec 14, 2013 01:56
|
|
|
Philthy posted:Is Unity the go-to tool if you want Windows/OSX/IOS without banging your head against the wall? It looks expensive as hell, but I'm getting pretty fed up with trying to make SDL2, SFML, and irrlicht work across all the platforms. I can get one to work great with Windows, but then you get stuck watching XCode choke on piles of frameworks, or something renders wrong. I want to murder. Dunno about iOS, but years ago I was able to get a game working on OSX and Windows that used Python and PyGame (basically SDL on Python) without especial difficulty. Not having a compile step when building the program is probably a big part of that.
|
|
#
¿
Dec 17, 2013 02:32
|
|
|
Angry_Ed posted:The problem is now I'm worried that my detail on things like the background will outstrip or not mesh well with the rest of how things look, especially the deliberately low-poly, basic look of my table, paddles, and blocks. I am not a good artist or 3D modeler by any means so what I can do is kind of limited, but I'm also trying to avoid going the full pixel-art/minecraft-esque style direction cause I know that's kind of played out by now. Throw some procedural textures at it. Procedural texturing has been around for ages and thus doesn't look horribly out of place next to low-poly models.
|
|
#
¿
Dec 18, 2013 23:15
|
|
|
JossiRossi posted:I feel like the segments "open" the wrong way. Where the shell has gaps they would act as scoops. So if it was moving in sand or dirt it would get lots of particles stuck in it. I think in nature you see segmented bugs/worms they usually have either totally smooth fitting shell segments, or ones that will have gaps facing away from the typical direction of movement. Easy fix: the worm's moving to the left instead of to the right. That does mean that it's butt is toothed, though. Oh well.
|
|
#
¿
Dec 19, 2013 17:52
|
|
|
I haven't actually tried this, but something you could try for the worm is giving the first segment (the head) an angle and velocity which it uses to adjust its position, and having each following segment just "chase" the segment immediately before that. You should be able to get a sinusoidal movement pattern if you want it by just swinging the angle back and forth (e.g. move from 0 degrees to 45 degrees, then back to 0, etc. over the course of a few seconds). And if the worm runs into something then you just adjust the angle of the head segment and set it on its way again; the following segments should adjust automatically. I believe in reality a swimmer that uses sinusoidal motion actually keeps the head relatively stationary and wiggles everything starting a few segments behind the head, but that's just a detail.
|
|
#
¿
Dec 19, 2013 23:58
|
|
|
Forer posted:
Man, making "stupid" weapons is clearly your forte. What you need to do is instead figure out how to build the levels around the use of this thing.
|
|
#
¿
Dec 22, 2013 17:49
|
|
|
Philthy posted:I'd like to generate piles of random dungeons, but they'll need to be stored throughout the game. If you don't need to store details about the dungeon state, you can always regenerate it by just storing the RNG seed you used. If you do, well, serialization is a well-studied topic. Pick a format you like (preferably not XML) and write serializers and deserializers for your objects.
|
|
#
¿
Dec 25, 2013 20:12
|
|
|
Lucid Dream posted:I posted a bunch of gifs on our site that I've collected over the last couple weeks, this one is my favorite: A man and a weird carnivorous plant, both immortal, trading the same spike back and forth forever. This is what eternity looks like.
|
|
#
¿
Dec 29, 2013 16:06
|
|
|
Has anyone tried combining a Wiimote+ (or other position/orientation "wand" device) with the OR? That would seem to me to be the natural way to handle sight and aiming. Movement would be with an analog stick, relative to your current facing.
|
|
#
¿
Dec 30, 2013 23:10
|
|
|
Bert of the Forest posted:Also, this sounds great! I tried accessing the channel via Mibbit, but there didn't appear to be anyone there. Perhaps I am going about trying to get into the channel the wrong way. Can't say I've ever used an IRC channel before but Mibbit seemed to be the only way I could see it as Chrome simply gave me a blank page when I typed in the little irc address given. I'd love to join in on the discussion, so if anyone knows how I can do so, that'd be good to know. I don't know how familiar you are with IRC; the simplest way this could have gone wrong in the way you describe is that you connected to the wrong IRC server. When you try to join a channel on a server, the server will create it if it doesn't already exist, which of course means that there won't be anyone else in it. Alternately, you misspelled the channel name, which would have the same effect. I don't believe channel names are case-sensitive, but you do need the # at the beginning of the name.
|
|
#
¿
Dec 31, 2013 16:24
|
|
|
DStecks posted:Uh... probably stupid question here, but can GTK# be used to create game graphics, or is it strictly a GUI system? If it's anything like other widget libraries then it probably provides a generic canvas object that you can draw on using OpenGL or whatever. So sure, you could run a game from within it if you wanted to.
|
|
#
¿
Jan 8, 2014 03:29
|
|
|
Peewi posted:I assume that indexing objects by position and then only checking for collision with a list of nearby objects instead of all objects would give a decent performance boost. Yep, some kind of positional-based data structure isn't uncommon. For 2D games you can make a quadtree, which basically recursively divides the world up into quadrants. Or you can just have a list where the contents are sorted by, say, X position. It doesn't provide quite as relevant of results as a quadtree would but it's a lot easier to implement.
|
|
#
¿
Jan 11, 2014 19:34
|
|
|
Philthy posted:What does this even mean? I guess I have no context in what you're trying to do. Level transitions are mostly fade to black, load new scene, fade in. Done. He means loading a new scene in the background (in another thread, presumably) so that there's no loading delay. You can just do a fast wipe or something from one scene to the next.
|
|
#
¿
Jan 11, 2014 22:01
|
|
|
deck posted:Slingray now I'm reminded of the Ball game mode in Altitude. What kind of game is this?
|
|
#
¿
Jan 16, 2014 02:25
|
|
|
StickFigs posted:How does indexing improve performance? Do you skip collision checks for objects with a higher index than a certain number? You can say "Clearly collision is impossible between these two objects, as they are far apart in the data structure", and thus can skip doing even an axis-aligned bounding box check. The main problem with naive collision detection is the n^2 growth in the number of checks (as each object is checked against each other object); a data structure that allows you to automatically ignore most checks greatly improves performance.
|
|
#
¿
Jan 16, 2014 22:42
|
|
|
I'd say the first one, since the pistols are already blocking off part of your view, so it doesn't really matter if the overlay blocks the pistols. You say the pistols move a lot, but presumably they spend little if any time covering the top 15% of the screen, so the second option loses you effective "real estate" by comparison.
|
|
#
¿
Jan 17, 2014 06:01
|
|
|
You absolutely can commit binary files to a Mercurial or GitHub repo, but as mentioned earlier on it may not scale very well if you have a lot of assets. As for Bitbucket, I suspect they're mostly just saying "Dude, we don't want to be your personal fileserver." Keep things reasonably under control and I doubt they'll care.
|
|
#
¿
Jan 21, 2014 15:58
|
|
|
The Radix posted:Sorry if I implied plasmid powers are planned: they were earlier on, but since they'd need to work differently to every other planned weapon set, or at least necessitate dual-wielding, they were dropped. With the exception of those and the Reedeemer and Shock Rifle from Unreal (dropped for similar reasons) there's a weapon inspired by just about every iconic gun I could think of, though. I can definitely see the problem with the Redeemer (needing a completely different control system and UI), but what's the problem with the Shock Rifle? You just need to have varying damage types for different weapons (which I could see being useful in a number of contexts) and then make the orb projectile react to taking shock damage by exploding.
|
|
#
¿
Jan 22, 2014 03:00
|
|
|
Ah, I hadn't realized you weren't doing secondary fire modes at all. I always liked them in UT but it's really easy to get lazy about them ("it's identical to the primary fire except the projectiles are less accurate/are affected by gravity/are bigger and slower/etc.") so I can understand not having them by default. If you have room in the control scheme though, it'd be nice to have some weapons have alt-fire modes.
|
|
#
¿
Jan 22, 2014 03:44
|
|
|
Shalinor posted:You need to do a 10 minute dubstep dance trailer of your little dudes doing nothing but randomly head bobbing like that. I was gonna say that they need to sometimes randomly get a pair of headphones for their idle animations. Or a glowstick to twirl.
|
|
#
¿
Jan 22, 2014 17:03
|
|
|
The Radix posted:I'm not sure I get what this pic is demonstrating. Line-of-sight vision that only applies to walls and not floors? Not so much line of sight, just not showing tiles that cannot possibly be relevant because they are already surrounded on all sides by walls.
|
|
#
¿
Jan 24, 2014 00:48
|
|
|
D_W posted:Loving these Candy Jam games. I haven't quite started mine yet because I've working on a different project, but I know what I'll be doing. It'll be a horror game where players must run away from the Candy King while collecting all the candies in a level. Probably a top down game with 4 directional movement, dumb pixel art, and super creepy ambient industrial music. So...Pac-Man?
|
|
#
¿
Jan 26, 2014 17:15
|
|
|
TomR posted:My Kickstarter is active now. You can see the KS here http://kck.st/1crtm1z "Dynamic animated horses" is a caption right below horses being spawned out of nowhere and awkwardly shuffled off the field of view. That implies to me that the jerky horse sliding is the "animation" being described. I assume the animation is actually some kind of 3D armature-based animation; having a GIF of a horse in action would be good. I'd also suggest moving the "About Horse World" bit to above the "Screenshots" bit, so people have some idea what your KS is for. Otherwise, looks good and good luck!
|
|
#
¿
Jan 28, 2014 23:55
|
|
|
|
| # ¿ May 22, 2024 02:12 |
|
|
I had a random idea the other day that I think would be pretty neat if done well. But I'm never gonna do it myself. Essentially it's to "crowdsource" the act of writing a game AI. You'd take a fairly simple combat system, like for an FF-style RPG or something, and code up a basic (i.e. easily-beaten) AI for it. Then you have the game observe how the player deals with different permutations of enemies. And then you take the actions the player used, and turn them against the player (e.g. if the player prioritizes attacking the enemy mage, then the AI learns to prioritize attacking the player mage). Then, and this is the clever bit, you network all of this, centralize the AI learning, and build up a set of AI tiers. Each individual player starts out playing against the basic actual AI (the level-0 AI), but as they figure out how to beat that, they get shunted up to the level-1 AI (i.e. the actions that other players took to beat the level-0 AI). And when they can beat that, they get pushed up to fight the level-2 AI, which is based on the actions other players used to beat the level-1 AI. If you can do this well, then what you'd see, I think, is that each tier of the AI would consist of a set of strategies that the player would learn to counter -- and then the next tier's AI would know the counters to the strategies the player used to counter the previous tier AI. The main problem is figuring out how to write a combat system with sufficient depth to enable that kind of strategy/counter-strategy/counter-counter strategy thing while still being simple enough that you can turn player actions into rules that the AI can "learn".
|
|
#
¿
Feb 6, 2014 06:06
|
|