• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Gorge Express

Members
  • Content count

    5
  • Joined

  • Last visited

Community Reputation

179 Neutral

About Gorge Express

  • Rank
    Newbie
  1. For something simple like shooting a projectile, i'd just give the class dealing with input access to the sprite manager so that it can create the projectile sprite.  The sprite manager should be able to do the rest, storing the sprite in some structure and iterating over that structure calling each sprite's update method each frame.    Also you should probably store the player's direction in a variable. If you can only face right or left, you can use a boolean. 
  2. Well, you could use flags I guess. Lots and lots of them.    Or you could save the state of the world, instead of reloading it anew. Serializing the entire world is one way to do that, though it's inefficient.    Another option is to reference information from both a "base world" and your save data to construct each object at the necessary location. Your game would keep track of only things about the object that can change, like position or if a button is activated or not or whatever. It would also have some kind of unique id. The id would reference an object in the base world, which contains the rest of the info necessary to construct the object. 
  3. Thanks for all the input.   fun fact: Not only did Nintendo have to position the sword near Link's hand each different frame, but they also had to determine how to rotate the sprite. There are 36 different frames of the normal sword swinging animation, but only 8 different sprites for the sword. Link himself usually consists of 2 different sprites(he is only 1 sprite in some arbitrary frames) and they just change the x and y position of his head to make it look animated. Must have been fun doing all that in assembly.    Anyways, what is a good way to deal with the timing of  actions specifically? That is, the activation/addition of a hitbox to the sword after a delay(or the check to see if an enemy is in front of the player), and the removal of the sword+reverting the state of the player back to normal after the action(which lasts an unknown amount of time) is done? The action must also end early if the player is hit. 
  4. LttP was made in assembly, so they would've had to do things the hard way :p but yea, i was just using it for an example.   FSM sounds like what i was saying I would do. Using only a FSM to address the problem would be a real pain if you need to implement a lot of actions though.    Using a data structure that takes care of itself makes sense too. Though something in the code would still have have to handle adding and removing the sword entity, adding and removing the hitbox, and changing the player state. You can't just change the player state out of "attack mode" after a set amount of time, because that amount of time isn't always known(imagine the hookshot in any Zelda game. If it hits a wall, you gain control of the player back sooner.)
  5. I'll use Link to the Past as an example   Frame 1: [attachment=15864:link1.jpg]   Link takes out his sword and begins the attack animation. Though the sword is being rendered, it has no hitbox yet. For the next couple of frames, pressing the d-pad or any buttons will have no effect on Link.    Frame 3: [attachment=15865:link2.jpg]   The sword now has a hitbox and can collide with enemies.   Frame 6: [attachment=15866:link3.jpg]   The player can now press attack to interrupt the current attack animation and start a new one. Any other input is still ignored.    [attachment=15867:link4.jpg]   On the last frame of the animation (13), the game checks to see if the attack button is held down. If it is, Link enters a new state where he begins charging his sword. If not, on the next frame, the animation ends, the sword disappears, and full control is given back to the player.   I'm wondering, how would people approach the problem of implementing "actions" like these in a video game? Where rather than the action taking place in a single frame, it takes place over several frames and updates certain things(like the position of the sword is always attached to link's hand, even if he is moved by some outside force during the animation) each frame. With access to today's technologies of course.    Best i can come up with for an "attack" action is hard coding it based on states. Pressing attack puts Link in the "Sword Attack" state and starts a timer. The game sees this, then creates the sword and starts playing out the animations. Each frame, the game updates, checks the time passed to see if it should add the hitbox or whatever it needs to do. The second half of the animation would have its own state, so the game knows that it is allowed to accept input for another attack to interrupt the current one.   That means coming up with a different set of states for every action in the game though, which would be a pain. Especially in a component+entity system, where you would need to add the code into a State System or something instead of each entity's  own update method.  So i'm wondering to see if there are better ways to handle this, especially more data-driven ways.