|
Sylink posted:Is there a good 2D game engine available that is cross platform and not XNA? I don't want to build my own engine through SDL.
|
#
?
Oct 24, 2013 19:43
|
|
|
|
| # ? Jun 13, 2024 05:20 |
|
|
I've been working on my game on and off, in what free time I have left over after generally trying to have a functional life, which turns out not to be a lot of time   The last few months have mostly been back-end stuff that doesn't carry over into screenshots. Messing around with the procedural terrain generator is probably the most rewarding thing for me, but I could spend a lifetime doing just that and never end up with a playable game...  For reference, here's what it looked like a year ago... 
Mata fucked around with this message at 21:41 on Oct 24, 2013 |
|
#
?
Oct 24, 2013 21:27
|
|
|
I've been messing around in Unity3D/Toolkit2D for a bit, and I've finally got a paddle moving, a ball bouncing, a beep beeping and a score incrementing. Amazing how, despite being a programmer for many years, whenever you start in a new language and do some ultra-basic stuff, you always end up grinning like an idiot. The joys of doing something new and fun 
|
|
#
?
Oct 24, 2013 23:42
|
|
|
Mata posted:Messing around with the procedural terrain generator is probably the most rewarding thing for me, but I could spend a lifetime doing just that and never end up with a playable game... Your terrain is seriously amazaballs fantastic. That's like simcity 4 level polished terrain IMO.
|
|
#
?
Oct 25, 2013 00:00
|
|
|
Mata posted:I've been working on my game on and off, in what free time I have left over after generally trying to have a functional life, which turns out not to be a lot of time Wow, I am REALLY interested in this. Is this some kind of city building game, by chance?
|
|
#
?
Oct 25, 2013 00:03
|
|
|
Mata posted:I've been working on my game on and off, in what free time I have left over after generally trying to have a functional life, which turns out not to be a lot of time Your terrain looks awesome. Mind giving an overview of how you did it? I'm about to embark on something similar myself. It is 100% procedural? Can you edit it on the fly? Like - raise lower areas with the mouse, paint on textures, etc?
|
|
#
?
Oct 25, 2013 00:06
|
|
|
HaB posted:Your terrain looks awesome. Mind giving an overview of how you did it? I'm about to embark on something similar myself. It is 100% procedural? Can you edit it on the fly? Like - raise lower areas with the mouse, paint on textures, etc? Thanks  ! It's all simplex noise... Making tutorial standard simplex noise with a constant amplitude and frequency, varied by octave gives you a decent but bland starting point. I've gotten some interesting and organic shapes out of feeding simplex/perlin noise back into itself though, like having the output of the first octave modulate the input of the lower octaves. Maybe feed a basic simplex noise in as the "amplitude" parameter in the next iteration, so instead of having an amplitude of "2" it will be a smooth function yielding output between 1 and 3 depending on your coordinate input parameters. Maybe have the output of THAT octave modulate the x and y input of the next octave? Who knows what will happen!  Mess around with this stuff for a while and you start getting really wild and unpredictable results. I played with it until I got something that was pretty mountaneous, which is my Mountains biome. Then I have another simplex noise function that determines the interpolation between biomes -- in that screenshot you see the grasslands biome, with the mountains biome shining through at some points, determined by yet another simplex noise function. I could write a long time about this but my approach has been extremely unscientific and amounts to just messing around until I find something I can use. Once you have many layers of feedback loops it becomes completely impossible to predict what will change when you tweak a variable a little. The terrain and texture maps are not editable in the game client yet, but I eventually want the player to be able to dig trenches and build dikes, but I have other priorities first. After all, what's the point of having editable terrain if there's no water simulation?  Zarikov posted:Wow, I am REALLY interested in this. Is this some kind of city building game, by chance? This kind of reassurance is why I post screenshots every now and then... It's a weird fusion of game ideas I've had, right now it's mostly a resource-gathering RTS with a focus on exploring and trading with npc settlements / other players. Not as combat oriented as most RTSes but definitely not a hardcore city sim either. Mata fucked around with this message at 17:02 on Oct 25, 2013 |
|
#
?
Oct 25, 2013 16:56
|
|
|
Is there an idiots guide to networking for something like a 2 player RTS? Right now I'm sort of doing command pattern with commands timestamped and serialized back and forth, plus some simple syncing and sanity checking, but there is probably a better way. It also seems that if you want multiplayer, it really has to be designed for that from the very beginning. Is there an easy way to abstract networking so it doesn't have a huge impact on the basic singleplayer gameplay?
|
|
#
?
Oct 25, 2013 17:46
|
|
|
more like dICK posted:Is there an idiots guide to networking for something like a 2 player RTS? Right now I'm sort of doing command pattern with commands timestamped and serialized back and forth, plus some simple syncing and sanity checking, but there is probably a better way. It also seems that if you want multiplayer, it really has to be designed for that from the very beginning. Is there an easy way to abstract networking so it doesn't have a huge impact on the basic singleplayer gameplay? This is a pretty good article that describes the synchronized lockstep algorithm, if you haven't seen it already. This pattern is as you describe. Your client would create a command on tick 100, sends it to the server which in turn distributes it to all clients and tells them all to execute it on tick 104. As to your second question, probably not... I built my game using client/server architecture from the start, and a transport layer that can be either be a TCP connection or a carrier pigeon or any class that exposes my connection interface. A local game creates a server thread and a client thread in the same process and the transport layer is just a really simple class that facilitates communication between the two. In a multiplayer game it's the same thing except the server thread may be running on a remote computer but the client thread doesn't need to know that. I wouldn't call it simple though. Mata fucked around with this message at 18:22 on Oct 25, 2013 |
|
#
?
Oct 25, 2013 18:19
|
|
|
more like dICK posted:Is there an idiots guide to networking for something like a 2 player RTS? Right now I'm sort of doing command pattern with commands timestamped and serialized back and forth, plus some simple syncing and sanity checking, but there is probably a better way. It also seems that if you want multiplayer, it really has to be designed for that from the very beginning. Is there an easy way to abstract networking so it doesn't have a huge impact on the basic singleplayer gameplay? This model is the simplest and also doesn't interfere with single player; you just get a very fast turnaround for the instructions when the server is the local machine. If you want to make it play fair when the server is one of the player's machines, then you just need to measure the players' ping times and add (longestping-yourping+margin) extra delay to every player's commands. A simple but not very efficient way to keep it all in sync is to add a (longest ping time + margin) timestamp delay to every instruction, send out "nothing else happened" updates every (margin), and pause the game whenever a client hasn't received any timestamps "in the future". If you don't do it that way then you have to be able to either do "poo poo, a newly received command was supposed to start happening in the past, now I have to rewind to that time and play out the new history", which is generally a lot more complicated, or "poo poo, a newly received command was supposed to start happening in the past, now I have to get an entire current gamestate of everything that can change to get back in sync", which is somewhere between the two in complexity. (But these models are more closely adaptable to other genres where control lag is really bad.) roomforthetuna fucked around with this message at 18:43 on Oct 25, 2013 |
|
#
?
Oct 25, 2013 18:40
|
|
|
It's worth noting that this deterministic style of multiplayer is almost identical to a replay system. Also that since you need to be able to package up a complete game state (to send to clients when they join or to begin a replay), the same code can build a checksum of the game state which you then use for validation. This makes tracking down determinism bugs much easier.
|
|
#
?
Oct 25, 2013 20:21
|
|
|
All those posts are very helpful, thank you. The more I think this through the more I feel that I should downsize this for the sake of actually finishing a project for once.
|
|
#
?
Oct 25, 2013 21:12
|
|
|
I've been working on a TRPG for the past 6-8 months during my free time. I could use some first impression feedback/comments.
|
|
#
?
Oct 26, 2013 03:45
|
|
|
From having not played the game at all I can say that all those bars onscreen are sort of cluttered and confusing looking. I see that you've got blood spatters on the ground which tells me some guys have been hurt, but it'd be cool if the sprites changed based on how hurt a guy is. That way you can maybe get a better idea of who's hurting quicker. Looks really good though!
|
|
#
?
Oct 26, 2013 04:19
|
|
|
Tres Burritos posted:From having not played the game at all I can say that all those bars onscreen are sort of cluttered and confusing looking. Thanks man. The bars you see on the units can be toggled on and off. Or can be shown by holding ctrl depending on the option. I left them on in the screenshot because I wondered if someone would mention it. Quick explanation of some of the bars, The brown/white/gray boxes is the unit's armor. It acts as a health bar, but only protects from a specific damage type. Gray = slashing, white = piercing, brown = blunt etc. So for example once you lose all your slash protection, any slash damage you take will go to your hp. The whole combat system is based around that meta and I think it will work out. But that depends on how confusing people find it.
|
|
#
?
Oct 26, 2013 04:34
|
|
|
Looks interesting. The units can blend into the background a lot - skeletons & white tiles in that screenshot. Maybe a dark grey outline around units? If the game is roughly playable you should start getting people to play it and give feedback. I've been doing this from very early on in development and it's good for both feedback and marketing. Eg here's post I made on reddit/r/playmygame last week: http://www.reddit.com/r/playmygame/comments/1p1usb/alpha_guild_of_dungeoneering/ retro sexual fucked around with this message at 12:03 on Oct 27, 2013 |
|
#
?
Oct 27, 2013 11:38
|
|
|
A few quick thoughts: 1) Maybe move the Armor bars at the bottom and place them horizontally over the unit's information. Leaves more open space between the units 'card' and the action/AP buttons. Also would keep the unit's stats more tightly clustered instead of sprawling out. 2) It is a bit hard to tell at a quick glance which units are enemies, and which are allies. A 1px dark outline around units and/or colouring enemies with more red (for example, skeletons pants). Good example of why the 1px dark outline might be necessary is the currently selected Knight's helmet is really hard to differentiate (at a glance) against the water and skeleton's legs. 3) In general I think the contrast between colours is a bit low. Example is the red Attack boxes; could try making the darker outline darker, or less transparent. 4) On the unit cards, the skeleton blends in with the background like crazy. Maybe make the background slightly transparent, although the 1px dark border, if it works out, might fix this issue anyways. 5) For the green vertical bars, I'm guessing the black bars are 'used up'? Might want to make them slightly transparent or something to make that a little more clear. Anyways, those are just some thoughts. I'm not an expert so there's a decent chance something I've said here is stupid but hopefully this helps you. I'm a huge fan of Turn-Based Strategy games like Fire Emblem, Advance Wars, etc and I think what you've got so far already looks cool as hell.
|
|
#
?
Oct 30, 2013 06:19
|
|
|
Faldoncow posted:A few quick thoughts: Thanks a lot! Unfortunately, I agree with you about the outline, and its something I will have to add. I also agree with you about the transparency. And theres no stupid comments there, thanks for your feedback!
|
|
#
?
Oct 30, 2013 13:42
|
|
|
What are you building it with? It could be really simple to add the outline in code
|
|
#
?
Oct 30, 2013 14:46
|
|
|
Does any body have any tips or links to tips on how to interpret the Unity profiler. In particular the memory and CPU usage.
|
|
#
?
Oct 30, 2013 20:28
|
|
|
xgalaxy posted:Does any body have any tips or links to tips on how to interpret the Unity profiler. In particular the memory and CPU usage. CPU is pretty easy. There are percentages (Total and Self columns) that describe the percentage of total CPU frame time a particular function takes, while the ms (Time ms and Self ms) describe the actual time they take in milliseconds. Self in either category means how much time the function itself takes, not taking into account of other functions it may have called. Say there is Foo (which calls Bar and Baz), which under "Time ms" says 10, but "Self ms" says 2. That means Foo, without the calls to Bar and Baz, takes 2 milliseconds. If you open up the function call, it'll try to list other calls to functions that function has made. "Calls" describe how many times it's been called for that frame. The times reported is not on a per call basis, so if Foo had 5 calls, that means each call to Foo takes 2 milliseconds maybe. "GC Alloc" is pretty important. It reports the total amount of memory the function allocated from managed memory in that frame. It doesn't necessarily mean the amount of memory that will be collected by the garbage collector, but if some function allocates some amount of memory frame after frame, then its most likely that function is producing garbage. This does not include stuff that are natively allocated, like textures, meshes and so forth. When selecting a function, it should list what GameObjects have been calling it on the right, with the same columns of data reporting it on a per-GameObject-call basis. In the "CPU Usage" box full of the color coded keys that describe the graph next to it, you can click any of them to toggle them on or off from being displayed in the performance graph. I usually turn everything except Scripts and GarbageCollector when hunting for leaky scripts. Some of the other profiler graphs have this feature as well. Selecting Deep Profile will try to get as much information as possible on the whole, or you can use Profiler.BeginSample and Profile.EndSample on a piece of code to get the same info Deep Profile would get. I don't know much about the memory profiler than what I take at face value. Total being the total amount of allocated memory, textures for textures, etc. It's something I have to look into eventually myself since I need to lower memory usage of my current project. EDIT: this is all based on Unity 3.5.7. I think 4 has some nicer stuff but I haven't starting working too much with 4 yet. ShinAli fucked around with this message at 00:48 on Oct 31, 2013 |
|
#
?
Oct 31, 2013 00:36
|
|
|
So I'm messing around with 2D Toolkit creating a simple top-down game just to learn some things. I'm using a character controller for the player and I have the camera following its movement with a slight delay. The problem is that I'm using a td2k riled sprite for the floor and when the camera moves I can see through the seams in the sprites. Why is this and what can I do to prevent it? All of my sprites are stored in a single sprite collection and it doesn't seem like messing with padding is having any effect.
|
|
#
?
Oct 31, 2013 16:07
|
|
|
I never used tiling in 2d Toolkit so I don't know how much control you get, but you might have to overlap the tiles ever so slightly. You also want to set Pad Method to Extend in the Collection Editor. vvv Great! Glad it worked! superh fucked around with this message at 17:11 on Oct 31, 2013 |
|
#
?
Oct 31, 2013 16:11
|
|
|
Yep that was it! I didn't realize that I could set padding and pad method on a per-sprite basis, I was looking in the global collection settings. 1 pixel extended did it and it looks fine. Thanks!
|
|
#
?
Oct 31, 2013 16:47
|
|
|
Yodzilla posted:Yep that was it! I didn't realize that I could set padding and pad method on a per-sprite basis, I was looking in the global collection settings. 1 pixel extended did it and it looks fine. Thanks! Yeah, I've found it's pretty important to pay attention to the suggested padding settings for various things in 2D Toolkit. Unlike a lot of stuff I've worked with, they actually seem to have some really good reasons for the suggested settings (which is a nice change from the usual).
|
|
#
?
Oct 31, 2013 20:15
|
|
|
Yeah now I just have to figure out what's going on with the tiled sprite and lighting. Sometimes it just...wigs the gently caress out for no apparent reason. PRO TIP: setting light render mode to Auto instead of Important can cause all kinds of hosed up poo poo! Yodzilla fucked around with this message at 01:41 on Nov 1, 2013 |
|
#
?
Oct 31, 2013 23:16
|
|
|
Mata posted:I could write a long time about this but my approach has been extremely unscientific and amounts to just messing around until I find something I can use. Once you have many layers of feedback loops it becomes completely impossible to predict what will change when you tweak a variable a little. Great looking terrain, you can easily lose yourself in just making terrain generators  Here is a trick I learnt from a very old book on fractals that you might find useful. For different biomes, try scaling all the heights by a powf( height, power ) function (after normalising the heights first so the heights are 0 -> 1 for this & rescaling back afterwards). If you use a power > 1, then the gradients near the peaks get steeper, and you get some lovely ice-carved rugged mountain shapes. With a power <1, you get a high plateaus with deep ravines and rolling hills (also very good for underwater terrain with flattened shelves and trenches)
|
|
#
?
Nov 1, 2013 13:42
|
|
|
Hm. I was thinking about how to structure a certain type of game and I came to get some input on what you'd think would be the best way to do it. Imagine a tile based game such as Ragnarok Online  Or like Disgaea     My question is, how would you personally do the maps for these games? My thinking is that, while some of them can use tiles (like the Item World in disgaea, since it's randomly generated), most of the levels involve unique setpieces or models (stairs, chains, etc) and this would be wasteful. The best way to do it, would be to probably just load the level as-is, since the levels are small enough to be loaded as an entire model (perhaps some instancing like chains, but even then, not very neccesary), and are pretty lowpoly (and even if they were highpoly, these days that doesn't really matter). Here's the naive way I'd think about doing it at first: On top of that model, I'd think you'd have a node system. So you'd have a node designating where people can stand, and connections between the nodes to designate such things like "Jump down". The problem arises when you think about the cursor the game draws on the ground when you select things, or general tile overlays. The cursor is a texture but it aligns all four corners to the tile corners. So if it's on the floor, that "square" would be taken up by the selection cursor. If the floor is raised in one corner, the cursor would be also raised in that corner. On something like a staircase, which isn't a completely flat surface, the cursor would align itself to the rough slope the stairs follow (and clip through the stairs a little). The cursor can also move along things you can't even stand on, such as lava below. This makes me think there's some kind of mesh that it follows, where each polygon is a "space", and the polygons are somehow designated to be able to be stood upon or not, but then the issue is: How would you designate these things, how do you do nodes such as "Jump down here". The other big problem with a polygon mesh like that is: Everything has to be on a grid, so if someone accidentally moved a vertex off the grid, what happens? Also; having a mesh like that means you have to manually take care of it, so if you change the visual level it might be a problem to change the mesh (though, this carries over to nodes too). I'm stumped as to what would be done here, really, and would like some feedback! Some more, less necessary info past this point that might help you think how they did it a little more: The overlays conform themselves entirely to the tile, but not if a detail model is on top of them, such as this:  This leads me to believe that maybe the textured mesh you walk on is the same mesh that's used to designate where the overlays go, with details added on top via other model set pieces? The later games have level editors, which let you place down basic tiles at whatever height you want, some of which not even being square. Overall what I can really think of is maybe there's both. Maybe there's the mesh for overlays and the node system (an array with connections) are two separate things, so each "node" has a height, links (with instructions whether to Jump Down here, or normal path, etc. No path means you can't move there), and a designating polygon on which to draw the overlay on? Possible. That would solve a lot of problems. And here's some gameplay to see it in motion. https://www.youtube.com/watch?v=oz3JY-w3_P8 ------------------------------------------ Edit: So after discussing it with some people, this is what I think it might boil down to:
So then if the cursor's at (5, 3) you have a mesh to draw overlays and you have a node in which you can path to and stand at and such. I'm pretty sure this is done but I don't know if there's any pitfalls with this method. Also someone linked http://gomtuu.org/fft/Ganesha/ which I'm going to check out tomorrow. Edit 2: A potential pitfall would be in http://i.imgur.com/Gp4JNCP.png where the tile you select isn't completely square. So maybe the tiles for the overlays aren't visible. The downside with that is you'd have to make sure the tiles you can stand on and the tiles that are visible are always the same if you make changes to one. But I guess it's the same with the nodes too. Edit 3: After fooling around with Ganesha and reading the docs: quote:First, you should understand that polygons are entirely cosmetic in Final Fantasy Tactics. This means that the placement and appearance of polygons doesn't affect the heights and depths of tiles, the materials they're made of, and so on. A polygon can be anywhere and look like anything, and it doesn't affect gameplay (unless it happens to obscure a monster or something). To edit terrain, which does directly affect gameplay, see the next section. So they use that system. The updated system, then, is:
Jewel fucked around with this message at 16:04 on Nov 1, 2013 |
|
#
?
Nov 1, 2013 14:21
|
|
|
Jewel posted:Overall what I can really think of is maybe there's both. Maybe there's the mesh for overlays and the node system (an array with connections) are two separate things, so each "node" has a height, links (with instructions whether to Jump Down here, or normal path, etc. No path means you can't move there), and a designating polygon on which to draw the overlay on? Possible. That would solve a lot of problems. I don't see why not. That seems perfectly logical, and like you said would be necessary. If you're willing to state as a limitation that all tiles have to be flat, or that they have to be at least a straight slope (allowing for angled surfaces) which I think was a limitation on FF Tactics, then you could get by with probably just a node list with a height and angle value for each, and then draw the cursor that way.
|
|
#
?
Nov 1, 2013 15:37
|
|
|
Last post about it before I go to bed: I tried out that FF Tactics maps editor and it seems they use predefined tiles, as Zaphod42 said above. You have polygons, visual geometry for detail, and you have terrain, the bulk, where objects can move to. Each of those tiles have:
Is there an advantage to doing it this way, rather than having a mesh do the work for you? There might have been back in the GBA days but I don't see much advantage currently, and I'm interested if I'm missing something major, once again. Here's what their map looks like:   I'm guessing the main upside from this method is that you already have a grid of Tile Types so you don't have to worry about the mesh not being in a grid, or nodes? Hm. Would you say Disgaea did the same thing? Edit: One last note appended to the end: If you did go with this workflow what's the best way to go about it? Making a model and using a level editor to manually line up tiles would be a pain  Perhaps make the tiles first then export that and model around it, though.. Though you'd need a lot of foresight or sketches to see how you want the level to look. Jewel fucked around with this message at 16:43 on Nov 1, 2013 |
|
#
?
Nov 1, 2013 16:26
|
|
|
Depth is likely for water, some tiles were only waist-high (you could attack from) and others neck-high. I'm fairly certain the Ragnarok system is the same in function, and the cursor just raycasts from the mouse to see if it hits a tile.
|
|
#
?
Nov 1, 2013 16:39
|
|
|
I haven't really played these games before, so bear with me. Assuming there's no "caves" where you can have two tiles with the same x,y position and different heights, the level's base terrain is simply a height map. That's how the cursor chooses what to go to. I'm also going to call the ability to stand on a tile that it "is navigable to", or that it has "navigability", since this is the common term in pathfinding. I don't know the behavior of slopes. Are they navigable? What's the behavior of the cursor in this case? I don't know if nodes like "jump down" are usually placed by the map designer or calculated based on the height difference. Let's say it doesn't really matter: we know when that when we navigate from A to B, we could jump down. I don't know if the "overlays" that the game places can be pass-through (perhaps a pond or something that you can stand in the edges of), it really depends on your game's design whether you want navigability on the overlay type or on the tile itself. Either is an acceptable approach. For pathfinding, you'd build a graph that you'd use A* on. You'd do this using the standard A* method taught in game dev tutorials: for every tile, build a directed edge to its nearest navigable neighbors, and apply a weight of some gameplay-oriented value. So really all you need to know is "is A navigable from B", which seems like a fairly simple test (is A navigable? is my height one more than the others? is there no special edge on the map saying this is one-way?) The weight here is interesting. Say that "Jump Down" takes two movement steps: we assign that edge for the "jump down" action a weight of two, instead of one, and now our pathfinding algorithm will always take the most efficient route in terms of in-game movement steps. That's all I can think of that's hard about this problem; it seems fairly straightforward to me otherwise?
|
|
#
?
Nov 1, 2013 16:50
|
|
|
So, one quick question about something I'm trying to get my head around. I'm doing a game in C++ as part of a project, and it seems like the easiest type would be something top down, probably a bullet-hell shooter, but everyone seems to have done a variation on this and I want to do something a bit different. I'm trying to come up with ways to do a platformer, but I can't think of an efficient way to do collisions with platforms. Seeing as the alpha byte on the screen was unused could I give the platforms an alpha value and do 'if(pixel under the player alpha ==0) player.xPosition--' to simulate gravity or something? And how would I do jumping in that case? Nothing has been set in stone yet, I'm just reaching out for some ideas on a good way to do it.
|
|
#
?
Nov 1, 2013 23:25
|
|
|
Praseodymi posted:So, one quick question about something I'm trying to get my head around. I'm doing a game in C++ as part of a project, and it seems like the easiest type would be something top down, probably a bullet-hell shooter, but everyone seems to have done a variation on this and I want to do something a bit different. I'm trying to come up with ways to do a platformer, but I can't think of an efficient way to do collisions with platforms. Seeing as the alpha byte on the screen was unused could I give the platforms an alpha value and do 'if(pixel under the player alpha ==0) player.xPosition--' to simulate gravity or something? And how would I do jumping in that case? Nothing has been set in stone yet, I'm just reaching out for some ideas on a good way to do it. Hey there! I've actually stumbled across something quite useful called Math for Game Developers on YouTube. He goes into detail on all of those things you've mentioned and a lot more in a better way than I could teach you.
|
|
#
?
Nov 1, 2013 23:31
|
|
|
Praseodymi posted:So, one quick question about something I'm trying to get my head around. I'm doing a game in C++ as part of a project, and it seems like the easiest type would be something top down, probably a bullet-hell shooter, but everyone seems to have done a variation on this and I want to do something a bit different. I'm trying to come up with ways to do a platformer, but I can't think of an efficient way to do collisions with platforms. Seeing as the alpha byte on the screen was unused could I give the platforms an alpha value and do 'if(pixel under the player alpha ==0) player.xPosition--' to simulate gravity or something? And how would I do jumping in that case? Nothing has been set in stone yet, I'm just reaching out for some ideas on a good way to do it. Maybe, but... you want to be able to check collisions between entities, which move, not just between entities and tiles, right? Otherwise you're going to have to check and update the alpha values every frame, for every pixel, which is way more math and a huge waste of calculations than just checking bounding boxes or however you want to do the collision between the objects you care about. There's no reason to make such an overly simple collision detection algorithm anyways. 2D math is pretty simple on modern computers, even smartphones. You can do an awful lot of collision checks in .01666 of a second. you should be able to check if any arbitrary object collides with another arbitrary object, regardless of if its a platform, enemy, character; whether its static or dynamic. Just compare bounding boxes if nothing else. (or you can use circles for an even easier check, although then its less accurate unless your objects are circles) Jumping involves doing 2D physics. You apply an initial velocity up, then you apply a gravity acceleration down, and you stop player movement when it collides with things. (Ceiling, floor, etc.) pretty basic collision detection, just google "2D collision detection" and there ya go, there's like a billion tutorials on the subject. Zaphod42 fucked around with this message at 23:59 on Nov 1, 2013 |
|
#
?
Nov 1, 2013 23:53
|
|
|
Thanks for the replies. I think I probably got a bit of tunnel vision on the subject and your responses helped. Just check the top/bottom and left/right of every object? It's all ints so that should be fairly efficient, right? Should I put all the entities into a vector and compare everyone to every other one?
|
|
#
?
Nov 2, 2013 00:15
|
|
|
Praseodymi posted:Thanks for the replies. I think I probably got a bit of tunnel vision on the subject and your responses helped. Just check the top/bottom and left/right of every object? It's all ints so that should be fairly efficient, right? Should I put all the entities into a vector and compare everyone to every other one? The reason I said to google "2d collision detection" is because when you do, the first thing that comes up is: http://devmag.org.za/2009/04/13/basic-collision-detection-in-2d-part-1/ Which explains everything you're asking perfectly, in depth. After that are other articles to the same effect. This has been covered a zillion times, its pretty common and basic stuff that all 2D games use. You'll probably want to use bounding boxes, like I said. Read the part in that article about bounding boxes, it'll explain the things to check for and optimizations you can make. As to which objects to check, Yes, the naive approach is just to keep track of all objects which can be collided with in a big vector, and then compare each against each other. But that's going to be sub-optimal. As I said though, with 2D stuff on modern machines, if this is running on a desktop, you can get away with that pretty easy (although, maybe not in a bullet hell). But you'll want to do some quick culling checks. You'll want to compare your moving player object and any other enemy sprites versus each other, and versus each tile they might bump into, but there's no reason to check if tiles that don't move collide with other tiles that don't move, for instance. Also, you can skip any that are further away than the longest axis of the bounding box; so if Mario is 2 units high and 1 unit wide, anything 3 or more units away obviously can't be touching, so skip those. Anything not currently in the camera space is probably safe to ignore for collisions, although maybe you want to consider the area immediately outside the camera. Etc. etc. Zaphod42 fucked around with this message at 03:40 on Nov 2, 2013 |
|
#
?
Nov 2, 2013 03:36
|
|
|
Manslaughter posted:I'm fairly certain the Ragnarok system is the same in function, and the cursor just raycasts from the mouse to see if it hits a tile. RO also had an important caveat, it doesn't account for height differences between tiles when determining navigability, so several maps with railless staircases (i.e. Clock Tower) required a tile-wide strip on the stairs to act as an invisible railing even though those spots visually appear to be walkable. I think the ideal system would be something like having 4 heights for each tile, a bit for which way the diagonal crosses it, and additional flags for whether it's traversable, obstructs visibility, obstructs movement, etc. Beyond that, other things to consider would be tile-edge obstructions (as opposed to only full-tile obstructions), and possibly having additional tile maps with edge links to each other, which would allow you to have overlapping tiles. There are a few advantages to using tiles over meshes, but a big one is that intersect checks are CHEAP. Areas of tilemaps are non-overlapping, so dividing them up into binary or quadtrees for intersection checks is trivial.
|
|
#
?
Nov 2, 2013 07:01
|
|
|
I've been "jamming" on a game for a few days now and I'm excited to show off a teaser shot Motherlode has a ways to go but it's starting to shape up and I'm in the middle of a proud parent moment 
|
|
#
?
Nov 3, 2013 05:03
|
|
|
|
| # ? Jun 13, 2024 05:20 |
|
|
I spent some time brainstorming some randomized algorithms for generating landmasses and got one that gives some nice looking results. The idea for this one is that it starts with a flat map, then identifies some peaks. Then it raises land by looking at elevated tiles and randomly decides to raise neighboring tiles (i.e. it takes each tile, looks at its neighbors that are lower and raises a percentage of them) and forcibly raising peaks. Then to generate an actual map I just take a slice at a specific height level, so the actual land are the tiles higher than some prescribed height. It's still pretty primitive, but it made some neat maps. I had the program output text-based graphics for now and the maps are intended to loop around at the boundaries like early RPGs:    Ideally I'd want to use this to code a simple exploration game, so the game would give a randomized map and your just wander around it, possibly with a boat to explore oceans too.
|
|
#
?
Nov 3, 2013 06:34
|
|
