If it's a network game, keep the stats on a server where they can't mess with them. If it's not a network game (single player) what's the problem with them messing with them? They're only cheating themselves at worst, modifying the game to make it more fun for themselves at best.

There is some decent art on http://opengameart.org... but you're unlikely to find EVERYTHING you need for a complete game.

Machine code isn't "encrypted" except in the sense it's readable by the CPU rather than humans. If you put human-readable stuff into a DLL you could read it with any hex editor/viewer. There will probably be a few function names you can read even in a code DLL.

What you suggest I do? if I want to use the .dll for new levels but I don't want people opening it up and messing with it?

I could create the .dll first then have a program that encrypts it.
Ofcourse only I will do these two steps.

The end-user will receive the game. Before the game runs it'll look for the .dll decrypt it and then run normally.

I wonder.. If I am willing to go through this much trouble, might as well just make my own file type...

First you have to understand what a DLL is. You don't put levels into a DLL.

So how does C++ building work? C and C++ files are compiled into object files, which contain relocatable machine code. Typically these files are *.obj (or *.o on linux). Next step is linking into an executable file, which means to throw all the object files together and resolve all open symbols (like function calls and global variables). Result is an executable. Collections of object files can be put into a library, typically *.lib (or *.a on linux). Such a static library is exactly that, a collection of object files to link with. Primary purpose is to keep linker statements shorter, and have libraries which are good for reuse in more than one project.

Shared libraries are working quite differently on Windows and on linux. On Windows they are DLLs, on linux *.so files. A special thing on Windows is the fact that a DLL looks very much like an executable files, but in the end, it's just a shared library, which is only loaded when the starting program (which is a *.exe) loads the DLL. This can be during startup or by dynamically loading the DLL as needed. Either way, loading the DLL involves a link step, and after that, the executable in memory is completely linked, all symbols resolved and relocated, so it can execute.

To answer your question, it's mostly a matter of taste, if you prefer static or dynamic libraries. Linking large programs can become really slow, using DLLs can help a bit here. On the other hand, the programs that you typically write, compile and link within seconds or a few minutes, so there's no problem. Using static libraries makes the executable look bigger, but it's self contained (doesn't need to resolve symbols during runtime). Using dynamic libraries means you have to distribute them, and their summed sizes are bigger than the executable alone. None of this is an issue these days.

I'm going towards static libraries for my own projects, especially when I try to go for Allegro 5, makes things a bit easier for me.

Put your game content into directories and files that you can easily read, like using load_bitmap. You will have your original data somewhere, and at least during development it will be so much easier to read those files directly, in comparison to introduce another build step that packs your original data into any sort of pack, zip or whatever file to read in in your game.

Regarding something mentioned earlier, about only definitions/declerations being in header files:

I put all of my class definitions in header files, and all the class functions go into a .cpp file; however, sometimes if there is an extremely basic function in a class that simply returns a class member, I put that into the class definition in the header file:

class clsMyClass{
  protected:
    int mi_XPos, mi_iYPos;
    BITMAP *mbmp_Image;

  public:
    clsMyClass(int ai_XPos, int ai_YPos);
   ~clsMyClass();

    void moveLeft(int ai_Amount);  //Code for this goes into .cpp file
    BITMAP *getImage(void) const {return(mbmp_Image);} //Simple so gets put here 
};

Would this be frowned upon? Should ALL functions go into the .cpp file, regardless of complexity/number of lines?