#sparts

HEY YOU. YES YOU. here's some new slime beds for your weird aliens. we have a significant lack of new sprite assets, i will fix that. the imgur link below contains the full res and a 2x sized one, for better scaling with most panels. these are recolorable however you like, and can be used with or without credit.

I recently started working on a personal project with a good friend of mine, using a python library called Sparts. Developed by the folks at Facebook, Sparts makes it dead simple to write new services (ie. software that continuously runs, doing whatever you’ve programmed it to).

Sparts is built on top of two foundational concepts: 

A “task” is, as its name suggests, a task that you would like to happen.

A “service” is a perpetually running program (otherwise known as a “daemon”, in computing-speak) that performs the tasks you write and specify.

You generally will have one service that runs many tasks; these tasks can run continuously, at regular intervals, or just once depending on how you program their logic. 

As per its design goal of making the process of creating your services/tasks as simple as possible, Sparts is implemented with an abstraction model such that there is a main service class and a main task class that you as the developer will subclass from to make your service(s) and task(s). The parent classes are written such that once subclassed, all you have to do is “fill in the blanks” with the logic of your tasks and services by overriding specific methods of the parent (or superclass). These methods are pre-defined but typically contain no logic, as that is what you are supposed to implement in your specific instance of the task.

In this manner, the typical work flow is to create a new task class that inherits from the main task class, otherwise known as subclassing the main task class. Note that there are actually two main common ones, but we’ll get to that later after we talk about the work flow. Then, you define the logic of that task by overriding the “execute” function that was defined as an empty function in the parent task class. After defining your task(s), you will create a new service class that inherits from the main service class (called “VService”) and then define a class list variable inside of it called TASKS, with each of your tasks as the list items. Then, all you have to do is run your service and it will handle running your tasks correctly as you’ve specified. 

You fill in the blanks for the logic behind each of your tasks, add them to a service’s list of tasks, and boom- you’re off to the races.