For this project I plan on making an interactive reader that will allow the user to adjust “values” in a text and have those values change the information on the screen… but do that on a physical piece of paper.

This idea is an extension of Bret Victor’s Explorable Explorations project (found here: http://worrydream.com/#!/ExplorableExplanations). Using Victor’s API we can potentially read a piece of paper using a phone camera and apply the logic in AR.

Potholes

There are two key parts of this that I’ll need to dive into, firstly Explorable Explorations is written in HTML and JavaScript… of witch I know neither. So I’ll need to find a way to convert their project into something more comfortable for my skills as a programmer. For this, I plan on making a Unity Android app that will interface with Victor’s project and do the necessary functions.

Secondly, I need to get an AR setup in unity to be able to read the paper. I’ll have to look into API’s and methods of reading text from a camera, then positioning them in the game world based on the text’s location. Which is a huge task on it’s own.

For this project, I have about 12 weeks to work on this, so I’ll need to budget my time carefully. I’d like to have Explorable Explorations working with Unity by week 4, this will leave me 8 weeks to get the AR portion of the project done.

Ideas on how to overcome these issues

So I have a few ideas on how to deal with the issues noted above. For the HTML & JavaScript part, I’m hoping that once I do a deep dive into Victor’s code I’ll find a way to re-rout the JavaScript functionality into C# so I can function with Unity. Using WebGL is another option as it already functions in the web. The third option is to write a plugin that’ll display an HTML text file into Unity, then using that to function.

For AR it’ll be a bit trickier. Since I don’t have the resources to write a text reader on my own (and doing so would be overkill for this project anyways) I’ll have to create a cheat for our purposes. However, if I simply create a syntax that’ll tell the program where what words are, and that they have a variable attached to them, then we can overlay the unity text over them. The issue with this is that we’ll have to create a way to easily import and export these variables to make this application usable to a wide market, as well as making a syntax that’s dynamic enough to be used in multiple situations but not distracting to the user.

For a first draft I’m thinking something like this [ Variable ][#]. Unity will look for the square brackets, then grab the # after it to tell the code what variable it is. This is something that I’ll have to tackle more in the future and is likely to change.

Another option for this is to have a barcode over every variable, however this will defeat the purpose as it’ll make the text unreadable without a camera. We could potentially put a small QR code after the variables that the program looks for, but that’s another can of worms.

The third is that I could use a image to text API (Such as OCR https://ironsoftware.com/csharp/ocr/), however that would be taking some of the work away from my hands but could be useful if crunched for time.

Quick Notes

Points of exploration: Making a plugin to get HTML & JavaScript code to work with Unity | Augmented Reality

Unknowns: Augmented Reality theory | JavaScript | HTML

External factors: Explorable Explorations| OCR (potentially)

Hello! For this project me and three of my peers did a deep dive into the GoDot game engine, with each of us focusing on a different aspect of the project. Below are the links to the blogs of my peers, read them to do a dive into the other aspects of the GoDot engine!

Bootstrapping: https://www.niklausbair.com/blog/developing-a-game-engine-looking-at-godot
Input and Server Architecture: https://jacobb.me/blog/2019/10/12/godot/

Scene structure: https://www.austinlaimos.com/post/game-engine-development-godot

So for this I decided to focus on how GoDot handles memory management. To start I’d like to go over the princaples that they listed in their documentation here: https://docs.godotengine.org/en/3.1/development/cpp/core_types.html#memory-model. Here they talk about the issues with using heap and paged memory build into the language, with heap it talks about how memory can lead to being segmented memory. With paged memory it’s good for temporary memory but falls flat when working with permanent memory. So their solution to this is to use a memory pool model for managing their memory. This allows the programmer to allocate memory as without wasting space. However the issue with this is that you have to do a get function every time you want to access that memory, making it slower than using the heap. So the solution is to use a mix of the three, for small / temporary management they use paged memory, for memory that needs to be accessed quickly they use the heap, and for the rest they use the memory pool!

With that established, lets talk about how they use and implement the memory pool. For this they have three classes that work together. Memory, PoolAllocator, and VectorPool. Lets start with Memory, here is where the engine actually allocates it’s memory. Located in this class is the memNew and memDelete functions, these are used as the main ways to allocate and delete memory within the engine. It is also important to note that they use primarily static memory in this function.

The next part of this equation is the PoolAllocator class, this is exactly what it sounds like it’s the memory pool. This is the slower part of the memory management, however it’s much more space efficient due to it’s ability to defrag itself when allocating memory. This works by allocating a set amount of memory (from the Memory class) on initialization, then it is free to ma mange that memory as it sees fit.

Here we can see the memory pointer tr being given it’s static memory, as well as some other pieces being put together. Next up is how they actually allocate memory, this is done in a few steps. Firstly it checks to see if there is any entries available. By checking this will allow the pool to exit early if needed, saving on time. The next check is done by seeing if there is appropriate sized memory space in the pool, if this fails the first time it’ll run a defrag on the memory chunk then check again. This helps a lot with the best case scenario of this check by doing a quick check, however extends the worst case scenario by checking the pool twice.

Finally if both of these succeed, the pool will place the memory into one of the entries pre defined by the pool. The rest of this class is general memory pool stuff, there’s a resize function, a getter for entries, and the normal deconstructions.

Next is the VectorPool, I’m a bit torn about the exact function of this. It appears to be an abstraction of the memory pool, being where the user actually calls the memory pool. However why the memory pool is abstracted is beyond me as it all seems straight forward.

In conclusion, the memory management in GoDot is extremely streamlined, giving the user a lot of control but abstracts it enough to maintain itself.

Hello and welcome to my newest blog! With this series I will be documenting my journey on creating my own game engine. So with this being said there are a few fundamental questions I’ll be asking and answering in this blog post. Firstly, what is the purpose of the engine? I plan to create a game engine that specifically focuses on turn based strategy games. I’m aiming at being focused enough that people using the engine will have a streamlined experience making what they need, but be flexible enough to cover various types of strategy games. So if someone just wanted to make checkers they could, or make a jrpg they could as well.

There are a few features that I would like to be a part of this engine. Firstly a unit creator / manager would be key. Allowing users to make a unit quickly is vital for any strategy game engine to work. Secondly is a build in turn system, being able to decide when turns happen, when they swap, and what turn order is made will be vital for any turn based strategy game. Thirdly is an instancing system for scenes, many strategy games (particularly rpg and adventure games) will have an instance for combat, dialog, and just exploring the world, and having an easy way to support this will help greatly. There are other features that come to mind that will help such as AI tools, scene management, ect, however these are all questions that I’ll ask down the road once I have more of an idea of the footing I’ll have.

The next question is, what IDE and language will I be using to make this engine? For this I plan on using C++ in the eclipse IDE. There are several reasons for this, firstly I’d like this engine to be cross platform between windows, mac, and linux. To do this I need to pick an IDE that can compile

C++ in these platforms, witch eclipse fits the bill. Secondly, eclipse is very well documented and well used so finding help on any questions I may have down the line will be simplified. Thirdly, I have some experience in using eclipse so, not as much as with Visual Studio but it still helps. Put simply, I’m using eclipse due to the well documentation, cross platform capabilities, and my familiarity with the platform.

With all of that, I’m wrapping this blog post to a close. I’ll be posting updates on my journey into creating an engine so stay tuned!

So we are just about finished with this project, and while I’m very proud of the final result there were definitely some major hiccups along the way. The first major one I want to talk about was the scope of the project itself, said simply it was way to high. We decided that in 3 months we were going to have 5 levels in a seamless level, leading out design team to be spread super thinly. But not being in design this didn’t affect me as directly as it did them, what did however was the fact that we were unprepared for the pipeline issues that would inevitably come with this decision. What we finalized on was having different “work in progress” scenes for each level, then when things were ready or needed to be tested we would shove them all into the master level scene. This caused generally more issues than it was worth, with this we needed to have one programmer focusing on making sure the build wouldn’t collapse after the merge.

The second difficulty we ran into was with the art pipeline, none of us on the team had any experience with how Unity handled it’s 3D art pipeline which made learning it a task upon itself. The problem was, we didn’t fully understand what we were doing until after the project was nearly done, so the issues that were started near the beginning of the project were affecting us later into it as well.

All that being said, I feel like I’ve learned alot about how to set up pipelines and about developing in unity generally. There’s a lot that went bad, in the experience of it going bad I learned about the limitations of the engine, how to work around said limitations, as well as the strengths. This project being completed I feel like I have a new understanding of how Unity runs and how to properly develop for it.