Workflow for Edgemaul Legends
My first dev post on how I planned my workflow for Edgemaul Legends
Edgemaul Legends Series
- This post
- Edgemaul Legends Jenkins Pipeline
I finally got back into writing! This time around instead of doing tutorials, I think I’m just going to document how I am building my game. The tutorials were draining when I was doing this and I planned for this to hopefully be useful to someone else as well as document the process of how I built the game and why I did it in the way I did
This first post is more a less how I outline the workflow I do for a potential feature all the way to building it. This is mostly focused on tools I use and not any UE5 code
Codecks is a very cool project management tool that is centered around game development. Codecks uses a hierarchy system to represent tasks in your project. The largest is a project, then comes decks and finally the card itself
My codecks setup currently makes use of 3 projects
One project is for active development. These project contains a deck for all work that needs ot be done (Backlog) and a deck for each active version being developed on. Typically this is the active production version, the upcoming production version and then finally the active dev version. An example,
My game is on version 1.10. I have a deck in dev for 1.10 where I would be fixing bugs in. We just wrapped up with version 1.11 that we plan on releasing a week from today. Now we are currently working on 1.12. Once we release 1.11, the 1.10 deck is moved to the Previous Version project to serve as a changelog.
Each deck in my active dev project has cards that are fully planned out and can be grabbed at any moment for active dev.
The GDD deck is short for Game Development Document. This is high level idea’s such as what your game is about, what abilities are in the game, npc names etc. My GDD still needs some work which I plan on doing after this post! The idea is that you have the GDD, turn them into tasks that you put in the backlog and then drag them to whichever version you plan on releasing them in
I use the effort points system in terms of how many days I think it will take for me to implement a feature. I attempt to pull in at least 5 points(days) worth of work for my project each week to make good progression. Here is an example of a completed card that I would pull into my hand
I like to outline the feature for this card and included functional tests for me to consider the work on this card to be completed.
Making a new Perforce Stream
Now that I have a feature I want to implement, I make a new task stream in perforce. I like to use tasks due to the little amount of space it takes up for metadata vs a developement branch and it also just feels more natural to me since I came to Helix Core from Git. I like to make my streams like this, //edgemaullegends/task0.1-experience_comp.
Inside the Engine
Once I picked up a card that I want to work on, I hope right into Unreal. I work using Test Driven Development. Hopefully you read that link, if you didnt to put it simply, I create a small test, make code to make that test pass and then do that continuously until the feature is implemented. I won’t go into too much details here since making functional tests as well as general blueprinting is outside the scope of this post
The final step is to verify my work. I like to make sure that no broken code is ever pushed to my dev branches. I do this with Jenkins. My Jenkins pipeline will build the editor version of my project, lint using the LinterV2 plugin on the UE marketplace, run functional tests with Gauntlet and then finally, build the windows client and server. If all of these steps pass and the feature is implemented to my satisfaction, I merge the task into my dev branch and then repeat the process
I’m still in dev phase and haven’t done any big releases. I will write another post when that comes. I do have the way I want to execute my releases planned. Once all the tasks are done for a dev stream, I merge the dev stream into my main branch. My main stream is a QA(quality assurance) stream or known better in the gaming space, public test environemnt. I let me releases linger here for a while and once I’m satisfied with the testing the users do I then move it to release.
The release stream is more or less static. The only changes to it will be bug fixes which will get merged downstream to the main stream and then to the current active dev stream