• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

122 Neutral

About cmc5788

  • Rank
  1. Updated the OP with new video links.
  2. I think I'm finished with the enemy AI overhaul for now. Enemies are... really, really deadly now. I've played this game more times than I can count and am really familiar with the controls, but I still have a really tough time with this latest build. The better AI just makes the game a LOT more challenging. I'll probably have to tweak player HP or rate of health pickup drops to balance it out at some point, but at this point I'm just really proud of how the AI works. It does a lot of stuff like leap attacks, jump-dodges, etc., that make it a lot more interesting. Here's the new build: https://www.dropbox.com/s/b4y140c6cmmricw/Casey-HackJumpSlash-Final.exe And here's a video of it in action: http://www.youtube.com/watch?v=GPqlZts7uzw (do 1080p if possible, otherwise it looks pretty crap) Next I'll probably work on the dash/sprint system while it's fresh in my mind. But seriously, if anyone can beat this latest build with any weapon other than the wizard staff (which is technically "cheating") I'll be seriously impressed. It's tough.
  3. Made some updates with a new build, available for download here: https://www.dropbox.com/s/b4y140c6cmmricw/Casey-HackJumpSlash-Final.exe Summary of changes: * Attacks add a "knockback" effect to give better feedback on hit * All attacks have been sped up significantly (speeds still vary by weapon type, though) * Added another control scheme for user-friendliness: can now use arrow keys/X/Z to move/attack/block, respectively * Separated "outfit" graphic from base creature graphic, so now helmet/cloak/etc can be worn by any creature dynamically. Move right towards "instructions" arrow to choose an outfit (or cheat and use the wizard's staff for overpowered-ness) * Added new graphics for a bunch of outfits * Currently outfits/helmets are purely visual, but will have gameplay effects soon * Added new weapons, axe and mace. Maces are super-effective against skeletons, but fairly slow. Axes are just really good all-around, maybe too good. * Added facial animations for taking damage, blinking, getting stunned, etc. * Attacks no longer slow your movement speed if you're in midair, which makes "leaping" attacks extremely powerful Things coming soon: * enemy AI overhaul * more platforming elements (environmental hazards, moving blocks, and more) * inventory & belt system for picking up usable items, swapping weapons and outfits, etc * More interesting, procedural levels
  4. Hi everyone,   I've been working on a prototype for an as-of-yet untitled hack-and-slash platformer. Although my background is in programming, I've been using GameMaker for its quick iteration ability.   So far, I've only got a few example levels put together. I've been focusing on getting really solid core combat mechanics, which consist primarily of attacking, dodging, and blocking enemy attacks. I'm looking for some feedback on the core mechanics -- movement, attacks, etc., but really any feedback or ideas are appreciated, harsh commentary included, and even welcomed. I'm trying to decide where to move next with this prototype and really take it to the next step, pushing forward the parts that work and moving past the ones that don't.   Keep in mind this is a very early stage prototype, not a full playable game -- meant to be more of a solid, working demo of core combat mechanics and general ideas. I certainly have ideas about how I want to further develop this game, but I'd prefer not to mention those here because I'm afraid they might "pollute" responses I get. I want fresh commentary since I've been tunnel visioning this thing for long enough to start losing perspective! So with that said, here are some visuals, an older video of gameplay (apologize for poor quality), and a download link to the current playable build:   Some placeholder vector art I'm using to get an idea of the style I'm going for:   The player reflecting a fireball back at a ranged enemy with a well-timed attack:   An older video showing one of the playable levels included in the prototype. Keep in mind the playable version below has changed quite a bit since this video was taken: http://www.youtube.com/watch?v=UiExWXRBz8g     New video!! (do 1080p if possible, otherwise it looks pretty crap): http://www.youtube.com/watch?v=GPqlZts7uzw   And a bonus video of WIZARD MODE: http://www.youtube.com/watch?v=zWz6InMYV9M   https://www.dropbox.com/s/b4y140c6cmmricw/Casey-HackJumpSlash-Final.exe (Windows only, standalone executable)   Controls: WAD to move and jump ENTER to attack E to block F to toggle fullscreen ESC to pause F5 to restart from main menu   Other things to keep in mind: Starts up straight into playable game, no "menu" Jump on enemy heads to stun them briefly Blocking an enemy attack with 'E' with precise timing will also stun an enemy Longpress jump for a full jump, tap to hop Projectiles from ranged enemies can either be simply blocked with 'E' or reflected back with a well-timed attack
  5. Game designs of questionable ethics

    There's nothing functionally wrong with making a game that includes ethically dubious (or even outright disgusting) themes, as long as you acknowledge and handle those themes appropriately within the context of what you're trying to do. Be sure that you know your game and how it comes off to players, and it shouldn't be a problem. It's only really an issue if the game just sort of haphazardly throws around really sensitive themes with no aim (unless of course the point of it is the absurdity, in which case that should be reflected in other ways throughout your design). In short, be consistent. If your game is otherwise very happy-go-lucky and cartoony, then suddenly you're inciting race wars between eugenically fanatacized populations, that's quite probably an issue (though, as always, there are exceptions: you could be going for the "dark cartoon" feel, ala Conker's Bad Fur Day).
  6. OpenGL SDL. would YOU recommend it ?

    Quote:Original post by swiftcoder Quote:Original post by lmelior Unfortunately this thread is about par for the course when you look through similar threads going back at least 7 years. Probably longer. Everybody experienced says NeHe's tutorials are bad, and that they should be redone, yet nobody has done it and there are very few alternatives.Having the necessary experience and qualifications to demonstrate why NeHe's tutorials are bad is very different from having the necessary experience and qualifications to write the definitive OpenGl tutorial for the modern world. It is also a not inconsiderable undertaking. While I am sure a few of us could pool resources and get it done, it is a hell of a lot to ask from a few volunteers. Like I mentioned, it might be easier just to put together a community "base code" of sorts that uses a few simple shaders to replace the FF-pipeline and some sort of non-immediate rendering technique, VBOs or whatever. From there, Google will suffice.
  7. OpenGL SDL. would YOU recommend it ?

    Quote:Original post by Prune Quote:Original post by swiftcoder [Prune's example isn't the only one, and while his is a relatively technical issue, some of the others aren't. The point though is not whether it's technical or not, but the impact on performance, which, I can assure you, can be quite significant in program areas where you have frequent data synchronization. The portion of the Windows API and WGL needed to write a base for OpenGL projects that gives you a context and handles input is fairly limited, and it's an exercise one would need to undertake only once--and maybe learn something in the process. Adding Linux and GLX as a second stage is pretty straightforward too. For threads, use pthreads or roll your own, which has the benefits of giving you the ability to tailor performance to your application, such as with a custom scheduler etc. For audio, OpenAL is great even despite the lack of alMapBuffer(). For networking, to get started you don't even need a library as working with TCP ports is straighforward and almost identical on Windows and Linux. If you find that something like SDL doesn't efficiently implement an area that you need to optimize (i.e., this is a program bottleneck) then this is an excellent point. Or perhaps you're simply someone who enjoys writing as much of their low-level interface as possible. Either way, it's not really much of an argument against the efficacy of SDL. Most often, SDL's performance patterns won't be anywhere near a bottleneck, so the clean design philosophy of the prebuilt multiplatform abstraction and the simplicity of implementation is desirable. This is especially true if you simply wish to begin developing your OpenGL application as seamlessly as possible -- if you later find that you don't need many of SDL's features, and you simply want a context, it's easy enough to add the WGL/Windows code to replace what SDL does. There's no reason NOT to start with something that's very easy to get up and running, especially when there will be no impact to later performance if you end up deciding to replace it. In short, knowing the platform-specific methods of getting a context is good... but that isn't really an argument against SDL.
  8. OpenGL SDL. would YOU recommend it ?

    Quote:Original post by nemebean Honestly, I find Google to be a better resource than NeHe. The NeHe tutorials that aren't recommending bad ways of doing something are so confusing that I've never actually gotten anything useful out of them. If you just Google whatever you're trying to do you will almost certainly find a better explanation of it in short order. Sure, there isn't another site that attempts to cover the breadth of topics that NeHe does, but I'm starting to think there's a good reason for that. Yeah, I agree with you, but it's hard to know what to Google for when you're first starting out. It would be really helpful to have some more modern base code that doesn't use immediate mode and starts out FF-pipeline-free. Unless I'm mistaken (and I might be, I'm still new to this) those are the two big things that define "modern OpenGL" in relation to NeHe era: shaders + non-immediate rendering. That and a load of extensions... but GLEW takes care of that nicely.
  9. OpenGL SDL. would YOU recommend it ?

    Quote:Original post by maspeir My statement was overly broad, but I stand behind it. The tutorials are, for the most part, still based on GL 1.1 and immediate mode. As such, they teach newbies a very antiquated method which is no longer relevant. To make it worse, it is now tied to this site, which lends credence to its usefulness. The tutorials, as currently written, need to be scrapped and rewritten. It does more harm than good to keep them up as is. Honestly, what's a better alternative? I find even the latest edition of the official OpenGL "Red Book" is equally confusing and overrun with discussions of deprecated features (and the worst part is, the deprecation gets no more than a passing mention at the beginning of each chapter). Do you have a better suggestion for a modern, cohesive source for learning OpenGL? Because if you do, I'd love to hear it... I just started learning relatively recently, and it took me ages to sort through all the material in the red book about display lists, VBOs, vertex arrays, and then cross-reference that with this site and a number of others to figure out what an actual modern technique was. I'm still not sure I know. NeHe might be outdated, but unfortunately so is the official manual (even the latest edition, which I have). It discusses every feature ever to have existed in OpenGL and there's no contextual information to help you decide which techniques "should" be used. So, yeah...
  10. OpenGL GameGUI

    I agree with the others who have suggested that coding your own GUI is generally the best solution -- it also tends to be very fun and rewarding, because when dealing with all the complexity of a 3d engine, the GUI is comparatively easy and the results come quickly. This probably goes without saying, but you want to abstract the GUI renderer. Past that, it's all up to you -- it depends on what you need in terms of features. Like others have mentioned, it's good to have a basic "widget" or "element" class from which to derive all other things, also pretty typical are the concepts of containers and controls, etc. I don't think anyone's yet talked about containers and controls, so I'll go a bit more into it. Basically, containers are objects that hold any number of controls, and can be parents or children of other containers. A control is a simple object that reports a single element of input back to the container holding it -- this would be something like a checkbox, slider, etc. A container, if it has a parent container, reports back the sum of the inputs of all its controls back to its parent container when it ceases to exist. This allows for a system where one window may have a number of buttons and sliders and input boxes, and when this window is finished, it can report back the sum of all these individual options back to its parent window, which in turn may have other individual boxes and buttons AND additional children containers that will report groups of control states. You may not need anything so complicated for your GUI, but this is the genereal theory of "windowing."
  11. OpenGL SDL. would YOU recommend it ?

    Quote:Original post by FlyingSolo The major problem was having the window go to black following a resize under Win7(64) or some corruption if going full-screen under windows XP. I'd finally got this sorted out by rewriting the window handling portions of my code when I decided that maybe something like SDL was a better way forward. I generally hate to use 3rd party lib's. The recommendations from the good folks here sealed it and so far, SDL has delivered the goods with remarkable ease. Something you should probably be aware of, then, is that SDL has a pretty well-known problem with fullscreening/resizing on Windows. The OpenGL context is lost when a fullscreen or resize happens. This means you need to reload all your textures and reset the OpenGL context completely. Not a big deal (and it doesn't happen on Linux), but probably something to be aware of.
  12. Unity [C++] Proper enum usage

    Quote:Original post by swiftcoder Nope, an enum is just a name. That C/C++ choose to implement them in terms of integers is immaterial. This is true, but it's also silly. In my mind, the most intuitive use for something like an enum is to simply be a wrapper around such const int functionality. Enums SHOULD be the same as const ints. Conceptually, there's really no reason to ever use enums... in fact, they're kind of a trap. For what you would intuitively think they're useful for, they are actually undefined :(
  13. http://www.allegro.cc/forums/thread/600737 Here's the thread I was talking about, which is where I got the idea that it was "okay" to do it with the projection matrix.
  14. Quote:Original post by karwosts I believe standard practice is that you should never position your camera using the projection matrix. These should explain why better than I can: 8.030 Where should my camera go, the ModelView or Projection matrix? Help stamp out GL_PROJECTION abuse Ah, thanks! I found a thread where someone mentioned that it was bad to position a camera with the projection, but everyone else in the thread seemed to disagree or downplay the idea.
  15. Hey, I'm pretty new to OpenGL still, and I have a (probably) simple question... I'm trying to achieve an "isometric-like" perspective view, i.e., 45 degree rotate on the y and then somewhere from 30-45 degree angle to the horizontal, etc. However, from doing a bit of research I've found that this effect can be achieved in different ways. I could either setup the projection matrix to lock into this perspective, or I could do something like gluPerspective on the projection and then just transform to the proper place on the modelview, taking care not to call loadIdentity unless I push the matrix first. Most of the examples I've found online seem to prefer the modelview transform. Is there any reason for this? Is there any tangible difference between the two techniques, or are they just slightly different ways of doing the same thing? Sorry if the question is simple, but I did indeed use my google-fu and couldn't find any direct answer. So, thanks!
  • Advertisement