• 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.


  • Content count

  • Joined

  • Last visited

Community Reputation

404 Neutral

About PyroDragn

  • Rank
  1.   There were two different questions to hand:   "what would you design if you had funding?"   and   "what do you suggest I do with my cousin's offer?"   You answered the second by saying "don't do it" but the first question, and the one in the title of the post, you didn't answer at all, so I guess that Mratthew is technically correct in that respect.   I have to sort of disagree with your answer of "don't do it" though. I'm sure everyone would agree that you shouldn't waste the money, but that would hold true whether it came from family, or another funder. He doesn't seem to have experience, so he needs to be careful, he needs to do a lot of planning, but no-one goes in to any investment planning to fail.   Millionaires aren't millionaires because they just throw away their money, sure. But not all families are entirely unforgiving, or entirely capitalist in their intentions. The idea that a rich family member may be offering a small cash injection in order to get a family member on their way in a venture they enjoy isn't exactly an impossibility.   The important thing is to find out what is being offered, and the terms for the offer. How much is it? Is it a loan, gift, or investment? What does your cousin want in return? I don't know anything about the parties involved, so there's no basis for judgements. The sentiment to be careful with your family's money, makes sense. To say "don't do it because if you don't make any money then your family will be angry with you forever" is entirely speculative. 
  2. Are the artists on board friends of yours, or are they people you have met online/recruited?   Who is going to be in charge of the design?   If the artists are your friends, then they probably expect some say in what project you go forward with. Even if they're not, you'll want to try and make something that they would be interested in (and therefore more motivated to complete). The most annoying thing that can happen is to start developing a game, and then have the team fall apart because of lack of interest.   You've never programmed AI before, are you therefore expecting to start with something with simple AI to learn? or to jump right in to learning complex AI programming? Get someone else in to help? or to make a game with no AI at all?   If this is your first project (it seems like it is) then you want to aim small. A lot of people jump right in with 'their ultimate team' to create 'the ultimate ultra-super MMO that will revolutionize the industry.' That's just not going to happen if you've never made a game before. A simple puzzle game is your best bet if making something without any AI, or some kind of directly competitive multiplayer game (so you only play versus other people, rather than any AI).   Designing a brand new puzzle game is not easy, and another rehash of a Chain Reaction or Bubble Pop game isn't going to net you much in the way of value or getting on steam - it might be a consideration if you're more interested in the experience at this point, which is a viable route to be taking. A competitive multiplayer game is probably easier to come up with a concept for, but going to be harder to program (in terms of networking and sending/receiving data, although local only multiplayer would be easier).   The questions right now would be, what do you (and your other team members) like to play? What sort of artwork are your artists used to working with? (if they work with 2D sprites, then designing a full 3D modeled game may be out of their league for example). Having possible funding is great. Wasting it is not.   Give some more information on what would you like to build, and maybe we can help brainstorm things through with you.
  3. Your post so far as said "I want to make a game with things which do things." Is this workable? Sure. Almost every game has things which do things. Is there much else to say besides that? Not until you give more detail.
  4. As Sporniket said above, one possibility is to have multiple outcomes - ie, the choices of the player affect the outcome.   This would increase the workload quite a bit in determining plot. Multiple outcomes/choices means multiple paths and more writing. This does also have the benefit of increasing replayability however, since the player can play again and make a different choice.   Alternative to this is to consider multiple paths to the same outcome. This would mean less writing in terms of storyline, but still a greater portrayed freedom to the player. As a very basic example; In order to progress the player needs to cross a river, get through a locked door, and past a troll. He has a rope, a golden key, and an axe.   1. He uses the rope to cross the river, unlocks the door with the key, kills the troll with the axe 2. He uses the rope to cross the river, smashes his way through the door with the axe, bribes his way past the troll with the key 3. He fells a tree across the river with the axe, unlocks the door with the key, sets up a snare to trap the troll with the rope 4. He fells a tree across the river, ties the rope to the door - and a boulder - then pushes the boulder off a cliff to yank the door open, he bribes his way past the troll with the golden key. 5. He uses the key to pay for a ferry to take him across the river, smashes his way through the door with the axe, sets up a snare to trap the troll with the rope 6. He uses the key to pay for a ferry to take him across the river, ties the rope to the door - and a boulder - then pushes the boulder off a cliff to yank the door open, kills the troll with the axe.   This shows the same three items, in the same three scenes, used in a multitude of options. The key to not feeding the player the story is to allow the player the essence of choice, even if those choices prove essentially meaningless. If the player has a choice between climbing a wall, or going through a gate, then it seems better to the player even if they both (eventually) lead to the same point inside the castle.
  5.   Having the environments and everything modeled in full 3D before you get the programmers in is usually - again, depending on the game - going to be a problem. There's not usually much point in modelling everything if you don't have a basis for the physics, the engine, collision detection, etc. If you're using, for example, the Unreal 3 engine then perhaps you could start doing modelling before you get other programmers in, but that's because a large chunk of the programming has already been done beforehand.
  6. [quote name='hpdvs2' timestamp='1358909611' post='5024572'] If that Y-force is at 0 [/quote]   To address this point made my hpdvs2, you cannot simply check to see if the force is at 0 since the force would also be at 0 at the peak of the jump, this would make it possible to jump again while at the top of your jump an infinite number of times.
  7.   Around the 14-15 second mark in the video, when you're jumping to hit the second ! box, it doesn't seem to detect the hit each time. You end up jumping once when it appears you're still inside the box (3rd jump) and the fourth jump looks like it should register, but you don't get the last coin until you pause a moment for your fifth jump. Looks mostly like you're able to repeat a jump while inside the box and therefore the collision doesn't register since the last collision is still valid.
  8. Just a critique based on the video; the collision detection for your box hits doesn't seem to be consistent. Don't know what kind of collision detection you are using but it might need some tweaking.
  9. [quote name='Lauris Kaplinski' timestamp='1350460970' post='4991046'] Some prefer grinding - i.e. slow low-risc scenario. [/quote] I agree that there are different playstyles, ie Fast: High Risk, and Slow: Low Risk, but I would disagree that grinding is slow. A lot of people grind because it is the fastest way to achieve a particular goal. Grinding a particular mob for a drop, or for gold. Grinding skills or leveling, etc. While leveling in an RPG, some people may prefer to grind mobs in areas below their level because it is low risk. Some people may prefer to grind above their level, because it is high reward. The problem is that there are lots of reasons to grind:[list] [*]The person grinding below their level may have tried the higher level areas and failed, therefore grinding in the lower areas is their fastest way to level. [*]The one grinding in the higher level areas may be dying a lot, or not get much reward for their time since it takes so long to kill things, so it is slower at leveling but more enjoyable. [*]Alternatively someone in a high level area may be killing things at a decent pace and it is a much faster way to level. [/list] They are however, all still grinding.
  10. [quote name='Bluefirehawk' timestamp='1350458489' post='4991041'] Here I think the bad thing is that you level up an action, that is not fun or in the main part of the gameplay. Hence if you slowly leveled your pickaxe, you would not have cared, or even liked it, I guess. [/quote] I'm going to reiterate this point because I see it slightly differently, though I agree with the main premise; you should level up through the main gameplay, not encourage grinding. The OP found himself repeatedly jumping off of a ledge to level his acrobatics, I doubt he liked doing this, but he did care because he wanted to minimise fall damage. If there was an ability to level up your pickaxe skill (with a decent outcome, ie, more powerful pickaxe), then the player is usually going to care about obtaining the outcome. If you make the leveling take part from mining, then the character is more likely to go around and progress their leveling through regular gameplay. If all they have to do is stand in one place and swing their pickaxe, then it encourages the player to do exactly that. You have to balance the time it takes to level, vs the effort, vs the enjoyability. Comparing "Mining to level" vs "Swing your pickaxe" to level (aka, play vs grind); If each swing of your pickaxe gives the same experience regardless of whether you hit something, then it's easier not to bother looking for something to hit (less effort), faster (less time wasted looking), but less enjoyable (doing nothing but repeating the same action is monotonous). If you gain more experience by using your pickaxe instead of just swinging it, then mining is faster (more reward per swing) and more enjoyable (more active involvement by the player). Whether or not it takes less effort is harder to quantify, because there are a lot more factors. Standing still with one button pressed, or repeatedly clicking (or automating the button press and going AFK) is mostly effortless - which is easy to understand. How much effort does it take to run around the map and find things to mine though? If I am going to play the game, and [i]mine anyway[/i], then I will level up through [i]no extra effort[/i]. If I was going to play the game, and [i]I wouldn't mine[/i], except for the purpose of leveling then the [i]act of mining does take extra effort[/i]. Now, introducing any sort of leveling system requires balancing - risk vs reward - and you always risk detracting from other gameplay aspects. If you level up one action, by repeating that action, then someone is probably going to concentrate on grinding the levels. Whether that means staying in one place (swinging your pickaxe), or focusing on that particular aspect of the game (running around the map, ignoring everything else and just mining).
  11. [quote name='meeshoo' timestamp='1349875445' post='4988710'] A gamer is not necessary a person who plays games on a regular basis. A gamer is a person with the right attitude towards playing games. This person must be playful and creative, ready to accept challenges just for the fun of it or ready to learn new things a game would throw at it. It requires a certain state of mind to have fun with a game. Someone who plays a game with an attitude of rejection for any challenge or mechanic or stuff that the game requires him/her to do/learn is a non-gamer in my view. [/quote] I'd disagree with this in part. I feel that a gamer is someone who actively enjoys gaming as a past time. They could be sporadically playing, ie a casual gamer, or play non-stop. I have friends who enjoy playing games, but aren't gamers. They can sit down and play a game, have fun with it, enjoy it - they have the right attitude - but it isn't something that they would actively pursue. As an example, a friend of mine adores Bejeweled, plays it a lot, enjoys it, but she's definitely not a gamer. It's just an enjoyable thing to do, but it'd be in the same sect as watching a movie or something. Similarly, I can enjoy playing a game of football with friends, but I'm not a sports-person. [quote name='meeshoo' timestamp='1349875445' post='4988710'] Someone who plays a game with an attitude of rejection for any challenge or mechanic or stuff that the game requires him/her to do/learn is a non-gamer in my view. [/quote] This, I think, doesn't have anything to do with being a gamer or not. It could be a gamer who doesn't enjoy the particular style of game, or it could be a non-gamer. Being a gamer doesn't mean being open-minded, in fact I would say that there'd be a great liklihood of gamers rejecting a game outright, on principle, because it's different to previous experience, or just because it's not "insert their favourite game." [quote]personally a "grind your teeth" game is the one to play (because I have accumulated to much gameplay experience over the years and I consider less challenging games uninteresting, maybe that is why I never play on the go)[/quote] I'm going to have to be a pedant here and try to reiterate something about phrasing: [i]'Personally a "grind your teeth" game is the one to play... I consider less challenging games uninteresting'[/i] - That's fair enough. Everyone has their own taste. [i]'Personally a "grind your teeth" game is the one to play because I have accumulated too much gameplay experience over the years'[/i]- this isn't really true, or at least it isn't going to be based on the fact that you've played a lot of games. Maybe you've played a lot of games, so now there are less games that are challenging, and you enjoy a challenge. It isn't that, the more you play games the more you like challenging games. If you played Hello Kitty online continuously for a while would you like challenging games more? As a comparison, I like sweets. I've eaten a lot of sweets over my life. Some I like, some I don't like. The ones I love aren't because of all the sweets I've eaten in my lifetime, I love them because I think they taste nice. Maybe eating a bad sweet will make me appreciate a good sweet more. But eating a bad sweet doesn't make all sweets bad. Eating a good sweet doesn't make all sweets good. Eating more sweets doesn't make all sweets better. Playing a bad game can make you appreciate a good game. But playing a bad game doesn't make all games bad. Playing a good game doesn't make all games good. And playing more games doesn't make all games better. I know this seems a bit like the grammar police going on a rampage, but it seems like you want your blog to go forward, and I'm just trying to help you see where more clarity may be needed.
  12. You say it seems to be skipping your else statement, can you say what the result of the program is, and what you would expect? Ie. Is it not running, is it giving incorrect win values?
  13. [quote name='superman3275' timestamp='1349823842' post='4988523'] Sorry, ^ That's kind of what you said, just simpler. Essentially I have 4 collision variables(ballx/bally at the beginning of the game loop, ballx/bally at the end) I update before and after I move the ball and check to see if collision was skipped every game loop. If collision was skipped, I move the ball back to where it should be using some basic linear algebra. [/quote] Essentially that should work, yeah, basically the loop should look something like: Take Ball Start Point. Calculate Ball End Point Check for Collision Along Path If No collision, draw ball at end point If there is a collision, calculate effect of collision. Now, what you do when a collision occurs is going to depend on how accurate you want the ball's behaviour to be. If you redraw at the point of collision then work from there with the next loop, that's technically going to be decelerating the ball. Normally speaking this is going to be for a bare fraction of a second, but it may be something you want to consider. If you imagine the ball is moving 100 pixels per frame. You calculate the path, then determine that it hits an object 40 pixels in front of it. If you redraw the ball at the point of impact, then the ball has only traveled 40 pixels in that frame (40% speed). It should have hit the object, adjusted its vector, and traveled another 60 pixels, which is where you should draw the ball - ie, at its new end point, not at the point of collision.
  14. As promised in my previous post, these are my musings on the subject: I think I've come up with a reasonable solution, that would work to determine collisions for a ball moving at any speed without skipping through any objects. This does rely on bounding box checks, so if you want to use something more accurate then this isn't going to be it. As FloatRects were mentioned I'm working on the assumption that using bounding boxes for collision checking is going to be good enough. I haven't written the code because I don't know enough C++ to do so, hopefully my description is easy enough to follow. Some of the later math and theory is perhaps a bit abstract and I hope it's not too complicated (and I hope I didn't get my theory mixed up somewhere). [img]http://img600.imageshack.us/img600/1409/collision.png[/img] I use the above illustration as an example for various points. The ball starts at the position in the lower right, and travels to the top left. Noteable Variables are: Ball Height = 10 Ball Width = 10 Ball starting X = 100 Ball starting Y = 200 Ball finish X = 50 Ball finish Y = 100 Block Height = 10 Block Width = 20 Red Block X = 60 Red Block Y = 120 Blue Block X = 80 Blue Block Y = 130 Draw a bounding box around the extremes of the movement. Check if this box intersects with any other boxes. This is a very rough check to see if there's any chance of collision. There's no need to do a pixel perfect check if there's no blocks nearby. If there are boxes, take note of their variables. Red Box: Top = Y = 120, Left = X = 60, Bottom = Y + Height = 130, Right = X + Width = 80 Blue Box: Top = Y = 130, Left = X = 80, Bottom = Y + Height = 140, Right = X + Width = 100 Find the distance the ball moved horizontally and vertically: Sqroot((BallBefore.X - BallAfter.X)^2) = Moved.X sqroot((BallBefore.Y - BallAfter.Y)^2) = Moved.Y From our example: 100 - 50 = 50 50^2 = 2500 Sqroot(2500) = 50 200 - 100 = 100 100^2 = 10000 Sqroot(10000) = 100 Therefore: Moved.X = 50 Moved.Y = 100 The reason for Squaring, and then Square Rooting the variable is so that you end up with a positive result at the end. We want to find the distance moved horizontally, it doesn't matter if it's left to right or right to left. Now determine which of these is larger: if Moved.X > Moved.Y Then HorizontalMovement = True Else HorizontalMovement = False End if If Both variables happen to be the same size it doesn't matter which variable we use for comparison later, so a simple if/else is fine so that one or the other gets priority. From our example: Moved.Y > Moved.X so HorizontalMovement = False (the ball is travelling more vertically than it is horizontally) Now comes some of the more awkward parts: Take the difference between the movement in the non-primary direction of travel, and divide it by the distance moved in the primary direction of travel. if HorizontalMovement = False then MoveRatio = (BallBefore.X - BallAfter.X) / Moved.Y Else MoveRatio = (BallBefore.Y - BallAfter.Y) / Moved.X End If This gives you the ratio for the smaller increment of travel. For each pixel moved in the primary direction (in our case, vertically) you move this amount horizontally (in our case -0.5) Now find the actual direction of travel in the primary movement. If HorizontalMovement = False then if BallBefore.Y > BallAfter.Y then Direction = MovingUp BlockImpact = Bottom BallImpact = Top Else Direction = MovingDown BlockImpact = Top BallImpact = Bottom End If Else if BallBefore.X > BallAfter.X then Direction = MovingLeft BlockImpact = Right BallImpact = Left Else Direction = MovingRight BlockImpact = Left BallImpact = Right End If End If Now according to the direction of travel we want to sort the blocks in the list. In our Case the ball is moving upwards, and so we want to start with the bottom most block and sort through the blocks going upwards as we check for collisions. This is the actual collision check you will want to repeat for each block in the list: Now for each block in the list we want to loop through in order and check for collisions: Find the difference between the starting BallImpact position and the BlockImpact position. In our example this means the difference between the top of the ball, and the bottom of the block. DistanceMoved = Sqroot((Ball.Impact - Block.Impact)^2) According to our example, for the first block (the blue block), Ball.Impact = Top of the Ball start position = BallBefore.Y = 200 Block.Impact = Bottom of the Blue Block = 130 + Height = 140 200 - 140 = 60 sqroot(60^2) = 60 DistanceMoved = 60 Multiply this by the MoveRatio RatioMoved = DistanceMoved x MoveRatio DistanceMoved = 60 MoveRatio = -0.5 RatioMoved = -30 Now we use the ratio moved along with the primary direction of movement to see if a collision is true If HorizontalMovement = False then if (Ball.X + RatioMoved < Block.X + Block.Width) and (Ball.X + Ball.Width + RatioMoved > Block.X) Then Collision = True Collision.X = Ball.X + RatioMoved Collision.Y = Block.Impact Else Collision = False End if Else if (Ball.Y + RatioMoved < Block.Y + Block.Height) and (Ball.Y + Ball.Height + RatioMoved > Block.Y) then Collision = True Collision.X = Block.Impact Collision.Y = Ball.Y + RatioMoved Else Collision = False End If End If From our example HorizontalMovement = False Ball.X + RatioMoved = 100 + -30 = 70 Block.X + Block.Width = 80 + 20 = 100 70 < 100 = True Ball.X + Ball.Width + RatioMoved = 100 + 10 + -30 = 80 Block.X = 80 80 > 80 = False Therefore, Collision = False If Collision is false then you want to loop and check the next block in the list. If Collision is true, then Collision.X and Collision.Y will give you the position the ball would be at, at the point of collision. What you do from there is up to you. The easiest (though technically inaccurate again) is to redraw the ball at the point of collision, and react accordingly. Looping through the example for the Red Block: DistanceMoved = Sqroot((Ball.Impact - Block.Impact)^2) Ball.Impact = Top of the Ball start position = BallBefore.Y = 200 Block.Impact = Bottom of the Red Block = 120 + Height = 130 200 - 130 = 70 sqroot(60^2) = 70 DistanceMoved = 70 RatioMoved = DistanceMoved x MoveRatio DistanceMoved = 70 MoveRatio = -0.5 RatioMoved = -35 If HorizontalMovement = False then if (Ball.X + RatioMoved < Block.X + Block.Width) and (Ball.X + Ball.Width + RatioMoved > Block.X) Then Collision = True Collision.X = Ball.X + RatioMoved Collision.Y = Block.Impact Else Collision = False End if Else if (Ball.Y + RatioMoved < Block.Y + Block.Height) and (Ball.Y + Ball.Height + RatioMoved > Block.Y) then Collision = True Collision.X = Block.Impact Collision.Y = Ball.Y + RatioMoved Else Collision = False End If End If From our example HorizontalMovement = False Ball.X + RatioMoved = 100 + -35 = 65 Block.X + Block.Width = 60 + 20 = 80 65 < 80 = True Ball.X + Ball.Width + RatioMoved = 100 + 10 + -35 = 75 Block.X = 60 75 > 60 = True Therefore, Collision = True Collision.X = Ball.X + RatioMoved = 100 + -35 = 65 Collision.Y = Block.Impact = Bottom of Red Block = Block.Y + Block.Height = 130 The Ball collides with the Red Block when the ball is at position: 65, 130
  15. Can you explain more about the setup you have for these two objects: What part of the objects are you referencing in regard to reporting their position? How are you rotating the first object? You said that you're rotating the one object about the origin, then moving it in to place, then rotating the second object (presumably by the same rotation) and then trying to move it in to place. [b]It seems to me that it should just be a simple case of rotating both objects at the same time around the same point from their original position, then you translate both by their same factor of movement.[/b] If this won't work then you are going to have to rotate each object individually, then move the first object in to position, calculate the respective positioning of the second object based on the rotation, and then move the second object in to place. If you can explain how you want to rotate the objects then I might be able to help with working out the appropriate formula.