|
Well, since this is a question I've been dealing with again and again, I thought I might as well post here. Basically, I have a very hard time deciding what language to do my game programming in. C# is what I'm most comfortable with, so XNA would be the natural choice, but I'd like at least the possibility to run the game on Linux as well. Basically, it comes down to the fact that it is hard finding a decent library that does all I need. Especially, I'd like a solid UI library etc., so I always think of the days when I was doing stuff in C++ and ClanLib offered all I needed. Graphics, Sound, GUI, networking etc., so I am always tempted to move back to that. However, C++ is more of a hassle, so stuff in general takes longer to write. I have even tried writing a SWIG wrapper around ClanLib, but their signal/slot-stuff was pretty much impossible to wrap and I gave up. With all other languages and game libraries, there seems to be a lot of library-hunting involved. I just haven't found a combination that works for me yet, maybe it is indeed time to try out a few more python options.
|
#
?
Nov 24, 2008 11:42
|
|
|
|
| # ? May 10, 2024 13:07 |
|
|
What about combining Ogre3d with something like Hikari? It allows you to design your GUI in Flash and the engine itself seems pretty robust as well.
|
|
#
?
Nov 24, 2008 12:58
|
|
|
Mithaldu posted:You get hung up on the wrong things and completely ignore the obvious thing that i can also do this and negate all your arguments about "weird" syntax order: I didn't ignore anything, except of course the things you didn't say. :P I also didn't suggest the changes you made because I recognize your original as very good Perl. "Mithaldu posted:Furthermore you ignore my original claim and act as if I'd said something else. I did no such thing. "Mithaldu posted:I agree there is no point in going on here. You know what, I also frequent the Python thread and I sort of got confused which one I was talking in. I definitely wouldn't have poo poo up the Game Dev thread with so much Perl vs. Python stuff if I would have realized earlier. Sorry, friends. 
tbradshaw fucked around with this message at 17:40 on Nov 24, 2008 |
|
#
?
Nov 24, 2008 17:37
|
|
|
Morpheus posted:Right, so I'm starting to add AI to my game (in C#), and I'm trying to figure out how. I mean, I know how to program an AI, it's about programming multiple variations of AI into a game, one for each type of enemy. At the moment I'm not entirely sure what to do, specifically from the coding perspective. I mean, I know how to program a single AI. That's easy. But I don't want to create a separate AI class for each type of enemy. I'm certain there's a way around this, possibly using delegates. Any tips? There was mention of finite-state-machines earlier, which sound pretty good, but it's all a question of implementation. Create a dynamic / hybrid class. Instead of explicitly coding a think() or whatever class, make it a function pointer and write callbacks which you plug into that function. Instead of having a bunch of class members, create a data dictionary (like an STL map or whatever) which you can plug values into at runtime. This is super-easy if you are using a higher-level language like Python. Wuntvor posted:I have even tried writing a SWIG wrapper around ClanLib, but their signal/slot-stuff was pretty much impossible to wrap and I gave up. Please explain, I was thinking of making a wrapper as well. Perhaps I can shed some light on it (and more likely, not). Panda3D is a good example of ClanLib for 3D: it is a one-stop-shop of sorts for most of what you need. The documentation is pretty bad, though, and it reeks of "this library was made for people who were being trained how to use it", so a lot of very simple stuff is not quite so obvious because the 'proper' way of doing it is undocumented. Sagacity posted:What about combining Ogre3d with something like Hikari? It allows you to design your GUI in Flash and the engine itself seems pretty robust as well. It's a good suggestion, but that counts as "library hunting" 
nihilocrat fucked around with this message at 21:18 on Nov 24, 2008 |
|
#
?
Nov 24, 2008 20:19
|
|
|
nihilocrat posted:Please explain, I was thinking of making a wrapper as well. Perhaps I can shed some light on it (and more likely, not). I don't quite remember at what point I gave up, I know I was able to at least call a few simple functions. I haven't really done a lot with function pointers, so maybe that's why I didn't see a way to wrap the signals/slots code. In theory, all you have to do is to convert a managed function pointer to a "normal" one (I think the Marshalling-class has a method for this), but I could never get it to work somehow. Writing about this, I really want to give it another try.. voodoo dog fucked around with this message at 21:12 on Nov 24, 2008 |
|
#
?
Nov 24, 2008 20:50
|
|
|
Wuntvor posted:blah blah .NET blah blah managed Wait, are you talking about wrapping good old C++ ClanLib with good old CPython? I have also discovered Py++ in the interim. Python-Ogre uses it, so perhaps it actually works well. I think a ClanLib wrapper would be great for the Python game development world. We've already got a large number of graphics libraries, but nothing that is a one-stop-shop. I hand-coded a ctypes wrapper around a C function that took function pointers a few years ago, and didn't have any issues. I was actually pretty amazed. I am also sort of having trouble finding a good engine/set of libraries and I'm feeling like I might want to roll my own. Of course, whenever I decide I might want to do something big I have to throw in a bunch of other requirements or froofy features. My idea was to use Ogre3D on top of a sort of "game OS" written in Stackless Python, where every process or game entity gets its own tasklet, following the MVC model to have clear seperation between presentation, control, and data throughout the entire engine.
|
|
#
?
Nov 24, 2008 21:26
|
|
|
nihilocrat posted:Wait, are you talking about wrapping good old C++ ClanLib with good old CPython? I have also discovered Py++ in the interim. Python-Ogre uses it, so perhaps it actually works well. I think a ClanLib wrapper would be great for the Python game development world. We've already got a large number of graphics libraries, but nothing that is a one-stop-shop. EDIT: Just tested it with what I've got from last time, and it does indeed seem to be working in Python as well. voodoo dog fucked around with this message at 21:56 on Nov 24, 2008 |
|
#
?
Nov 24, 2008 21:48
|
|
|
Oh. Yeah. For some reason I thought you mentioned Python in the post, it tells you how much tunnel vision I've gotten in the past year from 90% of my code being in Python. A managed C# wrapper would probably still be pretty cool. Did you do anything special for the SWIG wrapper, or can I just create an interface file that references all the headers (the "truly lazy" way according to the tutorials)?
|
|
#
?
Nov 24, 2008 22:40
|
|
|
nihilocrat posted:It's a good suggestion, but that counts as "library hunting" But they should provide a good 'all-in-one' solution. Oh well.
|
|
#
?
Nov 24, 2008 23:05
|
|
|
I just started using Psyco in my little pyglet/rabbyt sprite game and it doubled my fps 
|
|
#
?
Nov 24, 2008 23:12
|
|
|
not a dinosaur posted:I just started using Psyco in my little pyglet/rabbyt sprite game and it doubled my fps While its not that great yet, pypy is hopefully going to knock that door off its hinges by letting you translate your python code down to C, LLVM or CIL code. I'm not sure if theres any issues with rabbyt but pypy already works with pyglet and should give you greater speed benefits than psyco while allowing you to target 64 bit architectures as well. There's also pyrex which lets you mix c and python data types and compiles down to a c extension which it calls from python, this should give you greater speedups than psyco as well.
|
|
#
?
Nov 24, 2008 23:26
|
|
|
tripwire posted:While its not that great yet, pypy is hopefully going to knock that door off its hinges by letting you translate your python code down to C, LLVM or CIL code. I'll try to keep this brief, since this isn't the Python thread. First off, I'm no PyPy expert, so feel free to correct me where I'm wrong. This is just gathered from some small amount of experience with it, and a bunch of reading. PyPy has a lot of promise, but PyPy is not particularly fast yet (unless that's changed really recently). PyPy can't translate normal Python into C, nor into any particularly fast form of LLVM, CIL, or anything else. What it can do is translate RPython, a subset of Python, into these things. The hope is, in the future, that it'll have a good JIT compiler/optimizer that will be able to do the same sorts of thing that the RPython translator does, but by generating the code needed on the fly, rather than using constraints to limit the needed permutations. Now, you could code your project in RPython, but (perhaps unwisely) the PyPy people didn't design RPython to be used outside of PyPy, and thus it doesn't really have a spec, and it apparently can be pretty cryptic and crash-prone, and it just isn't designed to be used outside of PyPy. You can use it, it just isn't recommended. I like Python a lot, and I think PyPy has a lot of promise, but I wouldn't encourage anyone to build games on top of it yet, and in general, I'm worried by the lack of real, immediately useful results from PyPy. However, the good news is that Pyrex/Cython is a really excellent way to generate C extensions for Python using something that feels like a pretty natural extension of Python. And there are lots of other good ways to call into C extensions, like Ctypes and SWIG, depending on your needs.
|
|
#
?
Nov 25, 2008 16:13
|
|
|
Mithaldu posted:I think it would help if you'd drop a few words about what input the AI gets, what outputs it can form from that and maybe a rough sketch of how you would implement a base AI. Er, right. Basically, this is a platformer. We're not talking tactical shooter here, so all the AI needs to know is the player's location and the area around him. Then I need to know if the enemy wants to 1) move and 2) attack. For the most part, attacking will be done by shooting little bullets, probably directly at the player, or in a couple cases trying to collide with the player, either by dive-bombing, increasing speed, simple stuff. A friend of mine suggested using a parameter list with a few variables that essentially tell the AI how to react to certain situations. Say, for example, there was a parameter MOVEMENT="Flying". I call enemy.move(), which says "Okay, are you a flying enemy?" and runs the "flyingMove()" function which, of course, doesn't take into account gravity. I'm not certain how well this would work, and I'd rather not code it all out just to find that it's a pain in the rear end and not extensible.
|
|
#
?
Nov 27, 2008 00:56
|
|
|
It doesn't sound like you need anything that complex, Morpheus, so I'd suggest going with your first instinct approach, and seeing how it works. You probably won't understand the more complicated approaches until you figure out the deficiencies in the simpler approaches first hand, anyways. I'd suggest giving each actor a state (fleeing, attacking, waiting, etc.), and creating a base enemy class that defines their behavior in each state, and a simple check which allows them to change state. Juts make sure you break it out into functions logically, so you can extend the base class when needed. For example, your flying guy, instead of having a parameter, could just override the move() function. Really though, just start writing something and see if it works. You can always refactor it later.
|
|
#
?
Nov 27, 2008 19:35
|
|
|
I get the feeling this is a relatively simple physics question but it's the kind of thing you might not be able to figure out yourself. Given one object's current position and velocity (the 'target'), and another object's position (the 'shooter'), and a constant speed of a particular 'projectile', how would you figure out the angle necessary to aim the projectile to perfectly strike the target? code:
|
|
#
?
Nov 28, 2008 04:37
|
|
|
UraniumAnchor posted:I get the feeling this is a relatively simple physics question but it's the kind of thing you might not be able to figure out yourself. Parametrize the path of T with respect to the variable for time. Then parametrize the motion of P, with speed known, but direction unknown, set them equal, and solve for the direction (a vector). I.e. for T at position P(x0, y0, z0) at t = 0, V(a, b, c) T = P + Vt Or alternatively (you shouldn't need to use this formulation, you can just do vector math, but this might be a little easier to understand?) x(t) = x0 + at y(t) = y0 + bt z(t) = z0 + ct Then say that you know the position of P, say it's P2, and its speed is S. One way you can do this is parametrize it in terms of the angles so that the velocity's magnitude equals S. Use Theta and Phi as the angles. |V_p| = S V_p = (S cos Theta sin Phi, S sin Theta sin Phi, S cos Phi) Then say P2 + Vp * t = P + Vt, and choose a time t when you want them to intersect, if you want to simplify the solution. If not you'll get a relation between t and the angles which will let you choose any time, I believe. Edit: Here's another way to think about it. This is really a 2-D problem. First, take a vector pointing from P to T, and the velocity vector of T. Take their cross product and use the position of P to have a normal and a point, so you have a plane, and the trajectory that P must take will lie in that plane, in fact, such that the direction will be somewhere between pointing at T's position at t=0, and pointing in the direction of T's velocity vector. Ever done those problems in calc class where you have a river going at some velocity, and want to travel along some vector so that you hit a point on the other end of the river? This is basically that problem. You can just do a similar parametrization to what I did above, but you only need to use one angle. I haven't done the math out, but intuitively I think the angle should work out as a function of the ratio between the speeds of T and P. P should point directly at T when the ratio of the speed of T to P is zero, and P should approach pointing parallel to T's velocity as the ratio of the speed of T to P is infinite. Like I said I haven't done the math but I believe the angle should be equal to arcsin(|T|/|P|), where an angle of 0 represents pointing at T and an angle of 90 represents pointing parallel to T's velocity. schnarf fucked around with this message at 05:24 on Nov 28, 2008 |
|
#
?
Nov 28, 2008 04:56
|
|
|
I'm driving myself crazy doing low-res pixel art graphics. Drawing sprites between pixel boundaries (ie. floating point coordinates) results in awful display artifacts, obviously- so for each sprite I maintain internal coordinates in floating point, and every time they are updated I do:code:This worked great at first, but seems to haunt me at every corner. The biggest problem right now is if a sprite starts moving diagonally from non-integer coordinates, display_x and display_y will jump in an alternating fashion. This means instead of smooth diagonal movement, the sprite vibrates along its path. The obvious solution is to reset the real coordinates to display coordinates whenever an object changes direction. Again, worked well for a while, until I starting implementing physics. Basically, objects can be caused to "change direction" every step of gameplay, and using the above solution means that objects never move. gently caress. I feel pretty stuck at the moment. Am I missing something really obvious? Does anyone have any ideas at all?
|
|
#
?
Nov 28, 2008 20:29
|
|
|
not a dinosaur posted:I feel pretty stuck at the moment. Am I missing something really obvious? Does anyone have any ideas at all? schnarf fucked around with this message at 20:43 on Nov 28, 2008 |
|
#
?
Nov 28, 2008 20:38
|
|
|
^^^^^^ I just read your edit. Again, I'll explain a bit better. Two different sets of coordinates are maintained for each object. The floating point coordinates, "real_x" and "real_y", and the integral coordinates, "display_x" and "display_y." The update_position code looks something like this: code:schnarf posted:How about you store the coordinates (display_x and display_y) as floating-point, and when you call the draw routine, you call it with rounded values -- by the way, casting to int doesn't round, it truncates. You might want to try floor(number + 0.5f). This has the same problem. Maybe I should describe it in more detail - let's say the player is at coordinates (5.4, 5.9). Every timestep, the player's movement vector, (-0.5, -0.5) is added to his current position. Note that the player would currently be displayed at (int(5.4), int(5.9)) = (5.0, 5.0). Now, execute the next timestep- the player's new position is (4.9, 5.4). He will be displayed at (int(4.9), int(5.4)) = (4.0, 5.0). This is what I meant before- he has jumped in the x direction and not in the y direction. Next step, he'll do the alternate. The result is that instead of smooth diagonal movement, he vibrates in a diagonal direction. a slime fucked around with this message at 21:48 on Nov 28, 2008 |
|
#
?
Nov 28, 2008 20:48
|
|
|
You're going to get "vibration" to some extent no matter how you do it if you're rounding float coordinates off to integers. If not when it's going "perfectly" diagonally, then when it's moving at some other angle. i.e. even if it looks OK going completely diagonally, what happens when it's moving, for example, twice as fast down as it is to the side? One thing you could try is allowing sprites to use subpixel positions while in motion and snap them to pixel boundaries when they stop or slow down enough. Also, try experimenting with filtering modes, NEAREST filtering may wind up looking better if you're shooting for an "old school" look.
|
|
#
?
Nov 29, 2008 11:24
|
|
|
OneEightHundred posted:You're going to get "vibration" to some extent no matter how you do it if you're rounding float coordinates off to integers. If not when it's going "perfectly" diagonally, then when it's moving at some other angle. i.e. even if it looks OK going completely diagonally, what happens when it's moving, for example, twice as fast down as it is to the side? Good point. Although, I think at angles other than 45 degrees the effect would be less noticeable. That's a good idea. Unfortunately the snapping effect would be more obvious the slower an object is moving... But maybe with tuning it wouldn't be too bad. Thanks! I am already using NEAREST
|
|
#
?
Nov 29, 2008 13:17
|
|
|
Are there any fancy ways to find the first intersection of a curve with an axis-aligned bounding box? I was previously using a modified version of the Liang-Barsky line-clipping algorithm (along with Minkowski differences) to determine if objects collided. Now I've added acceleration and things are no longer linear- this isn't enough any more. Instead of the relative positions of two possibly colliding objects being simply "move_vec_a - move_vec_b", it is vel_a * t + 0.5 * accel_a * t^2 - vel_b * t + 0.5 * accel_b * t^2... Ugh. I'm hoping there's something better than straight up solving for the points where the curve intersects with each line segment of the AABB, but nothing is showing up on  edit: details, details edit 2: fuuuck now determining moving AABBs means calculating local extrema for each moving object a slime fucked around with this message at 14:46 on Nov 29, 2008 |
|
#
?
Nov 29, 2008 14:23
|
|
|
not a dinosaur posted:Good point. Although, I think at angles other than 45 degrees the effect would be less noticeable. not a dinosaur posted:Are there any fancy ways to find the first intersection of a curve with an axis-aligned bounding box? If you're trying to do it with moving objects, you're opening up a major  that even well-established major physics engines don't attempt to solve (they just let objects penetrate, generate contact constraints, then run a few more solver iterations). The easiest way to do non-penetrating physics is to iterate each object separately, which doesn't work well for groups of connected or contacting bodies, but is extremely stable.
OneEightHundred fucked around with this message at 12:11 on Nov 30, 2008 |
|
#
?
Nov 30, 2008 03:58
|
|
|
Re: the python/psyco/pypy discussion I think it is worth pointing out (bragging) that haXe has a C++ target in testing now: http://gamehaxe.com/2008/10/28/c-backend-for-haxe/ and http://gamehaxe.com/2008/11/10/hxcpp-02-huge-performance-increase/ If that gets more stable and optimized, it'll be feasible to write number-crunch-heavy software in haXe. I used Python for a very long time but have switched over to this in the last year - nice language, the multiplatformness rules, and it's much, much more promising than PyPy if you're looking for speed. The main downside is that library support is limited and probably will continue to be for years to come.
|
|
#
?
Nov 30, 2008 05:51
|
|
|
not a dinosaur posted:I'm driving myself crazy doing low-res pixel art graphics. Drawing sprites between pixel boundaries (ie. floating point coordinates) results in awful display artifacts, obviously- so for each sprite I maintain internal coordinates in floating point, and every time they are updated I do: I'm having a similar problem to this, although using GL, which I've found GL_NEAREST seems to solve. Kinda. This is an iphone though, so things are a bit whacky , being GL ES and all that.
|
|
#
?
Nov 30, 2008 14:17
|
|
|
duck monster posted:I'm having a similar problem to this, although using GL, which I've found GL_NEAREST seems to solve. I'm also using GL with GL_NEAREST, not sure why you aren't having the same problem with scaling artifacts. It doesn't happen at all float coordinates, only some. Lower image shows the ugliness.   VVVVVVVV and there it is, let me know if you find a solution a slime fucked around with this message at 15:21 on Nov 30, 2008 |
|
#
?
Nov 30, 2008 14:47
|
|
|
Actually now I think about it, I am having some issues... But its really sporadic. Just a rip, here and there on the sheet
|
|
#
?
Nov 30, 2008 15:20
|
|
|
Me and this other dude are collaborating on a pygame project as our annual winter time-waste. At its core, it will incorporate some basic sidescroller elements with assorted minigames that I can only define shortly as sort of like rhythm games without a beat. We've spent two weeks scouring around looking for relevant tutorials on how to set up both aspects, and we either come up against really terrible ones or decently written but old as hell. Does anyone have links to any pygame tutorials they recommend? Or even some nicely written open source games we can tear apart and learn how to structure our poo poo?
|
|
#
?
Dec 1, 2008 00:14
|
|
|
Wuntvor posted:Well, since this is a question I've been dealing with again and again, I thought I might as well post here. Basically, I have a very hard time deciding what language to do my game programming in. C# is what I'm most comfortable with, so XNA would be the natural choice, but I'd like at least the possibility to run the game on Linux as well. You're going to have a hard time finding a single library that does it all and is completely cross platform. I don't know if I would recommend it but you could probably use C# for your Win32 gui code, use managed C++ for the core, and of course use something other than C# for the gui on other platforms. I think you'd be making life harder for yourself that way, though. The other option is to mix and match your libs, say SDL (or whatever) for your video/input/sound, and something else (probably platform specific) for your gui lib. You could also write your own in SDL, too.
|
|
#
?
Dec 1, 2008 12:04
|
|
|
not a dinosaur posted:I'm also using GL with GL_NEAREST, not sure why you aren't having the same problem with scaling artifacts. You're probably getting floating-point error. Having textures with power-of-two coordinates helps, as does putting the textured quad in the middle of a pixel on the screen (i.e. if 1 unit = 1 pixel, your vertices should be some_int + 0.5).
|
|
#
?
Dec 1, 2008 12:50
|
|
|
Thug Bonnet posted:You're going to have a hard time finding a single library that does it all and is completely cross platform. I don't know if I would recommend it but you could probably use C# for your Win32 gui code, use managed C++ for the core, and of course use something other than C# for the gui on other platforms. I think you'd be making life harder for yourself that way, though. Plus, if performance at some point turns out to be subpar, I can still switch from SdlDotNet to OpenGL at some point.
|
|
#
?
Dec 1, 2008 16:03
|
|
|
While we are on the subject of libraries, what do you guys use? I use: SFML -- Handles Sound, Graphics, Input, and limited TCP. Very easy to set up and use. ( http://www.sfml-dev.org ) Demonstrably faster than SDl in the 2D department. Only a 2D library. RakNet -- UDP networking library that is at once easy to use, and VERY powerful. This guy knows his stuff. ( http://www.jenkinssoftware.com ) Includes support for game lobbies, object replication, auto patching, logging, and a whole bunch on top of their basic UDP handling. CEGUI -- Pretty decent GUI library. Scriptable with lua. ( http://www.cegui.org.uk ) Box2D -- 2D physics library. Never run into problems with it ( http://box2d.org ) As far as I know, it's still being actively developed. With those four libraries, you should have everything you need to write your 2D networked game, without having to worry about the particulars. Oh, and Boost. For things like shared pointers.
|
|
#
?
Dec 1, 2008 20:51
|
|
|
Pfhreak posted:Box2D -- 2D physics library. Never run into problems with it ( http://box2d.org ) As far as I know, it's still being actively developed. This thing got me so excited last year. Fascinating library, I'm sure its responsible for more than half of the physics inspired games available today. What ever happened to that Crayon game?
|
|
#
?
Dec 2, 2008 06:35
|
|
|
edit: I suck.
vanjalolz fucked around with this message at 06:52 on Dec 2, 2008 |
|
#
?
Dec 2, 2008 06:48
|
|
|
vanjalolz posted:What ever happened to that Crayon game? It's up for preorder with a TBA date: http://www.crayonphysics.com/
|
|
#
?
Dec 2, 2008 07:26
|
|
|
t_rf posted:Re: the python/psyco/pypy discussion I'm hoping things will turn out as you suspect. Not having the huge library support that Python has is a bit limiting, but having a mature FFI would basically "solve" this, as lots of Python libraries are just ctypes/Py++ or other FFI wrappers. It seems like haXe is basically looking at the strengths of the VM platforms (JVM and .NET) but trying to implement them in a different way. It seems promising, but I'm not sure how everything would actually turn out in practice. Being able to code the same game in flash and C++ simletaneously would be a huge boon to game development, though. Flash provides a great outlet for getting people interested in your game, while C++ is obviously quite fast.
|
|
#
?
Dec 2, 2008 19:23
|
|
|
Anyone else doing uDevGames this year? http://www.udevgames.com I don't really have any ideas for what I'm going to do yet, but when I do, it will probably use SDL and have terrible art because I am terrible at art. They've got some really great prizes for the winners, too. 3 months seems reasonable to do something good but simple. I think I'm gonna spend the next few days brainstorming and another day or two writing up a design document so I can have a solid foundation to work from. As far as I know, at this point it's going to be 2D and sprite based, or if I have an idea that I think will benefit from it, 2.5D. I am bad enough at 2D art, 3D art will be impossible to get done in the amount of time I have.
|
|
#
?
Dec 2, 2008 20:06
|
|
|
whoknew posted:I don't really have any ideas for what I'm going to do yet, but when I do, it will probably use SDL and have terrible art because I am terrible at art. They've got some really great prizes for the winners, too. 3 months seems reasonable to do something good but simple. I think I'm gonna spend the next few days brainstorming and another day or two writing up a design document so I can have a solid foundation to work from. As far as I know, at this point it's going to be 2D and sprite based, or if I have an idea that I think will benefit from it, 2.5D. I am bad enough at 2D art, 3D art will be impossible to get done in the amount of time I have. I wouldn't be too worried about art. Just design a game that uses a simple art style. Look at Darwinia, it obviously didn't have a huge art budget but the game still looks very pretty.
|
|
#
?
Dec 2, 2008 21:16
|
|
|
I'm sure something like this has been posted in this thread, but I sure can't find it so if this is a huge repeat just point me to where it was already posted. I'm trying to develop a very simple platformer in Flash and I want to ask about physics. If I was making a physics reliant game I'd just import Box2D and be done with it, but I only want a really basic feature set (think Knytt) and I figure it will be a good learning experience to do it myself. I'm only using static, rectangular, non-rotating hitboxes so collision detection is easy. My problems come from resolving those collisions. My basic idea was to decide from which side a platform was being hit (all objects are either platforms or not and this collision resolution code only runs for collisions between platforms and non-platforms) and then back the moving object up until it's on that side of the platform. This has worked to some extent and the more I tweak it the better it gets, but some problems just keep cropping up that make me think I'm doing something fundamentally wrong. Here's the collision resolution code: code:TL;DR – If anyone has any resources/example code for simple physics like this I'd love to see how it's usually done.
|
|
#
?
Dec 4, 2008 06:56
|
|
|
|
| # ? May 10, 2024 13:07 |
|
|
Just use the dynamic separating axis theorem: http://realtimecollisiondetection.net/files/levine_swept_sat.txt
|
|
#
?
Dec 4, 2008 08:33
|
|