The Wrap: Pre-Alpha Excursion
Since starting the main voyage in January, we leaped into creating our Pre-Alpha Build. There were some ups and downs along the way, just as you would expect on any truly admirable voyage.
This week we will hear from a couple voices on our team that you have not before. But first, we wanted to introduce you to Roswell’s Journey’s Development Grid (working on a shorter title)! We plan to update this every week in our blog.
So let’s give you the run down.
Urgent is work that is holding up progress within its chapter, “Needs Work” is areas that have temporary pieces or are otherwise not completely done, “Passable” is for features that are just missing some polish and playtesting, and “Locked” is for the things that will be untouched and making it into the final version of the game (outside of any bug fixes of course).
(Pssttt… Did you hear? There’s a Secret Mission: TOP SECRET)
Hi! My name is Kylandra, or Ky for short. Although this is my first time introducing myself, I’ve been a part of the blogs since the very beginning. That’s one of the many things I do here as the executive producer.
Throughout our Pre-Alpha build, there were many things we noticed that we could approve upon. For this build, I am playing around with different ways for information and communication to flow better. Jumping into this without a proper structure, and changing management systems in the middle of a build, left a lot of room for improvement. For example, Organization is a huge must. I find more and more ways to better organize even the smallest details all of the time.
Another thing I realized, it’s hard for people to read over everything, especially in discord. The sentences can easily blend in with each other and make it take so much longer than necessary to read, especially for us dsylexic folk. And lets be honest, the long spaced out posts just take up so much room, especially on mobile. It’s hard to look at for a quick and easy guide. Besides that, the documentation takes multiple steps to reach. So I have been working on finding ways to make things a little more accessible for everyone. I started making these posters for important information but I have also been working on a couple documents that will be what I call the source of truth.
We will also be working on a workshop to help team members find everything a little easier as we make the changes as well as urging directors to not answer questions that can be found in the documents, rather point them to look there instead. The idea behind not answering any questions that can be found else where is to train the teams to reach out for the single source of truth. That way in case any updates happen, everyone is aware instead of going off possibly old information.
There will be plenty of changes as we figure out how to streamline the processes best for our team. I absolutely love the idea of agile methodology and constantly collaborating and improving. I cannot wait to show you more!
- Ky <3
Embarking on My Animation Odyssey: Unveiling Hatbat's Journey in "Roswell Adventures"
Meet Hatbat: A Creation Taking ✈️
Hatbat, for "Roswell’s Journey," underwent a fascinating transformation from a mere concept to a vibrant character. Witness the journey as I breathe life into Hatbat's virtual existence.
Discovering Animation Tools: Blender Constraints at Play 🛠️
My learning journey led me to the powerful tools of Blender constraints—Limit Distance and Copy Location. These became my brushes, painting the canvas of Hatbat's movements and expressions, turning each animation into a personal masterpiece.
Trials and Triumphs: Navigating the Constraints Code 💡
I won't sugarcoat it; learning constraints had its challenges. Walk with me through the candid account of stumbling blocks turned into stepping stones, and how each hurdle became a lesson in the pursuit of mastering Blender's constraints for Hatbat's animated escapades.
The Eureka Moments: A Personal Celebration 🌈🚀
Every achievement, big or small, marked a step forward in this personal odyssey. Join me in celebrating those Eureka moments, from the first successful constraint implementation to Hatbat's mesmerizing in-game animations.
Conclusion: Hatbat's Flight Beyond My Imagination! 🌠🚀
As Hatbat takes flight in "Roswell Journey," my learning journey becomes a testament to the limitless possibilities that constraints unlock. This blog marks not just the culmination of Hatbat's animated charm but also a personal triumph in the ever-evolving landscape of animation.
So, here's to Hatbat, to Blender constraints, and to the continuous adventure of learning and creating in the vast galaxy of animation! 🌌🎮✨
- Vergil
===Intro===
Hi, I am Isaak Cherdak, The Systems Director at BitRateGames. My focus so far has ranged from implementing foundational components of the game in C++ (UE5), to researching/setting up a VPS and a perforce server, to doing game system architecture design/documentation in UML. Since this is my first blog post here, I will be mentioning everything I have done so far. Full disclosure, I am a CLI person, and hate the pointy clicky (mouse) thingy. Given the systems nature of the work that I do at BitRateGames, I don't think people want to see snippets of blueprint and code followed by the occasional details pane with predictably matching information (implemented map variable? surprise, surprise, there is a map in the details pane). There generally isn't a "visual component" to my deliverables. This coupled with the amount of pressure I was putting on myself to actually contibute to a blog post (and hopefully be consistent about it), led me to decide to make blog posts TEXT ONLY. This probably would deter all but the extremely nerdy, especially given my attention to detail and how verbose I can be.
===END===
===C++ Game Development===
I started by figuring out how to handle adding text to dialogues. Clearly, as a technical person, I wasn't expected to come up with the dialogue. After some questioning regarding how the designers, which are actually in charge of making dialogue, will be entering that information, I was eventually directed to a spreadsheet for how text was managed in the original Roswell's Journey project in Unity. This led me to realize that the task at hand for me was to actually create a system for conveniently adding text which had many pre-defined forms (e.g: different languages) that could be looked up by key. Thus, data assets seemed to be the natural solution. However, as I thought about the size of the spreadsheet, I realized it would be unfortunate to have to manage using a different data asset for each text entry. Furthermore, I realized it would also become a nightmare to have to manage a single data asset that would be appended to/contain every text entry. The compromise I came up with was to create a primary data asset class which would contain a map of key/text entries. Then UE5 would scan all instances of this data asset in a pre-defined directory. This would essentially allow us to use the UE5 details pane's UI for map data structures as a "spreadsheet replacement" while immediately being accessible in the game as needed. While I was able to figure out how to scan through all data assets of a given type, I found that this could become unweildy. Especially, if ran constantly at runtime every time an asset needed to be accessed. I instead prompted to load this during the game mode begin function into a map stored in the game state (because the latter is replicated on all clients). This was so that all accesses to text entries could have the runtime O(1) performance that one should expect from a map. Of course, these original asset maps were unloaded after being merged into the complete map. We don't want to eat your precious RAM for no reason after all. In the end, so long as no one makes a duplicate key in a different data asset of the same type in the designated folder, there should be no issues. From this point onward, I refined the process until one basically needed only to create new primary data asset / UStruct pair, add info about the data asset type/directory to asset manager settings in unreal, add a few macro calls to the game mode code and a few similar boolean/map variables to the game state code. This would magically merge all similar data assets game designers may create in a way that programmers can access, whether from C++ or from blueprint. Needless to say, my task of setting up similar map type data assets for the active/passive properties of abilities and element types was comparatively streamlined. I also made a starting point for the card manager, which was somewhat painful because it has to manage cards which are blueprints. Thus, the equip function would have to be provided the class of the card to spawn (through the blueprint which has the card manager component) and spawn/track it internally. Luckily, these classes could be grouped in a discrete set mapped to UI elements at build time, so it should be extensible as needed later (as long as we aren't planning to create custom cards at runtime...). When unequipping/equipping a different card, the prior one being tracked in the card manager would simply be despawned. You may have noticed that it is not ideal to be despawning a card which may just be moving to the card loadout wheel, only to be soon re-equipped. This is currently done because the card manager currently only allows holding onto one card at a time, because given where we are with the game's development, priorities and all, fleshing it out further isn't yet necessary. More updates on this once we do get to the point where we have UI to manage cards and other pre-requisites addressed so that working on this may become a priority again. Finally, I am tasked with combining all character properties into a "character properties" component which should hopefully be done to a basic usable level (at minimum adding all relevant variables/functions to set/get based on agreed upon game architecture) by next week. Ultimately, it should smooth out the pieces and convert a number of blueprint components to C++, which will ultimately make the project easier to manage (as will be discussed later in this post, asset merging is painful).
===END===
===VCS (version control system) research, setup, and management===
It increasingly became apparent that we would run into issues with git. We tried to implement git lfs early on but we ran into problems. One problem was needing to adjust rules (and watching as people unknowingly commit 1kb empty/corrupted assets to the repo). Turns out that it doesn't help that many people aren't technical (and it shouldn't be expected that they all are). Furthermore, the fix required people to use the command line, sometimes requiring fresh re-cloning (reset --hard HEAD didn't always work...) for git lfs to actually provide the complete artifacts. The second problem was that, whether due to debugging or otherwise, we were burning through our git lfs bandwidth allocation in half the time it would take before it ran out completely. Clearly, something had to change. After some research on alternatives, we settled on perforce (which is the company, and helixcore is the VCS, but I will just be saying perforce anyway). We had considered mercurial, SVN, silly workaround like putting some files in submodules/other cheaper external object stores/etc. but ultimately, this wasn't just about money. Namely, we wanted to give everyone a reasonable process to follow with a GUI and have people work with something that would be valuable to them throughout their career. Given that we didn't need any extra pieces (made for large files) and the gaming industry interest in perforce, it was the clear choice moving forward. After coming up with a workaround so that our "modestly funded" organization could use the free tier, we got to work on figuring out how we were going to actually use it. Before we even get to using perforce, we had to figure out where the server would live. Many people would just settle for a perforce provided cloud service, but this felt like going down a similar path of git lfs's second aforementioned problem: being reliant on the service cost model of another company. Thus, we decided to figure out how to host it ourselves. Some searching narrowed us down to settling for a ~120 GB storage capacity potato spec VPS hosted by [SITE NAME REDACTED]. After some unfortunate scuffles with technical support that gave me a PTSD episode reminding me of encounters in my past work, we were able to figure out our server hosting was fine but the default port was shadow blocked by [REDACTED]'s "core routers" "due to security concerns and potential for abuse". Of course, to get an alternative port to use instead, we had to play guessing games because [REDACTED] "can not provide a full list of ports we block". Luckily, my guesses were correct and I was able to choose an alternative port and the server was live. It only costs 15 dollars a month, not too bad. After our CEO added the core content to the new perforce repository and I confirmed everything was there, we were able to give everyone access. It took some getting used to, but it was really nice not having to worry about large files anymore. I also think the workflow model is really interesting, I just don't think I have fully grasped its capabilities and the right way to use it. Things like the concept of checking out and locking files so that no one can make changes until you put yours in and unlock are really useful for avoiding conflicts with assets. Anyway, at least repository access and progress was restored. We have run into some problems but things have gotten a lot smoother ever since we transitioned. I highly recommend that other small game startups consider playing with perforce Helix Core as well.
===END===
===Game systems architecture===
At some point, I felt it was difficult to contribute for two primary reasons. The first reason is that many people were inadvertently stepping over each other's toes. This may even have been a struggle if everyone was only making changes to source code. However, many people needed to implement their features on the same core set of assets (binaries, though sometimes built in tools in unreal engine helped smooth the process). This nonetheless caused many merge conflicts that were often difficult to correctly resolve. The second reason is that people were developing things in the general area of what is needed with little semblance of what will exactly be needed by a game designer. Game designers will be experimenting freely with what they are given but within the bounds of the requirements for the game. A deliverable from a developer can be frustrating to work with when it is limiting in functionality. However, a deliverable can also be difficult to work with when it gives too much freedom as this may support game design practices that are too unbounded. For example, a game developer can start prototyping things that were agreed not to be put into the game because the developer provided components which made it easy to do so. The solution I came up with to both of these problems was to review and document all the game systems, the scope of their intentions within the game, and the properties/methods that they can be expected to have. This was done in a UML style format to illustrate what has been documented so far (originally in draw.io, now in mindmeister). I discussed with game designers and the CEO the different ways that each system is intended to be used in the game. Ultimately, in working on and creating this, it was possible to distill this information in a simple way that we ended up referring to as "developer documentation". Firstly, this approach allows us to address the issue of conflicts due to few core assets because it gives us a clearer sense of the components we need and allows us to separate the pieces so that people can work on their own assets and link them to a single asset later. Essentially, it reduces the difficult process of resolving asset conflicts to generally only ensuring that the reference to other's assets are maintained. This is as opposed to having to ensure all property/blueprint graph/etc changes of all contributors are correctly merged in one place. Secondly, this approach allows us to create a contract of sorts between developers and game designers (arguably far more important than the first reason). The game designers have reviewed and went through all the things I have finalized as the expected use cases, properties, etc of all game systems. This ranges from the kinds of properties abilities can affect to the various applications of teleportation. That being said it will be a living documentation, actively being referenced and updated wherever relevant and at weekly meetings. Game developers will be able to make specific components providing just the right amount of flexibility. At the same time, the game designers can expect to have a smoother process of utilizing these components for prototyping and putting the game together.
===END===
===Priorities moving forward===
As mentioned, a lot of my tasks fell under the umbrella of best fitting into the needs at present. However, as things have stabilized and much work is being done without my contributions to implementation being actively needed, I will be focused on overall quality, cohesion, and integration of the game's technical systems and implementation. This means continuing my work on game architecture but also shifting focus towards auditing existing/ongoing code, and the development of tests at different levels. Of course, I will still be involved in some development here and there, but I am ultimately focusing myself where my skills are needed most.
===END===
===Closing thoughts===
It can be said that I went where I felt I could be most useful to the game's progress. That being said, I progressively enjoyed each transition of tasks more and more, perhaps because in addition to feeling that I was contributing more holistically, there was a sense that the kind of work I was doing was also more natural for me to execute on. I can program, but I can be very OCD about it, which honestly isn't particularly productive at early stages where we are trying to figure out which mechanics are necessary and what is most fun. I can do Linux administration and figure out how to setup a server, but at some point too much focus on it becomes disconnected from making direct contributions to the game (I become sad). In contrast, thinking about the systems in the game and documenting what their properties, containing structures, and relationships will be, ultimately felt like the best fit for my nature and interests. This architectural focus also ends up addressing a necessary creeping issue that results in having so many creative types going their separate ways adding features to the game. Anyway, rant over. I haven't done this before but if anyone has any questions, suggestions, etc., please feel free to direct them to ijcherdak@bitrategames.com. Until next time...
===END===
Here’s our Multiplayer camera.
It now has padding, is much smoother and works with any number of player.
It also is all converted to C++.
All I need to do is fix this bug: The margin is not working when player 2 is on the right.
And make it so that the camera also moves on the Y axis.
- Andrew S.
We hope you’re enjoying the journey we call Roswell’s Journey. There’s so much more to delve into so you’ll have to stay tuned.
Don’t forget the secret mission, only the best will make it there.
