Work Log

Making a sphere     Possibly my greatest programming achievement so far; I have made a sphere. It sounds very simple (and with hindsight it was) but after a few days of work I have managed to render a procedural sphere in unreal.      From my last post, I said that the last thing that needed to be fixed was the nullptr issue a variable that was passed to the GeneratedPlanet() function. This ended up just fixing itself I guess. Like I just came back the next day and it didn't happen anymore, so that's cool.     Although, as I correctly predicted last time, this was not in fact the final issue. There were actually two final issues. I recognised the issues because on the first test that didn't crash the editor there was only one section of the sphere rendered, and on top of that it was rendering inside out.      My instinct was that either it was a problem with the math of finding triangles and vertices, or it was a problem with the array of procedural mesh components. I decid

Messing with procedural meshes     Over the past 3 days I have put work into getting generated planet shapes. I have decided that this is currently more important than the orbit debug because the debug wouldn't show up in an actual game, the orbits work without it, and having custom planets would be way cooler.     Again I am using  Sebastian Lague as my backbone because he has already done a series on procedural planet generation in Unity. Just as the other video I followed by him, I understand C# so I can follow along with what he's doing while trying to translate it to C++ in Unreal. As of today I am still on the first episode dealing with rendering a sphere. I am so close, with only one compile error (as far as I'm aware), to having this work.      This process has been mainly involved with Unreal's "Procedural Mesh Component" which is super cool. Basically you can specify vertices, triangles, and even UV's and more to create a custom mesh at or befor

Big success     Over a week since I started this project I have finally achieved orbiting planets! All scripts compile without warnings or errors and the simulation works as intended.      The major problem I was dealing with yesterday was with UObjectIterator. It ended up, not surprisingly, being user error rather than the engine being broken. The just of the problem was that I was trying to get pointers to actors in the world, which is not possible with this iterator and as I later found out, not necessary. I found that there was also TActorIterator which has some differences that I don't understand but which are better for my use. Basically, the code had to go from this: for (TActorIterator<ACelestialBody*> Itr(GetWorld()); Itr; ++Itr) { bodies.Add(Itr); } To this: for (TActorIterator<ACelestialBody> Itr(GetWorld()); Itr; ++Itr) { bodies.Add(*Itr); }     Moving a single * solved the problem. So as I understand it, instead of trying to get p

Unreal Hangups     As seems to be tradition now, one thing has been fixed but another has broken. I managed to fix what I thought was everything, but regardless it would not compile. Turns out the problem with the loop for the functions was that I didn't #include "CelestialBody.h" and so the declaration of that private variable was not recognised. Additionally, I had the correct logic for the getting all actors with a TObjectIterator instead of TActorIterator as I had yesterday. There were no red squiglys so I thought I was all good, but unreal had different plans.      When I compiled, it threw errors with it's own source code. It kept saying something was wrong with UObjectIterator which I hadn't touched. This led me on a wild goose chase looking up error codes, error messages, and anything else I thought was important. I also looked into the source code to see if I was able to fix it myself but everything seemed ok to me. I then looked into the history o

More Slow Progress     Today I was able to fix one thing and break another. I got the array of my custom class working, but I couldn't populate it. I was able to get 'TArray<ACelestialBody*> bodies;' working by creating a forward declaration with 'class ACelestialBody' at the top of the header file. I vaguely remembered forward declaration from an online C++ class I took two years ago which led me to this solution.     When I finally got that done, I went on to try to fill that array with all of the celestial bodies in the scene. In blueprint this could be done with a 'GetAllActorsOfClass' node, but in C++ it isn't so easy. I looked around for a good while trying to find alternatives. I found something called 'TActorIterator' which seemed to iterate through all actors of a class on the scene which was just what I wanted. The only problem was it would not work if I passed it any class that wasn't 'AActor'. This frustrated m

Slow Progress     Continuing on the "tutorial", I tried today to get the function calls working so that I could get the planets moving. I decided to do this in the gamemode. Basically I needed two functions to be called on tick that would update the velocity and position of all planets.     The first challenge was getting a gamemode at all. When I first started trying to create a new gamemode, the editor would crash every other compile. I realized that there were some updated made to the source code, so I downloaded and built that. Immediately after that the editor was crashing every compile. I spent some time trying to debug this but eventually it managed to fix itself and I haven't had a crash since then. I created a CelestialGameMode and a blueprint child. The next challenge was to get a variable for the gravitational constant that all planets could access to calculate the force that should be applied to them. It took me some messing around but I got it working.

Beginning C++     Over the weekend I was able to finally compile Unreal Engine from source. The reason I couldn't up until now was a combination of things. The first was the version of Visual studio I was using. The readme specified VS 2017, while I had always been using VS 2019. I also didn't read the readme up until this point which was something I should have done way sooner. After I figured that out I built with only 20 errors. This was better than the few hundred I was getting from VS 2019 but they were still the same Fatal Error C1076 compiler limit. Because it was only 20 errors I decided to just build it again for the hell of it and it went down to 8 errors. This was confusing but a welcome surprise. On the third build it finished with 0 errors and I was able to open the editor in 4.26 in all of its buggy beauty.      Today I have been mainly focused on getting the planets moving in C++. It's not done yet but I hope to have it done by the end of the week. The

Full Speed Ahead         Since high-school is now officially over, I am finally able to put all my effort towards game development. There are multiple things that I plan to do to further my knowledge and experience. The first is to continue to work in a group of Warren Tech students. This will keep me learning and hopefully motivated. I also plan to learn C++ in unreal through personal projects. This will not only be vital to my career (learning C++) but also very fun as I have found past personal projects to be very entertaining as I am allowed to take the project in any direction based on what I find the most enjoyable. I also decided to go down the road of personal projects as opposed to premade tutorials because I have found over the past two years at WT that I find I learn much better that way (e.g Nexus  from last year).     I have an idea for a personal project, but it's very vague. All I know is I want to do stuff with space. Being able to explore a solar system fluidly

Utter Confusion Top-down game:     So as I said yesterday, I worked on making the Plague Doctor's poison attack better. I wanted a physical poison vial of some kind that would splash an area instead of just immediately poisoning everyone in range. However, I was not able to get this done today.     For some reason this was way harder than I thought. My initial plan was for the Plague Doctor to spawn this vial actor which would then launch itself, and upon hitting something would incur the poison effect upon any players within range. I got all the way through to the part where it would launch before I found the problem that I would spend the rest of my time on without solving. The vial wasn't showing up. It was working, I think, just not rendering. When the AI would choose the AOE attack it would spawn the actor successfully and some time later (presumably when the thing landed) the player would get poisoned but I saw nothing appear on the client or the server.     I

Juggling projects     Today I went back to working on the top down game. I was assigned to finish 2 of the enemies so that I could work with our animator and get everything  everything working; animations lining up with ai tasks and that kind of thing. I chose to finish the Plague Doctor and the skeleton archer (mostly because I had already done most of the work on them, but don't tell the team that). These enemies had had some attacks added to them in the new design doc, most of which were variations on already existing attacks.      For example, the archer was given a triple shot which would just be calling the shoot function three times. I did this but then quickly ran into issues. The first being that, as the three arrows would fire, they would all try to attach to each other like they would to a player. I fixed this simply by checking that the actor that the arrow collided with wasn't another arrow.     The next problem was that the arrows weren't actually sti

Plagiarizing Valve (not actually please don't sue me)     Yesterday I played Portal as research for the step back game. I went in looking for a few key features and trying to figure out how they were done. I didn't exactly want to copy Portal one for one, I really just wanted to get ideas on how Valve approached certain problems. Movement:     The first was general movement. From the beginning of our game I was getting complaints about how the movement didn't feel good. I started to remedy this with air control but that improvement can only go so far. I found a few things about portal's movement. The crouch is really, really low. The jump is surprisingly short and does not adjust for the time you hold down the space bar. Air-control is similar to what we already have in the game (if you jump at a direction on flat ground you can almost but not exactly get back to your original jump position in air).      The jump height and length surprised me the most. I