Dev Diary: Week 44

As university dawns again, so does keeping an active work schedule. This, for me, means keeping a dev log that keeps track of everything I’m doing and to keep the brain juices flowing! I’ll try to make the nonsense I spit make sort of sense, but I apologise pre-emptively if some of the stuff sounds like tech magic. So, without further ado, here’s the rundown of what I’ve done week 44!

API Work

I started the week getting the hang of two different APIs that I will use for my coursework that is about learning (surprise surprise!) how to read documentation and implement application interfaces that one might not be masterful in. The two APIs I’ve decided on using are WPF and ASP.NET. I decided on these two APIs as they are both Microsoft-made interfaces that have years of usage online if I ever were to get stuck, as well as both having quite detailed documentation. Now, you might wonder, what is WPF and ASP.NET? Well, WPF stands for Windows Presentation Foundation and is a graphical user interface library used for many Windows based applications. It’s designer functionality builds off of XAML-files which is a markup language for visualizing every part of the UX of the application. ASP.NET is a server-side web framework mostly used for web applications, but the framework itself can be used to create Peer-to-Peer applications, a method of networking where the client works as a server for the user’s peer to connect to. This is used to circumvent the usage of servers on the developer’s side, meaning the application will not be made redundant because the developer decided to turn off the server.

Hoo boy, that was a lot of mumbo jumbo, so let’s make it simple. WPF is all of the stuff you see (aka the front end). ASP.NET is the network stuff that lets you, the user, connect to another user in another place (aka the back end). Now, here’s the kicker. For the coursework in question, we have to create some piece of software, tool, or gameplay addition that utilizes at least one external API. That’s right, one. So why am I using two APIs? Well, WPF has a simpler brother called Windows Forms. Windows Forms is another great graphical user interface library that is also commonly used for a lot of Windows applications. It is an API that I first used back in 2016, and have made a lot of applications that have never seen the light of day. These tools were mostly internal apps that helped me personally and were made with my machine in mind alone. However, as good as Windows Forms is, I find it personally quite clunky as it is more about the designer experience alone and then the programming experience alone. With WPF, these two experiences are more intertwined and would allow me to switch between programming the backend and frontend at a second’s notice. Additionally, WPF is still similar to Windows Forms in a lot of ways, and thereby this minor transition would be nothing but a miniscule hitch in my development. So, yes, the project in question is utilizing two different APIs, but the focus lies with ASP.NET, an API that I have never worked with prior to this week.

With that out of the way, let me introduce you to my software!

Wow, so cool! This is revolutionary, industry-changing, will change the virtual landscape forever, I hear you say through the monitor. Please, you humble me. But in all honesty, yes. This isn’t very impressive on the surface level. It’s two windows talking to each other, big deal. But that’s where the untrained eye is wrong! What is actually happening here is that I am using my local IP to connect two instances of the same software to each other. They don’t speak on a client level at all, they’re not “actually-the-same-instance-but-two-different-windows-so-they-share-variables”. No, these are different clients communicating. Now, in theory, this should work cross machine, but I have yet to get that to work and that is what I will spend next week trying to solve. But let me try to explain what is happening here then, and fair warning! There will be some tech nonsense coming up so don’t be scared of that!

So what is happening here? First off, we have each user filling out their username. That part is simple, and the username is simply to let the users know who wrote what. What’s next then? Well, the users both enter a port that the other user will use to connect to their IP with. See the port as an identifier for the connecting user to know where you will be communicating. If the IP is their phone number, the port is the channel you will call them through. Then there’s the IP, or partner address. This is where the user enters the IP of the user they will connect with, as well as the port that that user entered to properly connect to each channel. With those parameters down, the users can both press the “Start Chat!” button and start chatting! With the chat active, both users have the software running a local server on their machine and on their IP address. By having the users connect to that server and then route through the software according to a route template set in code, certain methods can be called when an event happens, such as a message being sent. In this case, when a message is being sent, that message is passed through the server and sends it to the connected client. Once it reaches the client, the method will be invoked and will show up in the client’s window. Pretty simple, right?

But all of this code, these clients and these self-hosted servers, they’re not my coursework. All of this code was simply for me to get to grips with how ASP.NET works. The project I’m making here isn’t just a chatting application, but rather a simplistic turn-based game, such as Tic Tac Toe with an added chat functionality that doesn’t rely on a server. So whilst this has been informative, and I am more confident in my abilities now than I was a week ago, as soon as I figure out how to solve the cross machine problem I’m currently facing, this particular instance of the project will be used for reference as I’ll start tackling the actual assessment.

Gameplay Work

As another part of the work I’m doing for my course, I have to create a game mechanic. This mechanic will use some of the different concepts and tricks that we learn about in class, such as raycasting, look-up-tables, delta timing, etc. Although this project still needs to be confirmed with my lecturer, my current plan is to recreate the V.A.T.S. system from the modern Fallout games (excluding Fallout 76 as that ditches the time-slow mechanic). Why the V.A.T.S. system, you might ask? Well, the V.A.T.S. system relies on multiple different techniques to make it work. First off, and most obvious, there’s the time slowing mechanic. Modifying the time-scale should be enough to make this work, but as I still require the UI to respond, some unscaled delta timing will need to be used. Second, the V.A.T.S. system allows the player to select a body part to attack, ranging in variety depending on their foe. Although more research will be needed, my current guess is that this system relies on multiple raycasts connecting the player and the body part. Depending on the length of each raycast and the amount of raycasts that connect, a percentage value is calculated whether the player will hit or miss. Finally, each body part is highlighted in V.A.T.S. which could be made through a wireframe shader or similar that will turn on whenever the player highlights the selected body part.

Personally, I think this is enough to merit the V.A.T.S. system to be something to be recreated for this module, but I have to first ask my lecturer about this to make absolutely sure that it is fine. Until then, I will work on some proof of concepts, as well as continue work on the chatting application outlined in the previous chapter.

Additional Work

Outside of university for a second, I have started work on some of my writing. All of that writing will eventually be moved over here, but for now you can find every chapter of my serial “Where the Lighthouse Shines” on my subreddit. This work is simply for me to improve my writing skills as that is a skill I want to develop for the games industry.