Week of 9/11 - 9/18

A little late this week due to tests, but:

SUCCESS!!! I refocused by drawing a visual logic diagram for what the embedding is supposed to do. This helped me figure out what to not look at when reading the Python C API documentation.

After three weeks, speaking through the API documentation with Mark, Adam, and posting a question on stack overflow, I have finally figured out embedded Python! The C Python API call PyRun_InteractiveLoop function. This creates a Python Console line, which I can now work with and embed into my API.

As it is currently listed, it takes console command arguments with stdin and "<stdin>" for the embedding. I theorize, but am uncertain, whether changing the variable names will allow me to pass the data from the game portion to the Python interpreter and back.

The next step on the back end now that the embedding portion is done, figure out how to transfer the data from Python Interactive back into C/C++.

Front End:

Not a whole lot of progress since initial proof of concept. I am still leaning heavily towards SFML as my API, but I might switch to Vulkan or OpenGL to learn a new one and challenge myself. Vulkan and OpenGL are more robust API libraries with a lower level connection to the hardware. I think it's unnecessary for my needs, but never a bad thing to pick up. Vulkan and OpenGL being in C over C++ means the entire program could be in C if I went that route, not that C and C++ are incompatible as it is.

Puzzles:

With the embedded console, now comes Puzzle Design. The three big types:

Basic Input/Output. This is the early stuff. "Hello world" and Mad Libs. I am wondering whether the "helper tutorial" character could have a sibling that would "say" whatever the user puts in through a speech bubble.

Interacting with variables. Things like making a calculator for the circumference and area of a circle. Python with OpenGL or Vulkan underneath should be able to draw circles with those areas, assuming they're also in the screen size.

Basic conditional statements. Things like "if" "else (if)" "while" "do while": I am thinking of using basic movement for the "helper character's sibling" as a way to teach this; especially for the youngest audience target.

To learn:

SAVE STATES! Being forced to redo the puzzles every time a user starts up a game will get cumbersome.

Week of 9/3 - 9/10

Week of 9/2/19


Boost:
I debate going back and forth with Python C header file and the Boost.Python library. I spend time setting up a Virtual Machine in Mint to test Boost libraries without messing up my main project dependencies. These dependency issues arose when I tested boost on my main working system on Labor Day, and I was forced to revert to a previous back up state for my whole system.

Boost proves to be a fickle animal. After building with their proprietary build shell script, it doesn't call in the Virtual Machine properly, though I can get SFML and other open source additional libraries working fine.

Python.h header file:
Setting up:
Setting up Python.h proves to be similar in Visual Studio to setting up SFML, OpenGL, SDL, or Vulkan. Preferably, the libaries are included in the solution file directory, and then they're called in the properties window.

For more information on that, this Stack Overflow link describes it better than I can without snapshots of internal file systems.

Thursday 9/5:

Major progress! After much trial and error, I manage to create a simple C++ program with Python.h C library embedded that takes a simple Python string argument and prints the result. The program does not allow for white space, or multiple arguments or functions, but the proof of a Python interpreter is coming together.

The above code is the example of the working Python Simple String interpreter. It takes the user's input as a Python string and reads it. I also learned the difference between 'const char*' and 'char const*', which helped the compiler not run into the error message: "no suitable conversion std::string to const char." The difference is what is constant. In this statement, the constant is the pointer, and the character changes.


Monday 9/9:

I have decided to use the Python.h C header file, though this involves learning C to read the documentation. It is more recently supported as of Python 3.7, with dev for 3.8 and 3.9 in the works. The Python.h C header file is created by the Python development team directly, and has compatibility for C to Python and Python to C, and embedding. Using Boost proved to have more challenges on the back end set up than Python.h, but the coding seemed to be easier.

After spending time at the CCLA and talking out my needs and interpreter with Adam, I have elected to use Python.h over Boost or other third party Python libraries. While I appreciate the efforts of the open source community to make this sort of implementation easier on the coding end, for my needs:

1. It is directly supported by the Python team. This is huge as documentation is more up to date, and it is much easier to move and copy Python from existing programs on my computer than a third party source.

2. I don't need to create a scripting system that changes back-end or on run-time events, things you might see in a Game Engine for mods, or reducing compile times, or business applications that use C or C++ for heavy lifting but Python for end user data manipulation. The whole goal is to interpret user code in, and check it against expected output. I would rather spend my time learning C and the Python.h implementation documentation than work out a third party, open source library with a proprietary implementation and set up methodology.

3. Learning and picking up C is never a bad thing. An additional programming language under my belt won't hurt. C in C++, C#, and Java based jobs tends to be a useful skill to have anyway.

Next major goals:

Python Interpreter:

1. Learn C well enough to read the Python C API documentation listed here.
2. Get the interpreter able to read open spaces in arguments, and simple functions or statements (if, for, while, etc.)

User Interface:
1. Work on different screen states to transition between a main menu and the "puzzle" screen. This involves going through SFML books and documentation to build that kind of engine state machine.

2. Make a "prototype" Main Menu/Start Up Screen. Design in GIMP, the buttons and interface. I don't expect the early implementation to be pretty by any means, but I want to figure out how the menu will look.

Documentation Notes, Week of 8/27 - 9/3

8/27 - Senior Seminar meeting

Dr. Engebretson recommends scrapping the more difficult languages: C#/Java, and C++, as the most efficient way to check player's answers against expected answers is to parse or compile code to produce the desired result. Doing so in C#, Java, and C++ would require creating a compiler within the larger program.

I then look into Python scripting functionality embedded in C++. This is a possible feature, but it requires utilizing a third party library support. The two options that I found are Cpython, which is built in the C language, and Boost.Python, which is an open source project built on the Cpython framework but implemented in C++.

Sunday, 9/1

I spend four hours attempting to get Boost.Python working within Visual Studio, the IDE I am most familiar with. Visual Studio and third party library support is not the most user friendly experience. I look into IDEs available on Windows that work more seamlessly with third party and open source libraries. I discover that Code Blocks using a MINGW compiler works quite well at compiling Boost libraries, Python and otherwise. Code Blocks also has a template for SFML, Simple and Fast Multimedia Library, the API I am using to create the graphics and sound portion of the project. Learning a new IDE will take a bit of time, but it also appears that the IDE will make moving the project between my desktop and laptop a lot more seamless too.

Monday 9/2

Big code day. The main goal for 9/2 is learning Code Blocks and working on implementation for Boost.Python, it might not be completely ready by Tuesday's class time, but the goal is to figure out the library calls, and if possible work on learning how to write and parse script in Boost.

Boost then messed up all other additional library dependencies, had to return to a previous back up state, and call my functions again.