I'm playing with pygame now for the exact same reasons you should be. I picked something and if it doesn't work I can always try something else but for now I'm at least coding something like what I want to be coding in the end.

Spend a little time with the most obvious options (you mention WPF and Unity) and "test the water". Force yourself to learn them enough to know how to do one of your specific goals, as kind of a "technical feasibility challenge" to yourself. You will not be able to properly judge their fitness for your goal without trying them out and learning what lurks below the surface.

Start with tutorials. WPF and Unity both have an immense amount of free tutorials all over the web. You will probably not find tutorials that tell you exactly what you need to know, but you will find some that are close, and those will get you familiar enough that you can figure out what to change in order to get what you actually want.

Search for examples of what other people have done with WPF and Unity - see if they are similar to what you want to do. Analyze their approaches. Try their code (if applicable). Learn their ideas. You can find a LOT of cool ideas and source code just by searching the internet for free examples.

Most importantly: Never worry about "wasting" time during the exploratory phase! Even if you use WPF for a month and never use it again, your experience is permanent knowledge you've gained which will help you elsewhere.

At this point you will have gained some experience, decided whether you like the approach, and more importantly figured out in more detail what you don't like and what you need. You will know which questions to ask when deciding whether to use alternative systems, and you may even decide that the first approach you take is actually good enough to keep going.

Don't try to do things perfectly the first time - it's impossible. Jump right in. Don't worry about making your game perfect. You can always change things. Make it fulfill your functional goals first, and then make it look good afterwards.

I would say try XNA. It uses C#, have tons of tutorials, and really just works. Some people say that it's dead because MS no longer develops it, i would argue that it's not dead, it's just complete :). When your game is finished (which i would'nt worry about at all when starting out for the first time) it's really no trouble to port it to MonoGame (i've done this once, took about 1 hour) or probably even better FNA.

In my opinion XNA works better than monogame while developing, no bugs, faster compiling.

You probably also should try out Unity. Personally i really dislike doing things using the mouse, and i get really annoyed when the editor crashes now and then. My experience with unity is that it's really great att getting some core features into place, and then ju want to change something from the default behaviour and ju get stuck watching videotutorials for some hours trying to understand whats happening :) But there's no denying that unity is popular and powerful.

Really thanks to all i will probably give a try to Unity and read books and see video tutorials that can help me

And for curiosity, SDL is it good for C# or better to stick with Unity?

Since you have C# experience I would strongly suggest Monogame. Unity is a bit clunky with 2d. It works but there is alot of unnecessary steps that you have to take because its a 3d engine. I've tried both and have chosen Monogame. Its easy to learn, updated frequently and has a very active community around it. Just my opinion. Hope it helps

I agree with Spool. Unless Unity has changed a great deal since I used it back in 2008-2010, it's not really great at 2D games, while monogame is a re-implementation of XNA, and XNA made making 2D games pretty simple.
I wouldn't use SDL with C#, and I'm a huge fan of SDL in C and C++. Use a library made for your language and runtime.