• 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.
Sign in to follow this  
Followers 0
Felipe M

Some programming questions I have.

9 posts in this topic

Some thoughts that I had. Not specific to any language. But if the answers depends on the language, I know c++, java and actionscript.

 

1- When you declare an integer: "int i = 0", what is int? Is it a class? How does it work inside? Is there a source code for how the int works?

2- The same doubt about structures: if, else, for, etc (I think we call them structures). What are they? How do they work? Is there a source code?

3- Is it possible to make a pointer point to a specific memory address?

int * p;

p = 0x00FF32

 

Is it possible somehow?

4- Is it possible to know what type of variable the memory address 0x00FF32 is containing? What other info I can get about this address?

0

Share this post


Link to post
Share on other sites

Thank you. So these primitive types are also made with assembly right? The assembly code for them just allocate some memory for them and tells how the high-level language should interpret the 0s and 1s that are allocated.

 

About the other questions about memory addresses, I was thinking like this: If you could scan all the memory adresses and see what type of variables they were, you could do something with them. Like I have a game where there is a tutorial where there is a text that says "Jump over the spikes".

 

I would make something like this:
 

for(>>from 0x000000 to the last adress<<){
	if(>>current adress is a String<<){
		if(>>current adress is equal to "Jump over the spikes"<<){
			String myString = "ahah I changed something in the game";
			>>make the current adress equal to myString<<
		}
	}
}
0

Share this post


Link to post
Share on other sites

Nothing is "made from assembly", assembly is just a way for humans to name the instructions the CPU understands.

 

Assembly language doesn't know anything about "types" either, it just has instructions which operate on data of various sizes (typically 8, 16, 32 bits but also vector types as well) and it is up to the assembly programmer to use the correct instructions for the correct data (in the case of high level languages, the compiler is the assembly programmer, and it knows which types of data reside at specific addresses, so it makes sure the correct types of instructions are used).

 

You can easily scan for strings in code by dumping the executable into a hex viewer (Visual Studio will display a hex dump if you rename the file .bin instead of .exe), assuming the strings aren't encrypted in some way.

 

Looking for other types is more difficult since you need to know the type of the variable that occupies the address.

 

To read memory from a running process have a look at http://msdn.microsoft.com/en-gb/library/windows/desktop/ms680553%28v=vs.85%29.aspx (assuming Windows).

Edited by Paradigm Shifter
0

Share this post


Link to post
Share on other sites

So these primitive types are also made with assembly right? The assembly code for them just allocate some memory for them and tells how the high-level language should interpret the 0s and 1s that are allocated.

Sortof. 'primitive types' vary from language to language, but basically in the hardware you have two types: integers, and floats. 32 bit integers, 64 bit integers, 32 bit floats, 64 bit floats, possibly other sizes as well like 16 bit floats or 128 bit floats or integers. This depends on the hardware. They aren't 'made with' anything, except binary in memory. Assembly modifies them, telling the OS to do some operation implemented in the actual hardware of the CPU.

bool's in C++ are just integers. 0 = false, anything else is true.
char's are just integers. We just assigned permanent numbers to specific letters and symbols. See ASCII chart. The number 65 is 'A', 66 is 'B', 97 is 'a', 98 is 'b'. 37 is '%'.
 
Strings are just multiple chars in a row. C and C++ don't have a native 'string' type, but they have arrays of chars, and C++ has std::string which is a class that wraps an array of chars for convenience and safety.

About the other questions about memory addresses, I was thinking like this: If you could scan all the memory adresses and see what type of variables they were, you could do something with them. Like I have a game where there is a tutorial where there is a text that says "Jump over the spikes".
 
I would make something like this:

for(>>from 0x000000 to the last adress<<){
	if(>>current adress is a String<<){
		if(>>current adress is equal to "Jump over the spikes"<<){
			String myString = "ahah I changed something in the game";
			>>make the current adress equal to myString<<
		}
	}
}


Well, many games load their data from files, so you can use a program to edit the data of the files.
The executable itself (.exe, .dmg, etc...) is just a file with data as well. Data is just binary, and it only depends on how you treat the binary. I can pretend a string is a float, or a float is a string. Doing so will give me jibberish, but it'll work.
The computer doesn't store what *type* of variable is at a certain location, it just stores binary. The program decides how to use that binary. This is important because A) it saves memory (don't store what you don't need), and B) you occasionally want to treat the same chunk of memory as different types.

So, if you open an executable in something like an hex editor (such as HxD), you can directly edit the binary. Doing so can obviously break the game if you accidentally edited the wrong value, so create a backup copy before editing it. Looking through the binary, you might notice patterns. HxD shows the binary as hexadecimal value (hence the term 'hex editor') and as chars, so if you're looking for a string, you might be able to spot it, or maybe do a Ctrl+F for it. Then you can modify it, save it, then run the executable. Note: Because assembly is referring to certain memory addresses (jump to 0x0FA3B4 and etc...), you can't remove any bytes or it'll throw off the memory jumps, so make sure anything you replace is the same size of bytes as previously. (Any strings you are modifying can't be larger than what you are replacing, and if it's smaller, pad it out with spaces or something so it's the same length). Edited by Servant of the Lord
0

Share this post


Link to post
Share on other sites

Hmm, that made things more clear to me. Thank you all. I have tested HxD, but couldn't do much. I could change a string of my own test program that I made. In other programs I just couldn't find the strings that I saw on them in the hex editor. Actually I don't have many programs to test here in this PC. Also, paradigm shifter, I couldn't implement that function in the link you've passed. I've included the windows.h library and all but the code didn't compile. Guess I'll take a better look at it some time.

Anyway, three more questions that came to my mind:

1- The memory address allocated to things don't always change every time you run your programs? How text editors change memory values and when you execute the program these values are the right ones?

2- Isn't it possible to change memory and get the desired effects at run-time? Hex editors don't do that.

3- Isn't it possible to do the things you do on hex editor on your code? so you can automate stuff?

0

Share this post


Link to post
Share on other sites

In other programs I just couldn't find the strings that I saw on them in the hex editor.

Then that's probably because the other programs don't have the strings within the executable as string literals, and instead load the strings from files. This is very common, so you can flexibly change text during development, so it's easier to patch, and so localization is just a matter of pointing at a new language file instead of recompiling the executable for every language.

1- The memory address allocated to things don't always change every time you run your programs?

The memory of the executable stays the same, relative to the executable. The executable is a file. The data at the location 50 bytes into the file is always 50 bytes into the file.
When the program is running, first it is loaded into RAM, and then it can (and does) allocate new memory in RAM do work on. The hex editor can't edit that memory while it's running, though it can edit the assembly instructions to change what it does with that memory or where it looks for the data. That's a bit beyond my knowledge though.

2- Isn't it possible to change memory and get the desired effects at run-time? Hex editors don't do that.
3- Isn't it possible to do the things you do on hex editor on your code? so you can automate stuff?

I'm not sure what you mean by 'automating' it, but yes, you can interpret and edit any chunk of RAM that your program controls however you want, within your program.

The example I posted above:

int main()
{
    int myInt = 357; //The program makes an int.
    std::cout << myInt << std::endl;
    
    float *myFloat = (float*)(&myInt); //The program pretends it's a float.
    std::cout << *myFloat << std::endl;

    *myFloat = 2000.0f; //The program edits the memory while pretending it's a float.
    myInt = 800; //The program edits the memory while pretending it's an int.
    
    return 0;
}

But hey, if you want an external program that can edit RAM while another program is running, I'm sure you can do that too.

See this website (from a different GameDev.net member), which focuses on some memory modification software she developed.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0