Jump to content
  • Advertisement
Sign in to follow this  
Tutorial Doctor

Does anyone try to Break their Game?

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement

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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


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

if happy then
...
end

if sad then
...
end


etc.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!