# Does anyone try to Break their Game?

This topic is 1480 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I was wondering if there is anyone here that tries to break their game like me. What I mean is that I will deliberately press keys, or perform actions in-game that should freeze the game. I had a toggle feature in this one level and I kept toggling really fast to see if it would freeze.

The reason I do this is so that I can test whether or not the code is solid and the game runs fast. I think I have found out that booleans make things run faster. Toggling variables on and off to trigger functions seem to work faster than just changing functions (correct me if I am wrong.)

Anyone have any good tips on how to make an unbreakable game (programming-wise)?

##### Share on other sites

Yes, of course.

Even though I write unit tests according to TDD (test driven development) most of the time and run regression tests when new features are introduced, there are lots of functionality (and non functional requirements) that are hard (or impossible) to test automatically. There are also cases where it is possible, but preferable to test by exploratory testing. Almost all "ility" requirements, such as usability, availability, operability, stability etc. are best tested using exploratory testing, and exploratory testing done right means trying to break your application any way you can think of (and not think of by performing random actions).

One lecture that I find very motivating and interesting on the the topic of exploratory testing, and "testing to break" is this one by James Bach:

It is not about testing games in specific, but rather about testing in general. He knows what he is talking about when it comes to testing and he is fun to listen to, even if he comes across as a bit odd at times.. xD

##### Share on other sites

All the time. As a programmer, you are not only a designer, architect, detective but also a vandal. You want to break your games before other players do.

Breaking your game is actually a good idea because it not only makes you a better programmer but also better at logic.

From my experience, I remember when I was programming a character to move in 4 directions. Weirdness ensues when I pressed all four arrow keys.

Long story short, my movement code was button dependent when it should have been dependent on a character state and direction of the character.

A lot of the time, your initial code might work in terms of "English" but when you apply English directly to logic, that is where the bugs can actually happen quite often.

Bugs are all learning experience. Learn from them and embrace them all!

Usually a game can break because of faulty logic.

It is more important to question the coding style of your code and think about how it can affect your future code in the long term.

This was my old code for character idle animation:

if(direction.equalsIgnoreCase("right") && !rightPressed
&& !castingMagic && !attacking ||
(rightPressed && (upPressed || downPressed || leftPressed))
&& !castingMagic)

{

g.drawImage(idleRightAnim.getImage(0),(int)position.getX(),(int)position.getY(),null);
}



The old code was so bad. Eventually i had to scrapped it and re evaluate my logic. Here is the new code

else if(state == State.IDLE && direction == Direction.RIGHT)
{
soraIdleRightAnimation.draw(g2D);
}



My learning experience was if my code is hard to read there is probably a better approach that takes fewer lines. It is important not to over think it. My old code involves so much over thinking that it became a pile of mess.

Edited by warnexus

##### Share on other sites

This is actually a very common practice, especially in enterprise software. It's called Penetration Testing!

Cheers :)!

##### Share on other sites

put the console in a microwave, play the game underwater

oh dear...haha. That's a funny one.

##### Share on other sites

, pull the disc out a weird times, yank the network connection, put the console in a microwave, play the game underwater,

Haha! Never thought about that type of testing. Hahaha.

I think I understand now why IOS is so stable, and why, when/if you get an error, it happens gracefully. It is good to not only predict the best conditions, but the worse conditions, and then program with that in mind.

##### Share on other sites

It is a fact of life.
The only unbreakable code is code that is never run. If you are truly so paranoid, don’t write code.

Hmm. good point. I really don't like bugs, and I thought I could make a program so solid it would never have an error. But when things are variable, then errors can occur, even if it is a limit.

Speaking of limits. I think that limits should be established beforehand. Whether the limit be an integer value or the area in which a 3d character can move. The reason limits make sense is because we are used to it. I mean, the surface area of the earth is a limited space. It is harder to move around in a space without limits, mainly because we are so limited.

I think the world is the perfect system though, because it was made with limits, though it has many variables. All the limits were taken into consideration beforehand. There are even laws that establish limits. This reminds me of another post I commented in about having a law system in games.

Hmm, something to consider.

Edited by Tutorial Doctor

##### Share on other sites

Long story short, my movement code was button dependent when it should have been dependent on a character state and direction of the character.

Right! I had the same issue! Someone suggested that I learn co-routines. The whole state-dependent idea is the best idea I have seen. Of course you use booleans to create states. I actually submitted an article a while ago about how to code in an english type grammar. It was rejected though because I only use my alias Tutorial Doctor and not my real name (the thrill of secrecy).

It also makes things run faster. I could type something like:

happy = false
neutral = true

if happy then
...
end

...
end



etc.

##### Share on other sites

One lecture that I find very motivating and interesting on the the topic of exploratory testing, and "testing to break" is this one by James Bach:

It is not about testing games in specific, but rather about testing in general. He knows what he is talking about when it comes to testing and he is fun to listen to, even if he comes across as a bit odd at times.. xD

Thanks for that link! I am watching it now. I have always been the type to prefer documentaries over movies. I am starting to like lectures (been watching plenty of 1hr + lectures on youtube).

Edit: Finished watching the video! PERFECT! Lots of useful info in there, not just for software testing but for software development also.

Edited by Tutorial Doctor

##### Share on other sites

Yes, of course.

Even though I write unit tests according to TDD (test driven development) most of the time and run regression tests when new features are introduced, there are lots of functionality (and non functional requirements) that are hard (or impossible) to test automatically. There are also cases where it is possible, but preferable to test by exploratory testing. Almost all "ility" requirements, such as usability, availability, operability, stability etc. are best tested using exploratory testing, and exploratory testing done right means trying to break your application any way you can think of (and not think of by performing random actions).

One lecture that I find very motivating and interesting on the the topic of exploratory testing, and "testing to break" is this one by James Bach:

It is not about testing games in specific, but rather about testing in general. He knows what he is talking about when it comes to testing and he is fun to listen to, even if he comes across as a bit odd at times.. xD

Nice vid

##### Share on other sites

It's called Penetration Testing!

That's not quite it, but I'm going to look into that term. I think the video that was posted refers to it as Software testing. It seems that Penetration Testing is a subtopic of software testing (as far as what I gather from watching the video, this is new to me).

##### Share on other sites

Long story short, my movement code was button dependent when it should have been dependent on a character state and direction of the character.

Right! I had the same issue! Someone suggested that I learn co-routines. The whole state-dependent idea is the best idea I have seen. Of course you use booleans to create states. I actually submitted an article a while ago about how to code in an english type grammar. It was rejected though because I only use my alias Tutorial Doctor and not my real name (the thrill of secrecy).

It also makes things run faster. I could type something like:

happy = false
neutral = true

if happy then
...
end

...
end



etc.

You could use boolean for states but...that is a nightmare you do not want to create. If you did that, you would wind up toggling the other states that should not be active false and the only one state on. Doing that for every keyPressed or keyReleased is definitely not the way to go. It can be error prone too. You could try it just as a learning experience.

Instead, try using enums. That is what they are called in Java.

Edited by warnexus

##### Share on other sites
Two things --

If you're going to test, you need a test plan of some kind. Doing random, unexpected stuff is important, but focused testing (not focus testing), unit testing, and static analysis tools will find far more bugs. Just doing ad-hoc testing is like proclaiming a building is fit because you climbed up on the roof, jumped around for a bit, and it didn't collapse. Its not enough, you need to make sure that the foundations are solid, that the joints are sound, and that everything is built to code.

With that said, you'll never Eliminate every bug, and AAA games always ship with a few (or more). If the test team and devs have done their job, and the publisher hasn't rushed them out the door, the bugs will exist only beyond the margins of anything that's likely to happen in normal use. But practically speaking, that's about the best you can hope for. Edited by Ravyne

##### Share on other sites

At my work right now we are trying everything we can to break our product before sending it out! It is a very common thing to so and its good that you are also trying to do so as well!

##### Share on other sites

If you did that, you would wind up toggling the other states that should not be active false and the only one state on.

Well, I wanted to model my programming after real life, and thought it would be better to use booleans for states because states aren't really numerical in real life. For instance, if I am happy that is a state. Now, if I am happy and I am jumping around like a mexican jumping bean, then either I am ecstatic: I could code it like this (lua):

happy = false
jumpingAroundLikeAMexicanJumpingBean = false
ecstatic = false

function BeEcstatic()
if happy and jumpingAroundLikeAMexicanJumpingBean then
ecstatic = true
end


Then there would be an event that would trigger the BeEcstatic() function. It just seems that counting isn't required for states. Also, the BeEcstatic() function could trigger an animation also as well as set ecstatic to true. I am definitely going to look into enumerations (that is what enum is right)?

This is just an example I thought of just now, but I would plan out the structure of the code and I might not use the functions in the way above. I certainly wouldn't have a variable name that long. hahahaha.

Edited by Tutorial Doctor

##### Share on other sites

If you did that, you would wind up toggling the other states that should not be active false and the only one state on.

Well, I wanted to model my programming after real life, and thought it would be better to use booleans for states because states aren't really numerical in real life. For instance, if I am happy that is a state. Now, if I am happy and I am jumping around like a mexican jumping bean, then either I am ecstatic: I could code it like this (lua):

happy = false
jumpingAroundLikeAMexicanJumpingBean = false
ecstatic = false

function BeEcstatic()
if happy and jumpingAroundLikeAMexicanJumpingBean then
ecstatic = true
end


Then there would be an event that would trigger the BeEcstatic() function. It just seems that counting isn't required for states. Also, the BeEcstatic() function could trigger an animation also as well as set ecstatic to true. I am definitely going to look into enumerations (that is what enum is right)?

This is just an example I thought of just now, but I would plan out the structure of the code and I might not use the functions in the way above. I certainly wouldn't have a variable name that long. hahahaha.

You can call them enum or enum types. Enumeration is an interface in Java which from what I research does something completely different as an interface. You can use boolean to keep track of states for that example.

Enum should be used if you need to represent something as a fixed set of constants. Modeling game state or the sense of direction is more readable using enum types.

http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html

http://docs.oracle.com/javase/7/docs/api/java/util/Enumeration.html

##### Share on other sites

One of the rules for programmers is to pre-test their own code before submitting it for integration with other tasks and passing it to QA (Quality Assurance) testing. For example, in Java, this is done using JUnit.

Also, if you are working on a project yourself, you need to incorporate a great deal of self disciplined. For example, in my line of work, I must adhere to the SDLC (System Development Life Cycle). http://en.wikipedia.org/wiki/Systems_development_life-cycle

To further clarify, a perfect world example would be as follows. And please, I'm only including the part related to this thread:

As a designer, you need to develop a flow chart, UML or other form of plan'o'gram that gives you a general idea of what you need to make the most basic, working application possible. Once you have this, you need to break it down in tasks. Normally, tasks are broken down in classes. You only further add to the design after you reach the criteria of the current design. You stop at each level of your design. Assuming you planned out your most basic working application, you stop here for now.

As a QA (Quality Assurance) tester, you need to spend hours, if not days trying to break your program.  Don't fix anything as this is micro management and a bad habit. You document, and you do A LOT OF DOCUMENTATION. Make sure what you document is well defined and well coupled with a bug. Create severity levels to associate with the bug. (e.g., Understand the difference from a hard crash (CTD [crash to desktop]), a soft lock (endless loop resulting in a unusable program), and partial lack of functionality but a running program none the less). Once you can't find any more bugs, you stop here. If their are bugs in your quota, or the project is not ready to move into the implementation phase, you go back to your developing phase to apply the fix and/or designing phase to move into the next design model of your program.

You repeat this cycle until either you reach your time quota or the  achieve your design expectation; which ever one comes first. Then you move to the implementation phase; that's where you often see games moved into beta, for public testing.

To summarize, if you want to make a game unbreakable, you need to adhere heavily on the SDLC model, and you must practice extreme disciplined on yourself since its likely your doing it yourself. The two things that cause a game to be breakable is a deviation of the SDLC model or a time restraint. Remember that.

Hope this helps.  Feel free to amend anywhere I'm wrong or add further in areas I am weak on.  Thanks.

Edited by Subtle_Wonders

##### Share on other sites

Great post Subtle_Wonders. That is the reason I like posting here on Gamedev. I like lengthy and informative responses (yes, I do read them). I always reference my posts, and I don't post unless I can benefit from the responses as well. Also it helps people who are coming here looking for information. Nice variety here too.

I like how you say don't go to another phase until I finish one. That is one of my issues. I jump around to and fro. I never really have had a plan for a full project yet (tried to wing it once). Of course, I haven't had an idea that is attainable that I am interested in completing.

Right now I am only testing ideas because I still need to work on my 3d modeling, texturing, programming and animation skills (all on my own on this). I am going to check out the SDLC model right now. Thanks!

Edit: Thanks for that Wikipedia link! Lots of good information there, and it is almost just what I needed to read! I am excited about it though, because I needed some educated information on how to get a project started and how to follow through with it.

I like the part about the feasibility study. Going to look int RAD and XP also. Thanks again.

Edited by Tutorial Doctor

##### Share on other sites

Great post Subtle_Wonders. That is the reason I like posting here on Gamedev. I like lengthy and informative responses (yes, I do read them). I always reference my posts, and I don't post unless I can benefit from the responses as well. Also it helps people who are coming here looking for information. Nice variety here too.

I like how you say don't go to another phase until I finish one. That is one of my issues. I jump around to and fro. I never really have had a plan for a full project yet (tried to wing it once). Of course, I haven't had an idea that is attainable that I am interested in completing.

Right now I am only testing ideas because I still need to work on my 3d modeling, texturing, programming and animation skills (all on my own on this). I am going to check out the SDLC model right now. Thanks!

Edit: Thanks for that Wikipedia link! Lots of good information there, and it is almost just what I needed to read! I am excited about it though, because I needed some educated information on how to get a project started and how to follow through with it.

I like the part about the feasibility study. Going to look int RAD and XP also. Thanks again.

Glad I could help. I used to work on voluntary game projects at Hard Light Productions found here: http://www.hard-light.net/. They made ready use of the donated Freespace 2 game engine from Volitation: http://en.wikipedia.org/wiki/Volition,_Inc. I wasn't a programmer back then but what I often saw were really great idea's crush or projects completed but not nearly to the expectation it was set to because of poor control over the project. Management over a project is just as important, if not by far more important than the programmer him/her self.

The one group who really achieved much at Hard Light Productions was the Wing Commander Group backed by Tolwyn. Their game could be found here: http://www.wcsaga.com/. You can quite literately feel the work and professionalism in their product. Tolwyn made full use of project management. He was very organized. He had a bug tracker, a story script, he broken down teams and assigned them small tasks. It may have taken him well over 4 years, but he produced a really top notch game because he was very well disciplined with the development model he was using.

Edited by Subtle_Wonders

##### Share on other sites
I tried to vote your first post up (subtle_wonders), but I accidentally tapped the down arrow, and it won't let me change it. Sorry. Voted the last one up though .

##### Share on other sites

I tried to vote your first post up (subtle_wonders), but I accidentally tapped the down arrow, and it won't let me change it. Sorry. Voted the last one up though .

LOL I was curious about that.  It's cool. Thanks much for letting me know. At least you got what you needed, so I'm happy about that.