Jump to content
  • Advertisement

Maxamor

Member
  • Content count

    209
  • Joined

  • Last visited

Community Reputation

361 Neutral

About Maxamor

  • Rank
    Member
  1.   Most large things start off small and grow large over time.         I like to think of the player and enemies as puppets, and the level is a stage -- without a puppet master they don't do much. I would put this logic in the GameState or whatever "knows" about both the player and the level.   In my game, a "Room" is essentially the same as your "LevelSection" idea. When the player collides with a transition region, a change is made to signal that a "transition" is happening, then the game figures a few things out: The direction of the transition (upwards, rightwards, downwards, leftwards) The position of the next room If you know both of these things, then it's pretty easy to decide what to do next. While the "transition is happening now" flag is true you shift the camera a little bit in the direction of the next room. For Mega Man, according to my measurements, the camera moves 4 pixels-per-frame horizontally or 3 pixels-per-frame vertically while transitioning (at 60 frames per second). As you move the camera, you'll eventually move all the way to the next room -- so you basically just keep moving until you've positioned the camera exactly where you want it. Once the camera has moved to the desired location you unset the "transition is happening now" flag and everything goes back to normal. Since you know the position of the room and the position of the camera it is easy to tell when you've hit your goal.   As for moving the player, you do the same thing as with the camera but with a smaller amount of movement. I let my "game state" perform this movement -- my player object doesn't know its being moved because it isn't being updated during transitions.   Obviously, my actual implementation is a bit more complex than what is explained above -- but at the highest level that's what happens.
  2. I'm writing a Mega Man clone right now and have implemented the screen transitions. You can see videos with the transitions here:     The way that I implemented it is to split up the level in to rectangular "rooms". When two rooms connect it gives you an opportunity to perform a transition. Each room has a list of "Transition Regions" which are more-or-less just a rectangle and a transition direction. So if Mega Man is in room #1 then I only check if he's touching transition regions from that room. Once he touches one, a transition is triggered and once it finishes he is now in a different room. Once you're in a different room you only need to check for collisions between transition regions in that room. This allows you to implement both one-way and two-way transitions and prevents you from constantly transitioning back-and-forth in some other cases.   Rather than using magic tiles or "outside of the map" triggers, I would suggest you use a method as I described. It's not a lot of work and it's flexible. I came up with this solution after asking the same question on the Game Development Stack Exchange site: http://gamedev.stackexchange.com/questions/6712/mega-man-style-screen-scrolling-design.   Essentially the design looks something like this:     As for "where does the code that does the camera movement go", well, that's up to you. I have a class where the "game play" takes place and I handle the screen scrolling there. When you collide with a transition region it sets a flag that says "a transition is happening now". When that flag is true the screen scrolls to the next room. Once you get to the next room it sets the "transition is happening now" flag to false. That way you can "disable" game play while the transition is happening.     That's what I do when my "transition is happening now" flag is true. I don't think it's the Player's responsibility to know about transition movements -- something else should do that.
  3. Hello! Yesterday I completed my first run at implementing an SFML-powered backend for Guichan. Guichan has been a favorite of mine and so far I haven't seen a fully-working SFML backend for it -- so I made one.   You can find it here on GitHub: https://github.com/zackthehuman/guichan-sfml   Right now it is only the gcn::Graphics portion, I'll be working on getting input implemented in the next few days. I would really appreciate any feedback about this, especially about how it can be improved. I'm hoping that people will find this useful.
  4. How is your rendering loop set up? Are you using setTimeout? setInterval? requestAnimationFrame? It should be possible to draw a reasonable number of things to <canvas> without poor performance.
  5. I recently revised my map rendering code to do some optimization for performance. Before you do something similar, have you tested to see if your current design actually needs performance tweaking? That is, have you taken actual measurements and noticed bottlenecks caused by rendering excessive off-screen tiles? If not, don't worry about it. Focus on other things until it becomes a problem. If you are having an actual problem, one way to solve it is to find only the visible portion of tiles and draw those. This can be done rather easily and cheaply by keeping track of your "starting" X and Y tile positions, and just drawing a "screen width" amount of tiles from your starting point. You simply need to determine the range of tiles to draw based on which ones would appear on screen. Since you screen is 17 tiles wide, your ranges should always be ("starting X" .. "starting X" + 17). The "starting X" can be determined by the position of the view/camera. In my case, it's the left edge of the camera that's used to determine the "starting X". Another approach would be to pre-render your tiles to a larger texture, and then just render the portion that would be visible. If your tiles are not animated this approach will save a lot of extra rendering calls since the tiles are only rendered once.
  6. Mike, I can help you with this but I'm confused as to what you're trying to create, exactly. So far this is what I gather: You want two columns to visually fill the viewport 100% (vertically). You want to stretch a navigation bar across the top of both columns without causing the document height to be greater than 100%. It possible that you could just create faux-columns using a background image, but the actual <div> elements won't have 100% height. I would recommend using a technique like this because you'll run into headaches when using height: 100%, especially if you want to introduce margin or padding. If it would be acceptable to use background-image trickery, and just overlay your "real" columns on top, I would go that route. You can read about the faux-columns technique here: http://www.alistapart.com/articles/fauxcolumns/ You can read about an equal-height column technique here: http://matthewjamestaylor.com/blog/equal-height-columns-cross-browser-css-no-hacks If you need some other kind of solution, we can iterate on your jsFiddle and get things working.
  7. Were you trying SFML 1.6? I recommend using SFML 2 instead. The release candidate is pretty solid; I have been using it with much success. The API has changed a bit between 1.6 and 2, so that could account for missing classes/methods/etc. One piece of advice I would give is that you don't want to over-design your game. If you're coming from the C world, write your first iteration as something close to a procedural program, then iterate on that. It's important to have something working to build on, otherwise you could end up designing forever but never building anything that works.
  8. To address your second issue; that of timing, event loops, Win32 API... I have never written a game without some abstraction over window creation and event management. I've written games with Allegro, SDL, and SFML. Being that Allegro and SDL are C APIs, for writing a game in C++ using C++ concepts and conventions, I would recommend you giving SFML a shot. It's what I am currently using and find the API easy to use and pretty much non-restrictive. You can easily create a window and set up a game loop with something as simple as this: #include <SFML/Window.hpp> #include <SFML/Clock.hpp> int main() { sf::Window window(sf::VideoMode(400, 300), "Sweet Ninja Power"); sf::Clock clock; while (window.isOpen()) { sf::Event event; while (window.pollEvent(event)) { if (event.type == sf::Event::Closed) { window.close(); } } sf::Time elapsed = clock.restart(); update(elapsed); render(window); } return 0; } Of course, you can write a more "correct" game loop to take things like lag into consideration, but I hope this gives you the general idea. In my experience it helps to have tools that let you write a solution at a higher level, and when you need to dig deeper you can. I feel like SFML provides several of those high-level tools.
  9. I can address only your first problem with a solution that I am currently using (successfully). Rather than creating two separate classes (PlayerControllableBody and AIControllableBody) you can abstract the "Controller" into another object, and let the ControllableBody use it. class ControllableBody { private: Controller * controller; public: ControllableBody(Controller * controller); }; /** Interface for controllers. */ class Controller { public: virtual ~Controller() { } }; /** A controller that uses an AI script. */ class AIController : public Controller { public: virtual ~AIController() { } }; /** A controller that uses joystick input. */ class JoystickController : public Controller { public: virtual ~JoystickController() { } }; /** A controller that recieves instructions over a network. */ class NetworkController : public Controller { public: virtual ~NetworkController() { } }; This allows your different control implementations to vary without affecting the objects you want to control. It also allows you to change how an object is being controlled at runtime, by swapping the pointer to another controller. I am using this pattern, which is essentially a form of the Strategy Pattern, in a platformer/jump and run game right now. Here is one such controller's interface: class HeroActionController { public: virtual ~HeroActionController() { } virtual bool shouldMoveUp() const = 0; virtual bool shouldMoveRight() const = 0; virtual bool shouldMoveDown() const = 0; virtual bool shouldMoveLeft() const = 0; virtual bool shouldJump() const = 0; virtual bool shouldShootWeapon() const = 0; virtual bool shouldChargeWeapon() const = 0; virtual bool shouldSlide() const = 0; }; So within your ControllableBody, you can "ask" the controller if something should happen, and then act based off of that input.
  10. My game project is written in C++ but makes use of Lua, which is written in C. My logging functions use std::cout to write messages to a log file, but I'm not able to capture print messages that take place in Lua scripts in the same log file, since the Lua library uses sprintf and the like. I am using this code to redirect stdout but am receiving warnings from MSVC about freopen being unsafe. freopen( "file.txt", "w", stdout ); The warnings are not uncommon, and having found a thread about the exact warnings I decided to redirect stdout using a "stream redirection guard" as described in the thread. The redirection works for std::cout but not for stdout. This makes sense to me but I'm not sure how to achieve what I want. So is it possible to get both pointing to the same stream or file?
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!