Package: game-forge
Forge (Pygame Wrapper)What is Forge?Forgeis a game development library that aims to help novice developers make the 2D games and experiences of their
dreams using a simple and opinionated library that wraps aroundPygame.FeaturesThe USP ofForgeis its powerful CLI,Kilnthat allows the creation of new objects quickly and easily. It takes
inspiration from theRailsCLI.A complete UI library withinForgecalledHearthwhich is used to create complex UI elements in code using a
system of constraints that make it resizable and applicable to a large variety of screen sizes. It takes inspiration
fromUIKitConstraints and ThinMatrix’s GUI library.Written inPython, a language that most novice developers already know basic concepts of, and is easy to pick up and
get started with.Type-hints throughout the code for a better development experience.Extensive documentation generated using theSphinxlibrary.Why a new Library?Pygameis an excellent library to start off with but there are a few key problems with it:Doesn't have the best development experience due to a lack of type-hints, good documentation and its general design.A lot of globals used throughout the code leading to various wildcard imports.The structure of aliases within the library can often confuse many autocomplete engines’ type systems.The code is not very well modularised leading to a difficulty in separation uses of various components. Each file
becomes very long and difficult to work with.The crux of the argument is that to many any serious project withPygamerequires the creation of another small
library on its own.💡 Using Pygame for large projects is like using vanilla JavaScript for a large application. You end up making a small and terrible framework of your own at the end, anyway.Why a Wrapper?For all its demerits, there is one big reason why I am usingPygameover making something from scratch: it is
cross-platform.Making a game engine usingOpenGLwould lead to a greater flexibility, but would drastically increase the scope of the
project. That would mean adding important features like theKilnCLI andHearthUI system would take far more time
than is reasonably necessary.While the scope of the project even as a wrapper is quite large, its use-case (a tool for novice developers) doesn't
justify the extra overhead that a graphics API likeOpenGLadds.What are the Changes?In short, everything exceptpygame.displayandPygame’s main-loop and internal systems (events, timers, etc.) will
be completely re-written forForge. I will have a custom implementation for those internal systems. While Pygame will
be a dependency for me, the ideal scenario involves the end-developer not realising thatForgeunder the hood,
actually runsPygame.Target AudienceForgeis designed for amateur developers that want something simpler than Unity or Godot for making simple 2D
experiences but something with more depth and nuance thanPygame.Pygletexposes moreOpenGLthan what I would be
comfortable with.Forgeshould not only create good games but also create a welcoming, fun and light development environment but still
have enough depth to create more involved and complex experiences.Development ProcessVersioningX.0.0A major version involves a completely new feature that requires a drastic change in current architecture. All the
current features are planned with the current architecture in mind. At its current state, the project will stay on
version1.X.X.0.X.0A minor version involves a new feature that can be implemented using the current architecture. Each minor version
creates a new GitHub branch.0.0.XA tiny version involves new implementation of an existing feature or, bug fixes using existing architecture.Planning New FeaturesSpend two days on planning new features to be added toForge. Think of all implementations, use-cases and future
updates to it. Think of applications within current example projects and see whether they are actually useful or, reduce
code complexity at all.Working on ArchitecturePlan the architecture of the feature; the design patterns used, the way it interacts with current systems and how it
will be exposed to the end-developer.Writing TestsAll new features will be implemented using a test-driven-development process forForge. The basic empty implementation
and abstraction methods will be implemented. Then, detailed tests for the feature will be written using theunittestmodule. The aim is for 100% coverage and then some.TheReStructuredTextdocumentation should also be added, even for tests, at this point.Implementation and DebuggingFinally, write the code to implement the feature. The aim is to keep the code easy to read and maintain. The files
should be short and have a singular purpose. Modularise the code and efficiently pack it. No fancy techniques should be
used unless absolutely required to achieve the desired output within certain constraints.TheReStructuredTextdocumentation should also be added at this point along with any single-line explanation comments,
if required.CLI IntegrationIntegrate the feature, if applicable, with theKilnCLI. The aim is forKilnto be developed alongsideForge Coreand not as a separate entity to avoid the package-within-a-package feel when using it. Kiln should feel like a natural
extension ofForgeand not like an additional, optional feature. CLI should be given first-class support.Final Debugging and DocumentationUndergo the final debugging process. No bugs should be shipped if I am aware of their existence. The release cycle may
be pushed back but, the uploaded code should be in a completely usable state.TheSphinxdocumentation should also be updated at this point.Commit and Push to Git RepositoryOnce the code has passed all unit tests and works as expected in the example project tests, it should be committed and
pushed to a public Git repository. If a new feature is being introduced at this point, the correct branch should be
created and checked out. Each branch on the repository should contain an internally complete project (however
impractical it may be to use).Feature DetailsKilnCLIKilnis the CLI forForge. The trouble with simple game making tools is that often, developers are forced to
re-write the same boilerplate classes with inheritance, and the same default methods as always.Kilnmassively simplifies this process by using simple command line arguments to create the Python files with custom
boilerplate so that the developer can focus on the actual development and implementation details rather that being
bogged down with the actual code.Kilntakes inspiration from theRailsCLI.Implementation DetailsHearthUIHearthis the UI manager forForge. UI is often an overlooked component of game making tools. Especially, in a 2D
medium, the UI needs to scale, move with a display of custom dimensions and aspect ratios and look good while doing it.Hearth uses basic shapes and custom versions of common UI components. The components thatHearthsupports are:ContainerPanelButtonCheckboxSliderList ItemsThe scaling is made possible by an advanced system of constraints that allow for the changing of component dimensions by
changing the display or parent container sizes. It allows for the creation of complex and scalable UIs at multiple
display sizes and aspect ratios. The constraints thatHearthsupports are:Hearthtakes inspiration form Apple’sUIKitconstraint system for its own implementation of constraints.Implementation DetailsEvent SystemImplementation DetailsPhysics SystemForgeuses a basic Physics component library to simulate simple Physics-based experiences in 2D.Pygamealready has
a few Physics and Maths classes and implementations however,Forgeshall not use either for its internal
representation of Physics objects.Implementation DetailsPre-Commit ChecklistAll the unit tests pass.The code is correctly documented.The documentation is updated to theindex.htmlfile using Sphinx.There are no known bugs in the code.PyCharm’s pre-commit checks pass.All code is manually tested and, if required, added to the test playgrounds.The correct branch is checked out and only the required files are committed. Internal test files are not to be
committed.