Pixelmon Mod Pixelmon Mod (2024)

So, what have we been doing to improve battles over the last year? At the end of the last post we identified that, the erroneously named, “unit testing” was the way forward. This was a mistake, as what we intended to identify was not specifically unit testing, but integration testing. The key difference here is that unit tests are designed to test things in isolation, whereas integration tests are for testing the interactions between many different components. Whilst our specific wording may have been incorrect, our intent was the correct one and since that post we have made hundreds of tests for various different parts of the battle engine, and a year after our first dev blog we have reached over 600 battle tests. These tests ensure that Pixelmon battles function as intended, such as checking abilities work, or moves do the correct amount of damage for the specific circ*mstance presented.

Here is a list of a few, of the many, battle bugs that we have found through writing our tests that were previously unidentified:

• Imposter applying after Neutralising Gas leaves the field
• Fixed ShieldsDown blocking all non-entry hazard statuses
• Fixed owned Minior not changing to core form when out of battle
• Fixed SlowStart not resetting count when NeutralizingGas disappears

What is Continuous Integration (CI)? Continuous Integration is the practice of continually integrating code changes into a central place collaboratively. By integrating changes often, we can then test them together to ensure the end product functions as expected from the average player's perspective. To do this, we use a tool that we call pipelines, which trigger any time a developer uploads a change to the Pixelmon project.

This has been a big step forward for us in regards to battle stability. When a developer uploads their changes, we have our game tests run against it, ensuring the most fundamental parts of Pixelmon are working, even before we move to the manual testing phase. We also run each of our battle tests 1,000 times, which ensures we cover a lot of potentially unexpected behaviors, and randomness. For instance, these help cover situations that might change if you execute a critical hit, or if specific abilities have different, exceptional interactions together, which weren't previously observed before. Therefore, every time we make a change to the battle code, we simulate over 600,000 battles, and all in the span of less than 10 seconds.

Something that we feel is lacking, that doesn’t strictly impact the stability of the battles, is the user experience of battling in Pixelmon. Once battling is at a point of unparalleled stability an important goal is to make sure that our battle UI matches that stability, and improves the experience of battling as a whole. Whilst it is important for battles to function well, there’s no point in them functioning at all if they don’t look good or are not easy to use.

Following that, we are looking at making battles more extendable using the datapack systems that we’ve been utilizing so extensively for everything else. This starts with smaller things, such as introducing datapackable types, but then extends to much larger projects such as datapackable moves, abilities and held items.

Finally, the ultimate goal is still to make a system that can be replayed, and work in a transactional fashion for the optimal debugging and reviewing experience. However, this is a much longer term goal and is on a much different scale in terms of difficulty.