Recherche avancée

Sur d’autres sites (11779)

• Approaches To Modifying Game Resource Files

  16 août 2016, par Multimedia Mike — Game Hacking

  I have been assisting The Translator in the translation of another mid-1990s adventure game. This one isn’t quite as multimedia-heavy as the last title, and the challenges are a bit different. I wanted to compose this post in order to describe my thought process and mental model in approaching this problem. Hopefully, this will help some others understand my approach since what I’m doing here often appears as magic to some of my correspondents.

  High Level Model
  At the highest level, it is valuable to understand the code and the data at play. The code is the game’s engine and the data refers to the collection of resources that comprise the game’s graphics, sound, text, and other assets.

  
  
  Simplistic high-level game engine model
  

  Ideally, we want to change the data in such a way that the original game engine adopts it as its own because it has the same format as the original data. It is very undesirable to have to modify the binary engine executable in any way.

  Modifying The Game Data Directly
  How to modify the data ? If we modify the text strings for the sake of language translation, one approach might be to search for strings within the game data files and change them directly. This model assumes that the text strings are stored in a plain, uncompressed format. Some games might store these strings in a text format which can be easily edited with any text editor. Other games will store them as binary data.
  

  In the latter situation, a game hacker can scan through data files with utilities like Unix ‘strings’ to find the resources with the desired strings. Then, use a hex editor to edit the strings directly. For example, change “Original String”…

  0098F800   00 00 00 00  00 00 00 4F  72 69 67 69  6E 61 6C 20  .......Original 
  0098F810   53 74 72 69  6E 67 00 00  00 00 00 00  00 00 00 00  String..........
  

  …to “Short String” and pad the difference in string lengths using spaces (0x20) :

  0098F800   00 00 00 00  00 00 00 53  68 6F 72 74  20 53 74 72  .......Short Str
  0098F810   69 6E 67 20  20 20 00 00  00 00 00 00  00 00 00 00  ing   ..........
  

  This has some obvious problems. First, translated strings need to be of equal our smaller length compared to the original. What if we want to encode “Much Longer String” ?

  0098F800   00 00 00 00  00 00 00 4D  75 63 68 20  4C 6F 6E 67  .......Much Long
  0098F810   65 72 20 53  74 72 00 00  00 00 00 00  00 00 00 00  er Str..........
  

  It won’t fit. The second problem pertains to character set limitations. If the font in use was only designed for ASCII, it’s going to be inadequate for expressing nearly any other language.

  So a better approach is needed.

  Understanding The Data Structures
  An alternative to the approach outlined above is to understand the game’s resources so they can be modified at a deeper level. Here’s a model to motivate this investigation :

  
  
  Model of the game resource archive format
  

  This is a very common layout for such formats : there is a file header, a sequence of resource blocks, and a trailing index which describes the locations and types of the foregoing blocks.

  What use is understanding the data structures ? In doing so, it becomes possible to write new utilities that disassemble the data into individual pieces, modify the necessary pieces, and then reassemble them into a form that the original game engine likes.

  It’s important to take a careful, experimental approach to this since mistakes can be ruthlessly difficult to debug (unless you relish the thought of debugging the control flow through an opaque DOS executable). Thus, the very first goal in all of this is to create a program that can disassemble and reassemble the resource, thus creating an identical resource file. This diagram illustrates this complex initial process :

  
  
  Rewriting the game resource file
  

  So, yeah, this is one of the most complicated “copy file” operations that I can possibly code. But it forms an important basis, since the next step is to carefully replace one piece at a time.

  
  
  Modifying a specific game resource
  

  This diagram shows a simplistic model of a resource block that contains a series of message strings. The header contains pointers to each of the strings within the block. Instead of copying this particular resource block directly to the new file, a proposed modification utility will intercept it and rewrite the entire thing, writing new strings of arbitrary length and creating an adjusted header which will correctly point to the start of each new string. Thus, translated strings can be longer than the original strings.

  Further Work
  Exploiting this same approach, we can intercept and modify other game resources including fonts, images, and anything else that might need to be translated. I will explore specific examples in a later blog post.

  Followup

  • Translating Return to Ringworld, in which I apply the ideas expressed in this post.

  The post Approaches To Modifying Game Resource Files first appeared on Breaking Eggs And Making Omelettes.

• ASP.net swf game file preview (thumbnail)

  12 avril 2015, par Moatasem bakri

  Scenario :

  I really in need for your help.
  I have multiple swf game files which I want to view them on the page as thumbnails and let the visitor click on it to play the game.

  Required :

  I want a tool that let make take a thumbnail from swf file, maybe the first frame of the file as image to view it.

  maybe if there another way to preview the files in asp.net pages without the need to the following way could be better.

  Bad news

  I have viewed all the possible answers on StackOverFlow and even on Google but with no luck, they lead my to the following :

  • use : https://swf.codeplex.com/ : I have tried it and now result
  • use ffmpeg : but the feature is not available yet, and I’m getting the following error
    ’swf : could not find codec parameters’

• Game Music Appreciation, One Year Later

  1er août 2013, par Multimedia Mike — General

  I released my game music website last year about this time. It was a good start and had potential to grow in a lot of directions. But I’m a bit disappointed that I haven’t evolved it as quickly as I would like to. I have made a few improvements, like adjusting the play lengths of many metadata-less songs and revising the original atrocious design of the website using something called Twitter Bootstrap (and, wow, once you know what Bootstrap is, you start noticing it everywhere on the modern web). However, here are a few of the challenges that have slowed me down over the year :

  Problems With Native Client – Build System
  The technology which enables this project — Google’s Native Client (NaCl) — can be troublesome. One of my key frustrations with the environment is that every single revision of the NaCl SDK seems to adopt a completely new build system layout. If you want to port your NaCl project forward to newer revisions, you have to spend time wrapping your head around whatever the favored build system is. When I first investigated NaCl, I think it was using vanilla GNU Make. Then it switched to SCons. Then I forgot about NaCl for about a year and when I came back, the SDK had reverted back to GNU Make. While that has been consistent, the layout of the SDK sometimes changes and a different example Makefile shows the way.

  The very latest version of the API has required me to really overhaul the Makefile and to truly understand the zen of Makefile programming. I’m even starting to grasp the relationship it has to functional programming.

  Problems With Native Client – API Versions and Chrome Bugs
  I built the original Salty Game Music Player when NaCl API version 16 was current. By the time I published the v16 version, v19 was available. I made the effort to port forward (a few APIs had superfically changed, nothing too dramatic). However, when I would experiment with this new player, I would see intermittent problems on my Windows 7 desktop. Because of this, I was hesitant to make a new player release.

  Around the end of May, I started getting bug reports from site users that their Chrome browsers weren’t allowing them to activate the Salty Game Music Player — the upshot was that they couldn’t play music unless they manually flipped a setting in their browser configuration. It turns out that Chrome 27 introduced a bug that caused this problem. Not only that, but my player was one of only 2 known NaCl apps that used the problematic feature (the other was developed by the Google engineer who entered the bug).

  After feeling negligent for a long while about not doing anything to fix the bug, I made a concerted and creative effort to work around the bug and pushed out a new version of the player (based on API v25). My effort didn’t work and I had to roll it back somewhat (but still using the new player binaries). The bug was something that I couldn’t work around. However, at about the same time that I was attempting to do this, Google was rolling out Chrome 28 which fixed the bug, rendering my worry and effort moot.

  Problems With Native Client – Still Not In The Clear
  I felt reasonably secure about releasing the updated player since I couldn’t make my aforementioned problem occur on my Windows 7 setup anymore. I actually have a written test plan for this player, believe it or not. However, I quickly started receiving new bug reports from Windows users. Mostly, these are Windows 8 users. The player basically doesn’t work at all for them now. One user reports the problem on Windows 7 (and another on Windows 2008 Server, I think). But I can’t see it.

  I have a theory about what might be going wrong, but of course I’ll need to test it, and determine how to fix it.

  Database Difficulties
  The player is only half of the site ; the other half is the organization of music files. Working on this project has repeatedly reminded me of my fundamental lack of skill concerning databases. I have a ‘production’ database– now I’m afraid to do anything with it for fear of messing it up. It’s an an SQLite3 database, so it’s easy to make backups and to create a copy in order to test and debug a new script. Still, I feel like I’m missing an entire career path worth of database best practices.

  There is also the matter of ongoing database maintenance. There are graphical frontends for SQLite3 which make casual updates easier and obviate the need for anything more sophisticated (like a custom web app). However, I have a slightly more complicated database entry task that I fear will require, well, a custom web app in order to smoothly process hundreds, if not thousands of new song files (which have quirks which prohibit the easy mass processing I have been able to get away with so far).

  Going Forward
  I remain hopeful that I’ll gradually overcome these difficulties. I still love this project and I have received nothing but positive feedback over the past year (modulo the assorted recommendations that I port the entire player to pure JavaScript).

  You would think I would learn a lesson about building anything on top of a Google platform in the future, especially Native Client. Despite all this, I have another NaCl project planned.