“What Time is it? GAME TIME HOO!”

Backyard Basketball, is finally ready to come off the bench for some sweet public testing! You can now play again on ScummVM this beloved Backyard Sports title (not to mention the last unsupported game on the SCUMM engine). Play with the Backyard Kids and even create five of your own! This game also features (now former) NBA and WNBA stars Kevin Garnett and Lisa Leslie!

Much like the other sports titles of this franchise, controls are point-and-click by default, with gamepad and keyboard options. Pick your favorite kids and play some 3 on 3 basketball. Don't forget your 110% Juice or Dunking Donut for a slamma jamma! Pass that ball in, listen to the live commentary from Sunny Day and Barry DeJay and shoot some jumpers on your way to a championship.

Are you ready to play? Dig up your good old CD and fire up the latest daily build!

Comprehensive Pull Requests Achieved During Google Summer of Code

Recap of my project: ScummVM includes a global fully configurable keymapper, but this requires engines to be adapted to use it. Hence the goal of this project is to integrate the customised ScummVM keymapper into the engine’s input handling system. This involves modifying the engine-driven input handling code for mapping user input to in-game actions.

Explanation: ScummVM contains multiple games due to its nature of porting several game engines, each engine has a name and the following list has the Engine name preceding it, thus each pull request is the work I did in integrating the keymap to each of the engine in separate Pull Requests in the course of my Google Summer of Code program.

  1. AGOS Engine: Pull Request

  2. COMPOSER Engine: Pull Request

  3. MADE Engine: Pull Request

  4. SAGA Engine: Pull Request

  5. HUGO Engine: Pull Request

  6. CINE Engine: Pull Request

  7. STARK Engine: Pull Request

  8. CRUISE Engine: Pull Request

  9. GROOVIE Engine: Pull Request

  10. LURE Engine: Pull Request

  11. Introduce I18N comments and better keymapping labels: Pull Request

  12. TOUCHE Engine: Pull Request

  13. TRECISION Engine: Pull Request

  14. BBVS Engine: Pull Request

  15. FREESCAPE Engine: Pull Request

  16. ILLUSIONS Engine: Pull Request

  17. DRACI Engine: Pull Request

  18. MADS Engine: Pull Request

  19. TSAGE Engine: Pull Request

  20. HOPKINS Engine: Pull Request

  21. TINSEL Engine: Pull Request

  22. TUCKER Engine: Pull Request

  23. SWORD1 Engine: Pull Request

  24. TOON Engine: Pull Request

  25. Adding I18N Comments: Pull Request

TOON Engine & ANDROID BUILD & TITANIC Engine

Toon Engine

Toon engine in one of those point and click engines but still require keyboard inputs, it has become easier for me to identify keys and map them into the keymap, thus tackling toon engine was not that big of a hassle.
Here is the PR.

Android Build

One of the highlights of this week was that I was able to run the android build on my PC thanks to my mentors, it was tedious and strenuous process but it was important in my personal development in learning how to use docker-container and what problems could arise when building an android-build, one issue was that as my docker container was in unix environment, some executables were built for windows format so I had to remove carriage returns (windows format) for the build to be able to execute. Now I am able to access ScummVM in android mode from my PC.

TITANIC Engine

There were no demos available for titanic engine and I am running out of engines that I am capable of mapping into keymaps so this is the first game that I bought, it was pretty cheap and interesting so it was not that big of an issue. Now in terms of actually tackling the engine it seems much more complex than anticipated.

The engine is very intertwined when checking for movement, so it took some time to figure it out

it seems the above class takes input then sends it to another function which fetches the movement then this is being used for movement.
As of now the code is not complete or clean so the PR is not ready as of yet.

Week12 – Wrap-Up

This week’s work mainly focused on wrapping things up as the end of the project is approaching, and I am striving to refine the details.

Quantitatively, I accomplished the following tasks:

  1. I thoroughly tested my code following the correct workflow.
  2. In the old version, when matching filesets in the command line, it would repeatedly create the same fileset multiple times (manifested in the logs as multiple occurrences of “Updated fileset: xxxx”). After some debugging, I found the problem. As shown in the diagram, the old version would automatically insert a new fileset after all possible match failures, which seems reasonable. However, I had already implemented the logic of “creating a fileset first before matching” in a previous version. This led to duplicate logs since the outer loop of this code was
    for matched_fileset_id, matched_count in matched_list:,
    meaning that the number of potentially matched filesets would result in the same number of duplicate logs. This issue was minor but stemmed from my lack of careful consideration.
  3. I added several new features: for instance, I added checkboxes next to each file on the fileset detail page for developers to conveniently delete unnecessary files, included sorting functionality in the fileset table on the fileset page, and highlighted checksums corresponding to detection types. These features did not involve complex logic, as they were primarily frontend enhancements, and therefore were completed without difficulty.

Looking back at my entire project, I have finished nearly 3000 lines of code over 12 weeks.

I am pleased that most of what I’ve accomplished so far has met expectations. However, there are still some improvements needed before deployment, such as adaptation for MacBinary and other Mac formats, and user IP identification. My sense of responsibility drives me to continue refining this project even after GSOC ends until it can be truly put into production. I look forward to that day! 😄

TINSEL Engine & TUCKER Engine & SWORD1 Engine

Tinsel Engine

Tinsel Engine was also somewhat simple but there was an area where I had to figure out where save and load menus are opened so I can disable the keymap, it took me some time to figure out the best places to enable and disable these

This was after intense debugging but I finally figured it out.
Here is the PR.

TUCKER Engine

As like any other engine, figuring out where to disable the keymap was the hardest part but this was still relatively easy.
Here is the PR.

SWORD1 Engine

Atleast for this engine there are functions defined where savescreen is being initialized and being removed so wasy to implement keymaps, one thing weird was that this engine has 2 _keypressed, one belonging to Control class and and 1 to Engine class so had to replicate that for _customType, other than that no major issues were faced
Here is the PR.

Week 11- Testing

This week, I mainly focused on testing the system I previously developed to see if there were any overlooked issues. Fortunately, the problems I discovered were minimal. Below are the issues I fixed and the new features I implemented this week:

  1. Marking a fileset as full on the fileset page is straightforward; I just needed to add a button for that.
  2. The set.dat file may contain checksums for “sha1” and “crc,” which I initially forgot to ignore. As a result, these two checksum types appeared in the fileset.
  3. I added a “ready_for_review” page. I realized I could reuse the file_search page, so I simply created a redirect to this page.
  4. Speaking of the file_search page, I finally fixed the pagination error. The issue arose because I hadn’t considered that the query page could include filter conditions, which caused the results to show the entire table (i.e., without any query conditions). This error was hidden in a small detail, but I managed to fix it.
  5. I added a user_count based on different user IPs. I implemented a simple prototype, but I’m still contemplating whether there’s a better solution, such as creating a new table in the database to store user IP addresses. I’m not sure if this is necessary and I may consult my mentor for advice later.

Overall, this week has been relatively easy, but I’m still thinking about areas for improvement.

tSage Engine & Hopkins Engine – Week 10

tSage Engine

This engine does not use the scummvm’s event class but its own, so I had to include customAction in that class.

Also in some cases the engine uses bitwise masking to check which event type is being triggered hence I had to give a value to the custom type which won’t mess up the masking if the event types were to be checked.

Now we can identify event type

Here is the PR.

Hopkins Engine

Hopkins was an easy engine but the only thing where I had used the most time figuring out was where was the best place to disable the keymap so text input can be taken

Other than that there was nothing too complex,
Here is the PR.

 

Week 10 – Fixing

This week, my main focus was on filling in gaps and fixing issues. Here are two significant changes I made:

Due to the need for the database backend to return counts of matches, missing items, and extras when verifying file integrity for users, I quickly realized that returning only a few mappings containing counts after the database query was insufficient (other functions require detailed information). As a result, I changed the dictionary type from defaultdict(int) to defaultdict(list).

At the same time, I discovered that I couldn’t retrieve user filesets on the fileset query page, even though the logs showed that I had indeed inserted several user-status filesets into the database. After investigating, I found the root cause of the issue. I had not considered inserting metadata for the game when the user-status filesets were added. After making some modifications, I resolved this problem.

In summary, this week’s work was much easier than before; I just needed to test different scenarios and make fixes based on the results.

Freescape Engine & DRACI Engine & MADS Engine – Week 9

Freescape Engine

Few games in freescape engine have non interactive demos that auto play actions/movement, so the issue with my PR was that the the demo shouldn’t allow any input while my method does allow the user to interact in demo.

So my initial thought was that event.customType was being given value of 0xde00 when demo input was being generated and it was later checked while polling event, and if it had that value, it would continue and not allow user inputs to be processed.
But for some reason the statement else if (event.customType != 0xde00) is not being triggered so there is something else going on that I am unable to figure out hence I have halted my progress for this engine.

DRACI Engine

Draci Engine was another simple engine that did not need much effort and was done in one day

Here is the PR.

MADS Engine

Something unique for mads is that it stores the keys in stack then processes them somewhere else so I had to replicate that for custom actions.

Another issue was that the keymap has an action to restart animation in main menu and it uses the “s” key, as there is a place in the game where user input is being taken so I had divide the keymap and turn it off when main menu is being shown, this took some time to figure out as I couldn’t find the best place to turn of the main menu keymap.

Here is the PR.

Week 9 — Major Features Finished

Week 9 — Wrapping Up Major Features

This week, I mainly focused on the last scenario, which involves performing integrity checks submitted from the user side. Structurally, this task is not very different from the previous scenarios. However, I initially adopted an unreliable matching method:

I first searched the database for filesets where the game ID, engine ID, platform, and language matched the metadata provided by the user. Then, I used a two-pointer approach to check each file within these filesets.

If any file did not match, I marked it as ‘size_mismatch’ or ‘checksum_mismatch’. However, I quickly realized that this comparison approach was unreliable; it did not conduct boundary checks and overlooked many unexpected situations.

Given the files of a single game, comparing them one by one is an acceptable time complexity (referring to the implementation of the match args in the previous dat_parser.py). Moreover, based on my experience playing games, it is unnecessary to report ‘checksum_mismatch’ or ‘size_mismatch’. Providing three responses: ‘ok,’ ‘extra,’ and ‘missing’ would be sufficient. Therefore, I restructured this part of the logic and ran some tests, and it looks like it’s working very well now!