Hey just wanted to find out if anyone else here hits the wall while developing a game and how they go about breaking through it.
What I mean by hitting the wall is coming to a point where you either dont know what to do next or get to a part that is hard and you cannot seem to figure out how to implement it.
An example is right now I am trying to implement a fight system in the game I am currently coding in php. It is a PBBG about prisons and the players inevitably will fight against each other. I am stuck on how they will actually fight each other. Will it be automatic or turn based? Which stats will be used in fighting and how are they calculated. I am trying to keep it simple in design as it is my first attempt at actually coding a full game.
Anyway how do you break through the wall?
Hitting the wall
Re: Hitting the wall
Use a pickaxe or sledgehammer?
Just so i`m clear, i`m not joking. Try doing something radically. Do something else, add other functionality, maybe write a story for the game, create artwork? Whenever I hit the "wall", i`m going to do something else and while working, a light will blink and I found the solution to the original problem, the wall.
Just so i`m clear, i`m not joking. Try doing something radically. Do something else, add other functionality, maybe write a story for the game, create artwork? Whenever I hit the "wall", i`m going to do something else and while working, a light will blink and I found the solution to the original problem, the wall.
-
Jackolantern
- Posts: 10891
- Joined: Wed Jul 01, 2009 11:00 pm
Re: Hitting the wall
It seems more like you are referring to not being able to continue vs. losing the will power to continue (and the latter is a totally different conversation, although an equally important one).
Basically you just have to go back to time-tested software design procedures. Design out what it will do first, down to all parts. Then you look at the process as a whole (the 10,000 foot view) and you keep breaking it down into smaller and smaller pieces, doing more and more discrete mechanisms. Then you start thinking about the algorithms to get it done.
But the most important thing is to think about how you want combat to work first. You are likely getting the requirements, design and development phases (three totally different steps in software development) muddles together or are trying to do them all at the same time. That is always going to cause problems and will repeatedly make you hit road blocks like this. First you determine what you want your program to do, completely independent of code (the requirement phase), then you determine from a higher level how you are going to do it and what parts you need (the design phase) and then you actually code those parts into existence (the development phase).
Basically you just have to go back to time-tested software design procedures. Design out what it will do first, down to all parts. Then you look at the process as a whole (the 10,000 foot view) and you keep breaking it down into smaller and smaller pieces, doing more and more discrete mechanisms. Then you start thinking about the algorithms to get it done.
But the most important thing is to think about how you want combat to work first. You are likely getting the requirements, design and development phases (three totally different steps in software development) muddles together or are trying to do them all at the same time. That is always going to cause problems and will repeatedly make you hit road blocks like this. First you determine what you want your program to do, completely independent of code (the requirement phase), then you determine from a higher level how you are going to do it and what parts you need (the design phase) and then you actually code those parts into existence (the development phase).
The indelible lord of tl;dr
-
Sharlenwar
- Posts: 523
- Joined: Mon May 28, 2012 7:14 pm
Re: Hitting the wall
To add to Jack's comment, it is always better to have the game developed to every aspect before you even start coding. The reasoning for that is what is going to happen if this fight code you want to implement causes you to redesign the entire game? You are going to be back to square one.
What sort of combat did you want? Did you want it where the players can decide to fight, so where they initiate the combat? Then if they can start to fight, are you going to have it go through the automatic process, or where you get player input for each attack?
As far as that wall, for me it tends to be real life that gets in my way of working on a game. So I usually ignore everything and carry on forward. For those coding moments where I feel stuck, I'll do what Xaleph suggested. Go work on a different aspect until the light bulb turns on.
What sort of combat did you want? Did you want it where the players can decide to fight, so where they initiate the combat? Then if they can start to fight, are you going to have it go through the automatic process, or where you get player input for each attack?
As far as that wall, for me it tends to be real life that gets in my way of working on a game. So I usually ignore everything and carry on forward. For those coding moments where I feel stuck, I'll do what Xaleph suggested. Go work on a different aspect until the light bulb turns on.
Deep within the Void of Quasion, a creation.
**My Corner of the Web**
***NEW***GrindFest - My own PHP/MySQL game!
Sharlenwar's Adventures
Torn-City - Massively multiplayer online text based RPG
**My Corner of the Web**
***NEW***GrindFest - My own PHP/MySQL game!
Sharlenwar's Adventures
Torn-City - Massively multiplayer online text based RPG
Re: Hitting the wall
Try to attack a smaller wall first? IMO, one of the big problems is a programmers own perception of what is a 'full game'. Their perception of a full game is generally a big wall to get through, while any small wall is 'not a full game'. But like a weight lifter, you start with the smaller weights first. Weight lifters don't say smaller weights 'are not full weights'. They are. I'd recommend trying to write a 'guess the number game', even if only single player. You should be able to knock that on the head in a short time. That shows you can burst throught that thickness of wall. Then figure a slightly larger game and try and code that. Figure out what thickness of wall is actually tough for you. The thing is, even finishing the guessing game will prove to yourself that you are able to knock through a wall, so it makes you less likely to give up knocking through harder walls. Improves your morale.
Yeah, this question comes up alot around here. As with the advice above, I'd suggest a smaller wall at first - automatic.Will it be automatic or turn based?