Note: This does not answers the question using x32dbg/ollydbg, but another tool. (I can't seem to be able to post a comment). My apologies if it is off topic.
You can try with Cheat engine (CE).
If yes, download the installer-less release, because the installer includes crap:
I assume you downloaded it and extracted it at this point.
This software has a really nice integrated tutorial which is another .exe shipped in the folder. Read more about it HERE (it is for 64 bits, but it should give you an idea on how to run the 32 bit tutorial). Try to go through it (or skip the steps - bottom right corner), and at some point (step 6 and 8) your problem will be addressed (no pun intended).
Good luck :)
Reading from the comments you posted below
- I'm usually not lucky enough to pick the right one straight away [...]
Although it is not perfect, CE has this tool called the "pointer scan" (you might already know this tool, I'm thinking about new CE users) where it kind of brute forces the offsets and goes down more than one level of depth. It might work after lots of effort.
- So I thought learning how to use them with small self-written programs would be the smartest way of getting into it. But as @mrexodia pointed out already, player objects are usually not allocated on the stack.
Speaking more generally (I deviate from your pointer question), I think that this is a very good approach. Example : with this approach I once discovered an opcode I didn't know about /
cmovcc in manuals) while dissassembling a game of mine and therefore I knew exactly how things were laid down in the memory and in the code. Very instructive for me, definitely a +1. You could also learn about compiler optimizations by comparing the code and the generated assembly.
When it comes to more complex games, try to practise on indie games (singleplayer of course) or open source (because they are accessible). Try Assault cube (or Assault cube reloaded). This game is quite enjoyable to practise on because there are no debugging protections nor anti-cheat system, ... You can for example find pointers to the local player, or modify the game code / making your team invincible, infinite ammo and so on...
A workaround to your problem
This is an intuition and not based on facts, but I beleive that games made in virtual machines such as Java, C#, or OS features such as address randomization ... are harder to debug in assembly and could be unpredictable in terms of pointer finding, ... .
A method I like to use (to find the local player, most of the time) is using "code hooking".
For example, if you want to find the address to the local player in AssaultCube (or an other game) you could find the GUI code that draws the player ammo/health on screen, because if your game displays to you that you have 100Hp, well it got to extract the value somewhere. What you could do in this case is using CE and find the Hp, finding what code accesses this address and hopefully there will be along the lines, the GUI code that intercepts this value. From there you can retreive the player base address. What is really good about this technique is that you don't have to mess around with pointers, it's a pretty straight forward way to get your player address.
The downside is that you have to inject some code to reteive it. You could inject a hand crafted program (C, C++, ...) or use a CE trainer to acheive this effect. Using a debugger at this point may help you to understand where the data comes from and hopefully find a way to get the pointer.
- so my whole idea seems to be stupid / My biggest problem is that I'm not really a smart kind of a person / or would you say that it's a waste of time for a person like me
No it is not stupid, you can totally get it to there, to me you are definitely not "not really a smart kind of a person" because you're trying to understand low level concepts such as pointers.
I am not experienced in the reverse engineering field, I do not pretend that I know much things, but I have some "bad" questions on stackoverflow / gamedev, I clearly didn't know what I was doing but hey, I was younger and that is okay, it's part of the learning curve. At first I didn't even understand these concepts and quite a time ago, I made a "simple" mod for a game that involved assembly patching to improve the fun. There were two simple patches to make, but it took me some hours to figure out. The point I want to make is that you have to start somewhere. Kudos to you for trying !
You WILL spend or even waste, to some extent, time figuring things out, learning techniques, debugging, ... It does not come alone you know. It's like drawing, I don't think Picasso woke up one day and knew how to paint, it eventually came with practice, failures, study and frustration.
Now I realize that this does not really answers your question and my apologies, basically try the pointer scan / code hooking. I'm sure that there are more solutions to this problem, that I am not aware of.