BASeCamp Programming Blog

Not generally speaking, but for any game with a large fanbase. Really, it actually kind of holds true for anything that has a large fanbase. People will always find things the complain about. The thing is, a forum for a game is more likely to become filled with people who want to bitch and complain rather than post any genuine critique.

One of the only game forums, and probably the last, given my experiences over the 6 or so months I have been a member (and from my understanding the situation is really quite the same on any game forum) that I am a member of is the Minecraftforums. I think I’m a member of the zsnes forum as well as eduke, but those don’t count as those are mature communities built up around well established older games- they don’t typically appeal to the average gamer these days. Minecraft is the only “new” game that captured my attention enough that I decided that I would join the official forums built up around it.

Now, with every update since than, people complain. Over. And Over. And Over. Mojang adds beds to the game- a useful feature for changing your spawn point in what is effectively an infinite world- people complain that it “ruins game balance”, which is a tad weird given it’s just a sandbox game, but oh well.  I’m sure people complained about the addition of sandstone in that same version, come to think of it.

The only feature I don’t really like in minecraft is the wolves; I tend to avoid them. Especially since whenever I use them they annoy the piss out of me and I end up killing them. The last time I tamed some they pushed me unto a ravine I was peering into that was floored by lava. I didn’t have to kill them that time since they piled into the ravine behind me. The reason I don’t complain about it that I really cannot think of anything that Mojang doesn’t already know. They already know the AI sucks. The only thing I can really say, and the only complains you can really find on the forum, amount to “the AI sucks” They already know that. repeating it isn’t going to get it fixed any faster, it just shows how impatient you are. Same with most new features.

Anyway, as usual there are hate threads for 1.0.0, “this should be released” “OMG how can it go from 1.8.1 to 1.0.0!” etc.

One of my responses, in this thread, pretty much summed up my thoughts on the constant complaints:

I swear to god the minecraft fanbase can be the biggest whiny bunch of entitled assholes. They add a feature, people bitch about game balance. They add a bug by accident, people accuse them of being lazy fucks. They remove that bug in the next version, people bitch that they had built mechanisms around that bug. People ask for more interesting mobs with unique abilities. They add more interesting mobs with unique abilities, and people complain that those mobs are destroying their work using that new unique ability. So they nerf that ability, and people complain that the mob is stupid now. People complain that the ores don’t have enough purposes, and then suggest that they add more. People complain about biomes being too small, so they make them bigger, and people complain that the biomes are too big and the landforms aren’t as “epic” (as if that is even quantifiable). People complain that they are spending too much time on new features and not enough time fixing bugs. They code freeze and release a few fixes, and people start bitching that they aren’t releasing enough content. Make up your fucking mind. All the while, they complain that Mojang isn’t listening the the “community” by which they actually mean Mojang isn’t listening to their personal half-baked ideas.

It’s no fucking wonder the Dev steam stays away from these forums. Any actual useful information is drowned out by the noise from people with a phd in being pretentious douchebags.

End of story right? at least three people agreed. Almost all of that is easily verifiable; All those complaints can be seen to exist in the archives and older posts. And there is no doubt that there are so many trite complaint threads that it would be impossible for anybody to sift through them to find the ones that are in fact reasonable critiques with usable suggestions/information on how to fix it. And the attitude of many of those posting such idiotic threads makes it clear they are in fact pretentious.

Imagine my surprise when I wasn’t just warned for that post, but suspended. The “warning” writes:

You made several insulting remarks towards other users. This is not acceptable.

My response essentially inquired as to where these insulting remarks were. I don’t see any. Use of swear words and foul language are there, but they aren’t used directly against anybody. The only thing remotely insulting might be the very last bit about “Any actual useful information is drowned out by the noise from people with a phd in being pretentious douchebags.” And really, nobody can argue that, either. But that is still only one instance. Unless “insult” has suddenly become a way to say “you pointed out facts that occured in the past and used them to form a coherent argument” I fail to see where this comes from.

Hilariously, all my warnings have come from people that only more recently became moderators. Not that that is really relevant, but at the same time it sort of makes sense. I know because I’ve been a moderator on a few and with that “title” you have a tendency to pay more attention to “rule-breaking”. After all, it is ones job. At the same time there is such a thing as taking it to seriously. it’s a game forum, and when somebody happens to use easily cited examples to make a point, I don’t see how that is an “insult” and I certainly didn’t insult other members directly. Unless somebody feels they are a pretentious douchebag, there is no reason for anybody to feel insulted by any of that.

Oh well. At least it fueled me to write a post.

7,196 total views, 64 views today

So, as mentioned in the previous post, I added a “sort” of scriptability to BASeBlock.

I made some tweaks, and refactored the code so it was a bit more abstracted; the original implementation was directly in the MultiTypeManager, but that didn’t really have anything to do with it, so I tweaked some of the parameters to a few methods there, added a new class with the static routines required for the needed functionality, etc. I also made it so that a “BASeBlock Script Group file” (.bbsg extension) could be used to both compile a set of files into an assembly, as well as include various other assemblies as required. Future additions will probably include the ability for each assembly to define a sort of “main” method, which can be called when the assembly is initialized.

However, once again, Serialization was the constant thorn in my side. I was able to mess about with a custom block written in a .cs script, and it even saved properly.

But the game encountered an exception when I tried to open that LevelSet; I forget the specifics, something to the tune of “failed to find assembly”  type of error. What could I do?

 SerializationBinder

What this basically meant was I was going to have to learn even more about the Serialization structure of .NET. Specifically, SerializationBinder’s. The concept was actually quite simple. You basically just derive a type from SerializationBinder, and use that as the .Binder property on a IFormatter class, overriding one method seems to be enough for the most part:

Simple! it gives you an assembly Name, a Type Name, and you simply return the appropriate type. The reason the default implementation wasn’t working was certainly as a result of the assembly being loaded dynamically, since it wasn’t [i] really [/i] being referenced by the BASeBlock assembly, so the default implementation didn’t find the “plugin” class assembly or the appropriate type, so threw an exception.

The trick here is not to enumerate the referenced assemblies, but rather to use all loaded assemblies in the current AppDomain. The general consensus with regards to using CodeDOM and compiling things like this is to compile them to their own AppDomain; however, since the assemblies were being kept “alive” for the duration of the application, that wasn’t necessary, and in this case would have complicated things. Well, it would have complicated things more than they already were.

The “AssemblyName” parameter, however, was more akin to the FullName property of the System.Reflection.Assembly; for example, BASeBlock’s assembly would (for the current version) be passed in as “BASeBlock, Version=1.4.0.0, Culture=neutral, PublicKeyToken=null”. Since we are only interested in the actual name of the assembly, we can simply grab everything up to the first comma.

Armed with the Assembly’s base name, we can start enumerating all the loaded Assemblies and looking for a match:

Then, we compare the Assembly.FullName.Split(‘,’) [0] (the text before the first comma) to the modified string, BaseAssemblyName that was changed in the same manner. I decided to go string insensitive for no reason; mostly because the assembly names for the scripts are formed from the filenames and I wouldn’t want filename capitalization to prevent a script from serializing/deserializing properly. If we find a matching assembly, we return the result of a GetType() call to that assembly with the same typename passed in as a parameter to the method. The Formatter will than attempt to deserialize the data it has to that type as needed.

There are a few issues with this- for one thing, it doesn’t work with Generic types. At least, I assume it doesn’t; I assume I would need some special code to get the appropriate Type for a generic type given type arguments. I’ll cross that bridge when I come to it.

Right now, I’ve not actually tested this extensively. My main concern would be to test that it can serialize in one session, and deserialize in another. This concern is based on the fact that the two assemblies would in that case be literally distinct- in that it would have been compiled on two occasions. Assuming the Binder is enough to convince the serializer it can deserialize something, there shouldn’t be any issues. Once I decide to figure out how to add Generics support to this Binder, I’ll definitely write about it here.

366 total views, no views today

When I first started developing BASeBlock, the basic idea was just to get a feel for how Animation, rendering, and other concepts were dealt with in C#, as opposed to the aging language I was familiar with VB6. Additionally, I wanted to make use of Threading. After getting through the initial hurdles and issues related to the type of code I would need to write with BCDodger, I had a good idea the type of things I needed for BASeBlock.

BASeBlock’s actual Game information is, not surprisingly, kept inside a instance of a “BCBlockGameState” object. There are a few folly’s in my design, whereby some elements that would probably be best placed as members of BCBlockGameState are in fact members of the main form, but everything works well as it is, and if necessary objects can get a reference to the form itself using the BCBlockGameState ClientObject property, which is a interface that defines the type of stuff that is more implementation specific than ought to be in the State instance. Rendering is managed entirely within the Paint event of the main form’s PictureBox- (and likewise for the Editor). Rendering and the actual GameProc() routine (that makes things happen) are similar; they both iterate through the various objects in the game and call methods. The GameProc() routine animates balls, GameObjects, Particles, and AnimatedBlocks; the Paint event basically iterates through all those objects and get’s them to paint on a bitmap which is them blitted to the PictureBox when necessary. Of course having these two activities on separate threads meant  that I tripped on a few things while I was getting started- not locking this variable, trying to call methods of the form from within the game loop, and other similar contention issues. All of those have been resolved, to the best of my knowledge.

Another goal while working on BASeBlock was to make it easier for the creation of new blocks. The way the older Poing game (VB6) did it was to only have a single Block object, which had an Enumeration that determined what kind of block it really was. This had the issue whereby the Block had a lot of fields that were only applicable with certain block types, and weren’t applicable at all otherwise. This was a primarily a result of the fact that VB6 isn’t really an Object Oriented Language, but rather an Object-Based Language; while you can fake Implementation Inheritance using the Implements keyword and an aggregate class, it’s a lot of boilerplate that I couldn’t be bothered with for little gain. With C#, and more importantly proper OOP constructs, I could try my hand at a more reasonable Object heirarchy.

Collections

By far one of the most annoying things to deal with in VB6 is collections. they are finicky, and more importantly, the built-in Collection class only deals with Objects, so I would have to cast variables all over the place, and casting in VB6 means actually declaring another variable of that type and using Set to attempt the assignment to perform the “cast”. The only “workaround” is to create a entirely new class that uses a Collection internally but exposes the members of that Collection as the more specific type, as well as having Strongly-Typed parameters for Addition of blocks and removal. But the creation of these classes:

• Is a gigantic pain in the ass. They are almost all exactly the same, differing only in the Type used.
• Clouds the namespace. Poing has a Levels.cls class, a Blocks.cls class, a Balls.cls class, and a few others, all for the sole purpose of representing the exact same data structure for different objects.
• Is a gigantic pain in the ass. I already said that, but I just wanted to make sure I was clear about that.
• While you can use For…Each on the collection, it’s only through non-standard coding and setting method properties that it works, and even then you have very little control since the Interface being used for Enumeration, IEnumVariant is not easily implemented in VB6, and requires literally hacking away at your Process Memory to change in-memory VTables, which wreaks havoc on the brittle IDE.

Now, thanks to my Switch-over to C#, I can just declare those variables to be List<Block> or List<Level> or List<cBall> and forget about all this special Collection class nonsense. And Of course for specific Data Structures, I can use various other Generic classes such as Stack<>, LinkedList<>, etc. Generics is a powerful feature that becomes that much more valuable when you’ve had to hoof it yourself in less powerful languages to duplicate it’s functionality.

Dynamic Loading

But, this is supposed to be about dynamic loading- and more specifically, Reflection. Visual Basic 6 sorta-kinda had reflection, in the form of a MS-provided library, tlbinfo32.dll, which essentially allowed you to inspect COM components; since VB6 produced COM components, this worked there. But it was still rather cumbersome; you were no longer looking at VB-native classes or types, but you had to interpret the appropriate parameters from the idl code. additionally, COM was often just plain stubborn. I feel that in many ways .NET tries to resolve the issues of COM, particular with regards to pluggable components. .NET allows you to, directly in your code, load a new assembly, inspect the classes and types within that assembly- see what those classes implement or derive from, and so forth. Java provides equal functionality with it’s reflection libraries, too, and  that is how a lot of java applications implement plugins, including eclipse, one of the better java IDE applications.

With C# & .NET, you can load assemblies directly from the .dll or .exe file; then you have the Assembly object, and can inspect the types of t hat Object. BASeBlock, for example, loads all the assemblies (that don’t meet an “ignore” regular expression) from it’s executable’s folder- I’ll probably change this to a unique location, to prevent the game from enumerating the assemblies I included which will never contain what it is looking for). Once it has all the assemblies, it searches for various Types that implement some of it’s types. It always inspects “itself”, so it will find all the Block derivations, iBallBehaviour implementations, iPaddleBehaviour, etc. These get added to their own LoadedTypeManager instances within the MultiTypeManager that does all the work, and this allows the BASeBlock code to easily find all the implementations of it’s various interfaces, for purposes such as showing a pop-up menu and so forth.

Originally, I wanted to add a single implementation of the appropriate interfaces and base classes,  that delegated their actions/events/etc to some sort of script interpreter/compiler. After futzing about with IronPython, however, I decided  that the object model exposed there and what I needed required a lot of plumbing code to make managable. But then I had another thought.

The CodeDOM

.NET Exposes a namespace, System.Runtime.CompilerServices that contains more namespaces, classes, and interfaces that are used for dealing with the CodeDOM; it also allows you to compile  VB.NET and C# (probably F#, but since that isn’t included in .NET 3.5, I don’t support it yet), directly into assemblies. That is when I realized I could use that functionality, paired with my existing code that finds object implementations and derived classes for an Assembly [] array, to make it possible to “script” new derived classes and implementations of those interfaces and Derivation I search for. The result turned out to be quite simple, not more than a page of code, which I added to the class that performed the Assembly enumeration. It loads new assemblies by inspecting a Scripts folder in it’s %appdata% folder, and attempting to compile those scripts into assemblies (.csx files using the C# code provider, .vb files using the VB code provider… I was going to use .vbx but that gave me flashbacks to Visual Basic 2.0 and vbx extension files. The code used to compile adds the basic references (System.Drawing, System.data.dll, etc) as well as itself, using Assembly.GetExecutingAssembly().Location- this includes the BASeBlock assembly, which is necessary since BASeBlock of course contains all the interfaces that need to be implemented, the necessary frameworks for any additional addins, etc. The script I used to test was a copy-paste of the AddBallBlock class, whose name I changed to AddBallBlockEx. Once the code compiles the new assembly and detects everything went well, that Assembly object is added to the list of Assemblies that the game will inspect for the appropriate derivations- of Block, iBallBehaviour,GamePowerUp etcetera.

After some tweaks and debug sessions, everything seemed to work fine. So far the only issue has been that AddBallBlock’s code called “AddScore” which is implemented by the Block base class, but for some reason trying to compile that resulted in the error that the symbol wasn’t defined. Absolutely no idea what is going on there… Once I resolve that issue, I’ll make the error-detection code a bit more robust and easier to get to  (for people trying to write their own scripts, or me in the future, it would be nice to have a place to find the errors issued by the compiler; perhaps it can save them in either the same scripts folder (as script.csx.errors or something) or a separate folder. As it is now, though, the test classes I created seem to be found perfectly fine; the blocks show up in the editor and the powerups can be spawned using cheats, so they seem to work well. the AddScore() issue will bother me though, but it seems to be related to the way the object heirarchy is laid out.

The main “unique” feature of BASeBlock is that it uses pure GDI+; this was because OpenGL seemed like overkill, and I needed to learn GDI+ at the time anyway. People don’t give it enough credit, honestly.

292 total views, no views today

Today, when somebody says “Video Games” people think of Disc-based formats, steam, or another distribution service; they might also think about violence and other ‘inappropriate’ material. Anyway, There used to be a time where Gaming was far less mainstream, and in many ways considered to be something of a toy use for technology. Generally, the way they were designed was to be as simplistic as possible; the entire thing was very simple to connect to a television, and switching games was as easy as removing the game and inserting another. Most early game consoles were cartridge based systems. Home Computers also experimented with the idea of Game cartridges, but eventually the lower price of things such as Floppy disks and cassette tapes for those systems made the cartridges obsolete.

For consoles, which are in many ways simply a special-purpose home computer, the cartridge based format was around for ages. There is something of a special charm, to them; they aren’t just software, and they aren’t just hardware. In many ways they were a very flexible method, particularly in those days. Many games on various systems that used the cartridge based format employed special chips to add new effects that you wouldn’t otherwise see. Without the ability to essentially change the available hardware, the games wouldn’t be able to do this. Another advantage, is that cartridge-based games are a powerful demotivator for piracy; the games, as well as the hardware has to be fully understood before one could properly attempt to make a “copy” of a game; and the fact that the game used hardware as well as software meant that a copy would often be equally expensive to produce as merely buying the game itself; not to mention that you would need an original copy to work with and examine anyway, making it a bit of a moot point. While you could, in those days, turn the actual ROM code in a game into data on a PC, the PCs and home computers of those days weren’t even close to being powerful enough to run the emulation software many old game aficionados take for granted, and those programs didn’t exist until such time as the hardware abilities of a general purpose PC were high enough to make their goals workable.

Of course cartridge-based formats have significant drawbacks, such as higher cost, more expensive to produce, the fact that, particularly with later titles, making the eye-dazzling effects that were expected of newer titles in the later days of a console required the use of expensive chips which had to exist in every cartridge, and also made things somewhat redundant, as multiple games used to the exact same chip.

I only have a Super Nintendo console and cartridges (or “Game Paks” as the official literature states), so let’s take a look at some popular and rather common games, and their innards.

Super Mario World

Fig 1:Super Mario World Cartridge

Who can forget this classic SNES title? Super Mario World was the pack-in game sold with the majority of all SNES consoles. It was, in many ways, the “Super Mario Brothers” for the Super Nintendo. Additionally, it was rather innovative, except perhaps in story. Naturally, the story is the same “Save the princess” stuff; but the game itself is far more dynamic than, say, Super Mario Brothers 3; defeating levels would often change the surrounding terrain (in purely aesthetic ways) and defeating a level would clear a path to the next one. The most interesting new feature was the introduction of entire areas that were secret and required you to find keys and their respective keyholes to access.

I personally feel it makes more “sense” than it’s predecessor (SMB3), if sense is something you can really apply to a game franchise that generally lends itself to cartoony characters, art styles, and mechanics. In any case, it tries to return to a more simple set of game mechanics. Super Mario Brothers 3 had several power ups: The Super Leaf, which turned you into a flying racoon, The ubiquitous  Fire flower, A frog suit, a tanooki(mischievous bear being the best description) suit, and a Hammer Brother Suit. Naturally these all had their own unique abilities; additionally the game added an item system, whereby you could acquire powerups and use them on the map screen before entering a level. In that manner, Super Mario World simplified many of the more complex mechanics in it’s predecessor; for powerups you had the Super Mushroom, Fire flower, and Cape feather (flying with a cape making far more sense than being able to wiggle a raccoon tail and fly). The only item system was a single item box that you could deploy within any level, and could hold one item. It also automatically fell down when mario was damaged. Additional changes involved turning directly from a powered up Mario (Fire Mario or Cape Mario) into small mario; then you could try to get the powerup that fell as a result of the hit. Additionally, the game was in many ways longer (to complete in it’s entirety) than Super Mario Brothers 3, and the game featured three battery-backed save files.

Fig. 2:Super Mario World Innards

So, what made all this possible? Surely all this excitement and awesomeness means  that that game pack is cram-packed with electronics to make it happen? Well look at Fig 2. and be disappointed if that was your expectation. It’s just a small board with four chips, and the battery to keep SRAM information alive. Note that to dissassemble these cartridges, there are a number of methods. I personally just use a Torx screwdriver set I purchased off ebay quite some  time ago.

In any case, the larger cartridge sort of hides the relative simplicity of it’s innards. Another interesting point that could be made is that in the context of a SNES system, the game pak is sort of a “add-on” card; that is, it fits in a slot on the system board, and is interacted with. In the case of the SNES, (and NES and N64) these cartridges are necessary for proper operation; otherwise you are merely greeted with a blank screen. A good analogy might to consider the game paks as something of a “system BIOS” for the game, in that they are necessary for there to be any actual executable code within the system, and they are based on ROM chips.

The primary reason for removing these “cards” from their cases would be for either investigative purposes (such as this posting) or for replacing or testing the battery. The battery is a basic CR2032 battery, the same one used in PCs for keeping track of clock and CMOS information, and much for the same purpose. They usually last a good number of years, but if your game is suddenly unable to save games or you find save corruption or issues, checking the battery is a good first step. One thing that many enthusiasts do with battery-backed save games is actually replace the battery holder with their own, that allows them to slip a battery in and out with ease. Most carts actually solder the battery on, and sometimes glue it. They weren’t designed to be user-servicable by any means (thus the special screws to open the system unit as well as game cases).

Fig. 3:Super Mario Kart

Super Mario Kart

Super Mario Kart for the SNES is the first in a long line of Mario Kart games that employ the Mario Kart characters as the cast of a Go-kart race, and use a variety of cartoony obstacles and items based on the franchise, such as banana peels, koopa shells, Invincibility stars, Coins, and so forth, as well as featuring settings from the franchise for the tracks. This  game is still extremely popular to this day, and competition for best times is still fierce. It became a “Million seller” and my first owned copy of the game was emblazoned with the “Player’s choice” logo. This copy that I purchased off ebay long after selling the original games and console are what some might call a “first run” of the game; I am unsure if there are software or hardware differences (such as bugfixes) between this and the Player’s Choice version. Nothing sticks out at me after playing the game, so I am willing to say that is not the case.

Something you may notice about this cartridge is that it seems to be designed differently from the Super Mario World cartridge. What makes this even more interesting is that it seems almost random what design a game will use. There are Super Mario World cartridges that use this “line” type design, and there are Super Mario Kart cartridges that use the smoother gradient design as seen on the Super Mario World cartridge above. I’m not really sure when, or why there is a difference. I initially suspected that maybe it was a cost issue; the cart for my previous Super Mario Kart was the recessed version, and it was newer than this one, so I suspected maybe it was a result of it using less plastic. But my Super Mario World cartridge uses the recessed variant. Also, I’ve seen all sorts of games that happen to use both designs, and I cannot find a consistent explanation, other than there maybe existing different factories that produced these that happened to use different moulds. Anyway, moving on to this games innards.

Fig. 4:Super Mario Kart Innards

Taking apart this cartridge, (results of which are shown in Fig. 4) it is clear that the game uses a larger circuit board than Super Mario World. Of interesting note is that this game also uses a special chip, known as the “DSP-1″ for advanced processing. It can be seen to the right, in the middle. This is used for the Mode 7 “split screen” that is used in the game both for single player and multiplayer. Mode 7 itself is a feature supported by the console, but the game requires a bit more horsepower to get it to work with the split screen model, thus the DSP-1 chip. The game also has Battery-backed memory for saving best times in Time Trials mode as well as what Cup’s/difficulties you have made the podium on and your place. The same sorts of information apply with regards to batteries as mentioned before. The board seems to have some sort of oscillator (not sure what that white thing is, to the right and down of the battery), which would make sense, the game does time you in hundredths of a second, so it might need that for more  accurate timing. I presume I am wrong about this assumption though.

Legend of Zelda: A Link to the Past

Fig 5: Legend of Zelda: A Link to the Past

Following in the footsteps of the wildly successful “Legend of Zelda” game released for the Nintendo Entertainment system, and abandoning many of the gameplay changes that were introduced in and shunned by many players in The second Installment for the NES, “Zelda II: Adventure of  Link” This game returns to the “overhead” perspective used in the first game, and much like Super Mario World compares to it’s franchise counterparts on the NES, this game expands on the gameplay, graphics, items, and story of the original. Story is something that is pretty interesting, the original game basically through you into a world you were unfamiliar and had you figure out what you had to do. There is still a lot of that in this game, but now it is far easier to find and get hints about where secrets lie and where to go next. This is an improvement over the first game, because I can’t stand just wandering around a dangerous world hoping I stumble upon whatever it is I am supposed to be doing. The game features things such as upgrading your sword (first at a smithy, then by way of a fat faerie (don’t ask)); and upgrading your items either by purchasing the upgrade or using a number of other methods to get those upgrades for free. Dungeons, much like the first game, feature unique items that are often critical to progress further in the game world. The game is the first in the series to introduce the now franchise-ubiquitous “piece of heart”; basically, the game has hidden Heart pieces throughout the world; finding them will restore your  HP, and for every four you increase your maximum life energy. In the previous game on the NES, you could find whole hearts in a few places, but the game didn’t have the heart piece system. Using a system whereby the hearts are found in pieces means the game has more discoverables, as well. And the much larger world basically requires that the world have plenty of discoverables and collectables to properly populate it with secrets.

Fig 6:Legend of Zelda: A Link to the Past Innards

The innards of the game can be seen in Fig 6. Because it doesn’t really use much functionality beyond what is provided by the console, it has no need of special chips. It pretty much looks exactly the same as the Super Mario World “Board”. An interesting note as to this cartridge in particular. I picked it up off of ebay, and when I first played it I pretty much went through the entire game in one sitting. However, when I returned to finish it off, I found the save missing. Upon opening it up, I found that the battery still held a good charge, but was completely disconnected from the proper circuit (the metal “holder”  that was supposed to press down on the top of the battery was in fact nearly a half centimetre away. upon remedying this situation, the game has saved fine every since. I just found it to be rather peculiar. One might note, again, the use of the different exterior design for this game as well. I swear they just did that to mess with people. Bunch of sick weirdos. I did notice that the notched versions seems to “look the same”;  that is, the inner, depressed notch seems to be analogous to the more shapely form of the other cartridges appearance (in my case, Super Mario World being one)

Fig 7: Super Metroid

Super Metroid

Arguably one of the best games available for the Super Nintendo system, Super Metroid, like Super Mario World and A Link to the past, essentially “extends” both the lore as well as the world and general mechanics of it’s franchise. In this case, it is the third game of the franchise; the first being ‘Metroid’ for the NES, and “Metroid II: Return of Samus” in which Samus, the main character, um… returns, I guess. I have no idea since I’ve not played that title.

As you can see pictures in Fig 7, Nintendo is still playing their mind games with regard to the cartridge design. The game itself also has a Battery backed save feature, so we can expect a battery when we rip it open and see if it’s insides are still fresh. I believe this game was also re-released as a “Million seller” title, but I can’t be assed to google that at the moment.

Fig 8: Super Metroid's Innards

The Innards of the game are pretty much the same as all the other games. a few chips and a battery. Very little to get too excited about. The game, being a launch title for the system, (or very close to one, anyway) doesn’t utilize any special chips as even first-party developers were still learning how to best take advantage of the relatively powerful capabilities of the SNES system itself.

Fig 9:Super Mario World 2: Yoshi's Island

Super Mario World 2:Yoshi’s Island

This game is something of a personal favourite of mine and has been for a number of years. It’s colourful presentation mixed with a bit of dark humour fridge logic (What happens to the monkeys when Yoshi swallows them?) is pretty epic. Of course it’s various advanced effects in the form of image scaling, rotation, lushly animated and coloured backgrounds and foregrounds, and so forth add to that experience. The title is sort of silly. Most people just call it  Yoshi’s Island; the actual title is too long for casual conversation. And sort of redundant, and even silly. How is it Super Mario World 2: when you specifically control Yoshi for the duration of the game. Seems like a bit of spotlight hogging on Mario’s part to me. his primary roles in this game seem to consist of sitting on Yoshi’s back lethargically, and crying inside a bubble.

Fig 9:Super Mario World 2:Yoshi's Island Innards

The insides of this game prove to be the most interesting so far, however. Yoshi’s islands various high-quality image effects are made possible by the SFX2 chip that is built into the cartridge (the square one in the middle-right). The cartridge also features two additional “tabs” which connect to slots in the console that weren’t usually used. Why? for moar power, obviously. The game also features the battery-backed save feature which of course means it has a battery. The SFX2 was one of the latest add-on chips used with the SNES, and as in fact the second version of the SFX chip, which was used with Starfox. In that regard it could be used for 3-D effects. Yoshi’s Island does indeed use a few of these 3-D effects for some platforms and objects, and it does so rather well. Capcom created a similar chip, the Cx4 chip, which has a more limited feature set and works exclusively with wireframes.  This was used in Megaman X2 and Megaman X3 for various boss fights and whatnot.

Super Mario RPG

Super Mario RPG

Here is another Wonderful game. The best way to explain Super Mario RPG would be that it is the gameplay mechanics of Final Fantasy mixed with a Story, characters, and graphical style that fits into the Super Mario Universe (which incidentally is probably the name of the Mario game to be released on the next console, after all we’ve go Super Mario Land, Super Mario World, Super Mario Galaxy, it’s the next logical step) Anyway this game is the result of a joint effort between Squaresoft and Nintendo. The result is unique and has appeal to fans of both companies games.

Super Mario RPG Innards

The Innards of the game are revealing; note that this game also uses the extra tabs in the cartridge slot. Some might guess “ah, so it has the SFX/SFX2 chip” Well, no. Many games with extra chips utilized the full cart connection. In this case, he game actually has the SA-1 chip, which can be best considered an “overdrive” chip, that speeds pretty much everything up. That isn’t a precise definition but that is the jist of it. We see once again the Battery, indicating a Save feature. And- that’s pretty much it. the SA-1 chip, a few ROM chips, and that’s it.

Conclusion

What did we learn? well, possibly not a lot, possibly a lot, I don’t know. In any case, the Cartridge based format is fairly interesting, because it arose both as a result of market conditions as well as to curb the cost of installing things like disk drives and the like into various consoles; additionally, before that many games were “solid state”; for example, the Magnavox oddysey, which was basically two player-controlled squares that could be moved around the screen. You had to use your imagination to make it into a game. The entire machine was hard-wired.

later machines were “programmable”, example being for example the Atari machine, which used what it called a “game cassette”; you had the system, and you chose a game by simply plonking your appropriate game cassette in it. This technology prevailed for many years. Nintendo in particular held fast to cartridges longer than many other companies.

For a time, cartridges were really the only route to go; any other form generally meant magnetic media which meant mechanical drives in each system, which were prone to failure. This also presented the problem of making the games something that could be copied, which was rather rampant at the time and was something the game creators would have liked to avoid. Later, when Optical media was coming to the fore, it was a matter of trade-offs; the price for the optical media was far less than manufacturing cartridges, and it had a lot more storage space (whereas with a cartridge you would need to buy more ROM chips to hold more data). The Sony Playstation was the first console to really storm the market with it’s Optical drive; in those days CD-ROM drives were becoming something of an enigma and were the “cool and techno” type thing, so the Sony Playstation really reflected the pinnacle of entertainment systems at that time. Additionally, it featured a 32-bit processor, which was faster than either the SNES or the Genesis/Megadrive.

Sega responded by introducing first the Sega CD attachment for it’s Genesis/megadrive, than by releasing the Sega Saturn. These were both comparative flops. Nintendo made the surprising move of sticking with the cartridge based format for it’s new console, the “Ultra 64″ which would be known as the Nintendo 64. This meant that the two systems (the playstation and the N64) had distinct disadvantages and advantages; the N64 had literally zero load time, but at the same time most of it’s textures were washed out; on the other hand, the Playstation lacked any sort of processing of it’s textures, but the N64′s extra processing power (in the form of the Graphics chip) was able to filter the otherwise low resolution textures, so you didn’t have low resolution textures all pixellated and stretched on a large object. If you pay attention, you’ll notice also that a lot of N64 games have the main character with very few textures; Mario in Mario 64 for example is predominantly solid-coloured and has no texture at all, merely vertex colours that are goraud shaded by the console. The playstation of course had it’s load time, but it also meant that games could be loaded on several discs; at the same time, because most code had to be loaded into the playstation’s memory before executing, this often meant less memory for the game itself, depending on how much it loaded. Nintendo finally accepted the Optical drive with the gamecube, but it made the disc spin the opposite way (to prevent piracy, or something I guess).

Every system since has used Optical disks; moving from CD-ROMs in the playstation, to Blu-Ray DVDs in the case of the PS3… (I think). And now consoles even have hard drives! They are really almost the exact same as a specially designed PC.

1,234 total views, 6 views today

Well, I removed the Bidvertiser ads. They were everywhere and all over the page and extremely annoying. And I got zilch. Definitely feel taken advantage of.

I’m going to try other networks. I’d stick with adsense, but their ads don’t show for me; I guess they blocked me. Would have been great to have received some information about that, but oh well. With any luck I’ll be able to at least make enough to keep the site alive. 3 dollars a month cant be too much to ask from the advertisements. So the site is back to being “ad free” for a short while.

256 total views, no views today