|
If you already know AS3 you can't go wrong with the Flashpunk/Flixel suggestions above, the great thing about flash is the ability to easily get feedback on stuff, plus I feel Flashpunk is a very similar base to how most people would do their first game engine if they were writing it from scratch, only all tested and whatnot. There is some stuff it'll teach you to be lazy about, like asset management, but that's just a result of having to embed everything into one SWF and isn't really a big deal either way. Check out http://flashgamedojo.com/ and if you have any flashpunk questions (i've never really used flixel) i'll be glad to help.
|
#
¿
Feb 8, 2012 18:24
|
|
|
|
| # ¿ May 13, 2024 19:55 |
|
|
GENUINE CAT HERDER posted:Yeah, the asset management stuff is actually one of the things that actually really bugged me about Flash design (it really all goes into one file!?), as it went completely contrary to a lot of the stuff I've internalized when making designing other programs. The thing you really should know is that the hard part in game development is not individual enclosed systems like asset management, basic engine design and simple rendering, it's in taking a concept through to completion with the hundreds of obstacles that come up along the way that you didn't expect. It all depends on your goals, if you want to learn how to make a game engine then do it from the ground up in C++; if you want to learn how to do fancy 3D shaders and effects, do it in something like Unity or UDK where the rendering pipeline is set up for you to easily test that stuff; if you want to make a full game, do it in an environment that you can get to grips with quickly that provides a lot of assistance in basic functionality. It's very easy to spend weeks doing a basic engine with some clever rear end component based design, then when it's done be burned out too much to get through making the actual game with it. The biggest enemy to completing a hobby project game is motivation, so making it easy to get back into it quickly is pretty important. Don't underestimate external motivators like having a progress blog that you imagine people read to keep somewhat indebted to finishing it if that makes sense. Man that's a lot of rambling about the same things.
|
|
#
¿
Feb 8, 2012 18:54
|
|
|
Jaur posted:I'm using PyGame to make a small platformer, it uses 32x32 tiles to build stages and stuff. I'm wondering what would be the best method for making the program able to scroll across a level that encompasses a larger area than the window. (Basically, I want to be able to have a camera focus on the player as she moves around the level). I have read a few things, but I'm having a hard time putting all of it together in a way I can actually translate to code. How would I go about creating some kind of camera that follows the main avatar sprite along a world bigger than the window? I don't know if the problem is you don't know how to have a camera that moves around at all (if so, when rendering offset all the render positions by the camera position (e.g. sprite.render(x - camera.x, y - camera.y)). If it's for a simple platforming camera system that follows the player without looking weird, I always use the mario system of essentially having there be an inner rectangle where the player character is, where if he goes outside of the rectangle, it moves the camera so he's back in. You then enforce any hard constraints like the level borders. It also means you can play about with the way the camera tracks the player for different areas, like ones where you're going up a lot you want it so the rectangle is relatively small in height so when you jump it follows you, while on ground areas you don't want the camera moving vertically when you're jumping so you make it really big in height. I can do a drawing if it helps but I don't think I can explain it any better without knowing what you don't understand.
|
|
#
¿
Feb 11, 2012 23:50
|
|
|
I don't know enough about UDK to answer you but you might get better help in the UDK megathread although I imagine most of the people who read that read this.
|
|
#
¿
Feb 16, 2012 05:48
|
|
|
Oh so that was you, I emailed you last night anyway, it would be snazzy to discuss stuff.
|
|
#
¿
Feb 16, 2012 18:41
|
|
|
Unless you're constantly changing the scale, you should be able to just generate a collision bitmask (like a grid of boolean values for solidity) based off the image that you'll render to the screen after scaling, either in the constructor and/or during a setScale type property. If you're worried about memory you can cache the different sizes you make so you can reuse them too. You can do a multiple hitbox approach and it will almost always run faster (unless pixel collision is done in hardware these days), but it's a pain to make new units and so on with, plus for objects that change animation heavily you'd have to update the hitboxes in line with the animation. Either way when doing pixel perfect stuff you want to make sure it only does it when needed, this typically means having bounding box tests before pixel collision tests and if needed making it so only stuff that directly affects the player uses it. If you've got a lot of objects colliding a lot physics engines may be your best bet too.
|
|
#
¿
Feb 19, 2012 02:08
|
|
|
MrZig posted:Thanks! I actually managed to get a PixelPerfectBitMask setup working properly, or at least good enough for now. I can start with a high res image, say 512x512, and have OpenGL refer to that for drawing, then for the bitmask I just used Android's createScaledBitmap to the object's actual size and presto, it works perfectly. I guess make sure there aren't any offsets you're not aware of are at work and step through with a debugger or debug text write what the mask looks like internally and make sure it lines up with what you think it's meant to look like. I mean other than that it's just a case of getting the logic for the test right.
|
|
#
¿
Feb 19, 2012 02:55
|
|
|
Well for a start you're doing test(enemy.x - this.x, this.y - enemy.y) when you want it to be test(enemy.x - this.x, enemy.y - this.y). Other than that I don't know. Just work out what should be happening on one test and what's actually happening and work out what you're doing wrong from the difference. It's really what you end up doing most of the time in game development.
|
|
#
¿
Feb 19, 2012 05:11
|
|
|
The guys at Flashbang did a game that did the same thing called Minotaur China Shop in Unity a couple of years back, I believe somewhere on the tech blog there's some explanation but as you can see from the game it's a really hard thing to do and still have the character remain upright and all together. I mean there's a reason it's not done outside of fringe cases, it's very hard to make stable enough for anything other than a gimmick (not that there's anything wrong with that gimmick).
|
|
#
¿
Feb 26, 2012 17:50
|
|
|
I'm down but if it's voting please for the love of god just make it ludum dare rules, only those who submit can vote, it just means they're far more likely to not only have played one game and voted for that. There will probably only be a few entries anyway so everyone involved can easily review everyone else's stuff.
|
|
#
¿
Mar 12, 2012 18:04
|
|
|
The King of Swag posted:Words words swag words swag words I totally went through the same phase as you, I mean I didn't coin it with a fancy syndrome name or anything, but I was heavily into doing everything myself for the sake of learning everything ever, under the delusion that after I just learned how to do this I'd finally be good at game development. Anyway you're totally right, it's all about using the best tools available to do the job. Game programming as a solo developer is about reducing the non-core game parts as much as possible while still being able to complete it to a quality level you'd be happy with. If there's middleware that will do what you want and will tell you when you're doing something wrong then you'd be a fool to not use it. Feature creep and having to rework things is a constant issue in iterative game development, but that's entirely why it's iterative and why prototyping on a small, testable scale and building from it is a good idea. That's my answer to the coming up with new projects thing too, pick an idea that you want to do, implement a prototype as barebones as possible and see if it feels like it's fun. From there you can try and map out what else needs done and the relative feasibility of it given your time frame. Art is an issue that you always have to deal with, either find a friend who shares goals who can do it and won't flake, which may be the hardest thing in the world, or work on your art iteratively while reducing as much artistic complexity as possible. Find other ways to make it charming or professional, use a lot of easy to implement but very snazzy looking UI interpolation routines, make everything monochrome or heavily based on a specific shading effect, make it abstract and arty, there's plenty of options. There's a big element of learning by doing with regards to scope, time estimating, keeping up motivation and so on. The best way to learn in the shortest period of time i'd say is by doing a lot of game jams and competitions, especially if you're lucky enough to be close to like a TIGJam or some other small jam that isn't mostly students. With regards to C++ I don't really know what the value of learning it is unless you have a goal in mind, if you accomplish your goals in C or Obj-C then go accomplish them, I personally would rather use C# or AS3 (Flash) over C++ and it's the language i've programmed the most in. It depends on the project obviously but if the reason you want to stick with lower level (but still high level) languages is because of performance concerns you might want to do tests to see if it's actually an issue that you can't work around. If you want to work in the industry it's important for a lot of jobs, although there's lots of AS3/Unity3D/HTML5 gigs going, the console and most mobile developers will require it. Just don't dismiss anything, it's all about using the tool that will make the process as easy as possible without diminishing returns. People who like to program well tend to build up a lot of opinions on a lot of things that will occasionally prevent them from doing the most logical approach to completing their goals, try and keep a check on doing that too much and you won't end up costing yourself 3 months of work for being stubborn like you did with the unicode thing. In the same vein evaluate times where you're cutting corners in a non-critical area and try and gauge whether maintaining it will outweight the time saved by doing it quicker. ABE, Always Be Evaluating. But not too much!
|
|
#
¿
Sep 8, 2012 20:30
|
|
|
Hey chaps, I was wondering if anyone had any experience with speech recognition and specifically if there are good packages available for somehow deriving intent from speech that isn't just recognising single words regardless of context, I remember stuff involving POS tagging and hidden markov models from a rudimentary AI class I had years ago, but I was hoping there would be some sort of prebuilt solution for this sort of thing. It's basically for directing a character to do things like running to objects and interacting them and so on.
|
|
#
¿
Sep 10, 2014 18:19
|
|
|
|
| # ¿ May 13, 2024 19:55 |
|
|
Ah brilliant, i'll look into all the links and see whether I'll ever have the time to implement it well enough to be worthwhile, a limited solution will almost definitely be fine given the context of just commanding a thing I imagine, I just want it to be as intuitive for the player as possible. Thanks!
|
|
#
¿
Sep 10, 2014 20:21
|
|