Jump to content

  • Log In with Google      Sign In   
  • Create Account


Does anyone try to Break their Game?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
22 replies to this topic

#1 Tutorial Doctor   Members   -  Reputation: 1435

Like
1Likes
Like

Posted 27 December 2013 - 09:12 AM

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)?

 

 


They call me the Tutorial Doctor.


Sponsor:

#2 Samith   Members   -  Reputation: 2041

Like
8Likes
Like

Posted 27 December 2013 - 10:09 AM

Before any game ships the publisher and console manufacturer will send it through a tough round (or even multiple rounds) of QA testing where they intentionally try to break your game. They'll do things like push buttons really fast, hold buttons forever, toggle things quickly, walk into every wall looking for collision bugs, pull the disc out a weird times, yank the network connection, put the console in a microwave, play the game underwater, etc, and make sure everything either works or fails in the correct way (for example by showing the right error popup when the disc has been removed).

 

I don't have any hard and fast rules for writing unbreakable code. Code is going to have bugs. That's a fact of life. Some people might suggest writing meticulous unit tests, though I've never found that to be particularly practical/helpful in games. The buggiest areas of games tend to be the areas that are the least friendly toward automated testing, unfortunately. I think what's worked best for me in the past is to make sure the game is tested thoroughly (by a human) throughout development, so you aren't overwhelmed when QA time comes. Keep a database of open bugs and prioritize them, making sure to keep the total number of bugs to an acceptable level. 



#3 L. Spiro   Crossbones+   -  Reputation: 12308

Like
8Likes
Like

Posted 27 December 2013 - 10:28 AM

If I test my game under extreme conditions 1,000 times and it fails once, it is broken.
If I test my game under extreme conditions 1,000 times and it never fails, it is broken, but I don’t know where. 1,000 more tests needed.

Anyone who is serious about game development tests not only as much as you, but more than you. Since last year’s end-year party I have been playing a game I won in a company lottery almost every day for the whole year since then.
It took about 8.52 months before I finally found a lock-up, after it handled thousands of similar cases just fine before that.
Approximately 4.17 months before I found a bug that was not serious and caused some laughter.


Yes, people are testing more than you.
Does that actually matter? To some degree but generally no. Bugs found due to investigation. Bugs still overlooked. 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.


L. Spiro

Edited by L. Spiro, 27 December 2013 - 10:28 AM.

It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#4 AlanSmithee   Members   -  Reputation: 960

Like
2Likes
Like

Posted 27 December 2013 - 11:16 AM

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:  https://www.youtube.com/watch?v=ILkT_HV9DVU

 

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



#5 warnexus   Prime Members   -  Reputation: 1384

Like
3Likes
Like

Posted 27 December 2013 - 11:22 AM

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, 27 December 2013 - 11:48 AM.


#6 superman3275   Crossbones+   -  Reputation: 1989

Like
0Likes
Like

Posted 27 December 2013 - 11:37 AM

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

 

Cheers :)!


I'm a game programmer and computer science ninja ph34r.png!

Here's my 2D RPG-Ish Platformer Programmed in Python + Pygame, with a Custom Level Editor and Rendering System!

 

Here's my Custom IDE / Debugger Programmed in Pure Python and Designed from the Ground Up for Programming Education!

Want to ask about Python, Flask, wxPython, Pygame, C++, HTML5, CSS3, Javascript, jQuery, C++, Vimscript, SFML 1.6 / 2.0, or anything else? Recruiting for a game development team and need a passionate programmer? Just want to talk about programming? Email me here:

hobohm.business@gmail.com

or Personal-Message me on here smile.png!


#7 warnexus   Prime Members   -  Reputation: 1384

Like
0Likes
Like

Posted 27 December 2013 - 11:53 AM


put the console in a microwave, play the game underwater

 

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



#8 Tutorial Doctor   Members   -  Reputation: 1435

Like
0Likes
Like

Posted 27 December 2013 - 12:05 PM


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


They call me the Tutorial Doctor.


#9 Tutorial Doctor   Members   -  Reputation: 1435

Like
1Likes
Like

Posted 27 December 2013 - 12:10 PM


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, 27 December 2013 - 12:11 PM.

They call me the Tutorial Doctor.


#10 Tutorial Doctor   Members   -  Reputation: 1435

Like
1Likes
Like

Posted 27 December 2013 - 12:16 PM


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
sad = false
neutral = true

if happy then
...
end

if sad then
...
end


etc.


They call me the Tutorial Doctor.


#11 Tutorial Doctor   Members   -  Reputation: 1435

Like
0Likes
Like

Posted 27 December 2013 - 12:23 PM

 

 

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:  https://www.youtube.com/watch?v=ILkT_HV9DVU

 

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, 27 December 2013 - 02:17 PM.

They call me the Tutorial Doctor.


#12 Rorakin   Members   -  Reputation: 618

Like
0Likes
Like

Posted 27 December 2013 - 02:26 PM

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:  https://www.youtube.com/watch?v=ILkT_HV9DVU

 

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



#13 Tutorial Doctor   Members   -  Reputation: 1435

Like
0Likes
Like

Posted 27 December 2013 - 04:23 PM


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


They call me the Tutorial Doctor.


#14 warnexus   Prime Members   -  Reputation: 1384

Like
0Likes
Like

Posted 27 December 2013 - 09:13 PM

 


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
sad = false
neutral = true

if happy then
...
end

if sad then
...
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, 27 December 2013 - 09:17 PM.


#15 Ravyne   Crossbones+   -  Reputation: 6778

Like
2Likes
Like

Posted 27 December 2013 - 11:10 PM

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, 27 December 2013 - 11:12 PM.


#16 lask1   Members   -  Reputation: 630

Like
0Likes
Like

Posted 28 December 2013 - 03:04 AM

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!



#17 Tutorial Doctor   Members   -  Reputation: 1435

Like
1Likes
Like

Posted 28 December 2013 - 04:22 PM


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, 28 December 2013 - 04:22 PM.

They call me the Tutorial Doctor.


#18 warnexus   Prime Members   -  Reputation: 1384

Like
0Likes
Like

Posted 28 December 2013 - 09:08 PM

 


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



#19 Subtle_Wonders   Members   -  Reputation: 225

Like
0Likes
Like

Posted 31 December 2013 - 08:20 PM

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 developer, you need to give yourself one task at a time as if you were taking the tasks from a basket offered to you. When you work on your task, you must pre-test your results. You should not work on another task until you are confident that the task you took responsibility for, works. You continue doing this until you have no more tasks left. If you find a problem that prevents you from finishing that task, you document and move on to the next task. If you have any incomplete tasks due to problems, you then revert back to a designer to amend then return back as a developer to apply the change. Assuming you have no further tasks and no problems, you switch to QA..

 

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, 31 December 2013 - 08:21 PM.


#20 Tutorial Doctor   Members   -  Reputation: 1435

Like
1Likes
Like

Posted 31 December 2013 - 11:58 PM

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, 01 January 2014 - 12:33 AM.

They call me the Tutorial Doctor.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS