HexLife postmortem

 As the GameDev.tv Game Jam gives participants a free course, I figured I had to do something with this Jam. The theme of the jam was “Life in 2 Dimensions” so my immediate thought came to Conway’s game of Life. Life is a cellular automata simulator with a set of very simple rules for running that results in surprising results. My first change was to place the automata on a hex grid. I then added three types of life and set the rules so Red cells eat Green cells which eat Blue cells which eat Red cells. My idea was that I would have levels where you would place cells in such a way that your color would dominate the board.  I also made the decision to write the game entirely from scratch. 

What Went Right

The actual simulation aspect game together quickly and my preliminary test showed that it worked producing a rather interesting swirling effect. While the simulation is fun to play with for short bursts, and random mode makes rather interesting displays, by itself it is not really a game. My idea for a game was to have the player control one of the colors and attempt to turn the board entirely that color.  This, will be discussed in the what went wrong section.

Mixed Blessings

The decision to do the game from scratch was a good one considering I am planning to build a game engine from scratch so this would be good practice. I had not anticipated as much interruption from the real world as there was but it was good practice getting back to building everything. Had I gone with my own libraries, I would have been able to do a bit more polish on the game but as things stand it doesn’t look too bad the way that it is. While eating up a bit more time than I would have liked, creating the UI from scratch let me play around with different, and better, techniques than I have in my rather dated and overly simple SLL libraries. This will be helpful as I get further along in the book series I am working on.

What Went Wrong

While the sim as it stands has nice flashy displays, it is not quite enough to allow for good strategic design. I am sure that there are additional features and rules that could be added to allow for more strategy allowing for a challenging game, but that is not here. Unfortunately, the way the rules work make for a fairly easy way for finding solutions to win the game. I am undecided if I will revisit this game but with more rules and other features to increase the challenge of the game but that is certainly a possibility.

Final thoughts

I have been reneging on this blog, so I am thinking about taking my code for the game and cleaning it up going over the code and what I am doing to improve it. This would also result in some soapbox posts about a variety of topics. I'm not sure how often I am going to update this but may go to a fortnight format where I update  my book on Spelchan.com in one week and then post about my refactoring on this blog. I may also consider entering more game jams, depending on what my schedule is going to be like.

HexLife Beta

This is it for today and I am not sure how much time I will have Sunday and Monday, probably just Monday morning. The beta is on Spelchan.com, but there is a lot of work that needs to be done. What I want to get done before Monday’s deadline:

• More levels, as a single simple test level is not much of a campaign.
• Better title screen
• Instruction screen

What I hope to get done by Monday:

• Transition animation between generations.
• Ability to save and load levels.

What I will do after Monday’s deadline:

• Write a postmortem.
• Clean up the code. Right now, pretty smelly as I fell into the time pressure trap.

Possibly spend a few weeks going over my code (not sure if this would be here or on Spelchan.com). 

The future comes from the past

 It has been a long time since I took a break from working on my 2600 emulator. Next month I am going to return to that project. Things have changed a lot since I worked on that project so have a lot of decisions to make. Web Assembly has become a real thing and there are several good paths to using it. Kotlin is not one of them. I am trying to decide if I should port to C, or Assembly Script. I am also thinking of going with an IDE instead of just an emulator. 

The next few months will be looking at tools and technology available followed by porting my existing emulator code. From there will be a matter of finishing the emulator then possibly building an IDE around things.

Preparing for Random Assembly

In the last post we covered the basics of a linear congruential generator and the simplest form of the permuted congruential generator. Now I am going write some generic 6502 implementation of these generators. This will require covering a few topics that not been covered yet as well such as writing a simple trace utility so the results can be seen. This fortnight I will break down the topics that will be covered over the next few months.

The first step is to create a simple trace utility that will let you run some assembly language code showing the effected registers and memory as the program runs. This is the equivalent of using a debugger to single-step through the code. One alternative to this would be to use an existing emulator that contains a debugger, but there are three reasons why I am not going this route. First, a trace utility would be fun to write. Second, I ultimately want my emulator to also be an IDE so development tools like the trace would be great to have. Finally, going with the existing emulator would require writing for a specific platform which at a minimum means a bunch of boilerplate code obfuscating the code. Writing a trace utility should not take too long, probability only one or two posts.

For the pure 8 bit version of LCG we need 8-bit multiply which is something  that the 6502 does not do.  Software multiply is possible so we will look at a couple of ways of doing this before implementing our 8-bit LCG.

Before getting to the 16-bit version of LCG we will have to take a look at how to perform multibyte math and then expand my multiply routine to 16-bits which is a bit of work.

Finally we will implement the 16 bit version of LCG and the most basic version of PCG.

State of the Emulator November 2018

Now that I have finished my 6502 emulation section, it is time to decide what to do next. As I have mentioned a few times, my blog is a bit behind where I am with my work on the emulator. What I tend to do is work on the emulator writing articles as I go and then only post an article every fortnight. The reason for doing this is that I knew that my University work (I am currently enrolled in a Master of Science in Computer Science program while working part time) would be taking a lot of my time so I wanted to make sure that I would have material to post. My plan was to also have the blog follow my development down all the ratholes that it leads down. I am rethinking that now as the sound emulation took me down a really windy rathole. To make my blog a bit more coherent, I will be editing my rathole and presenting the information in a bit more structured way.

For those of you who are wondering about the state of my emulator, the graphical portion of the TIA chip has been completed. I still need to implement the sound, which has led me down the random number generation path as the TIA sound generator is based on a LFSR (Looped Feedback Shift Register). After the sound is either implemented or muted, I will be synching the TIA and 6502 chips then implementing the PIA at which point the emulator will be finished.

Before I get to the TIA, I am going to take a bit of a dive into 6502 programming and random number generation by creating several different random number generators for the 6502 and some test games for the 2600. These test games will be used to test our emulator but will likely also result in changes to the assembler I wrote as I discover issues while creating these games. For the people who are interested in creating games for the 2600, this will be a good break. For those of you who are more interested in the emulator, remember that Test Driven Development dictates that you write your tests first so I am simply following TDD principles here.

My delve into random number generation will start first with a rather in-depth look at a particular paper on the subject. This is partially because the paper does a really good job of explaining all the key concepts that are necessary for the creation of a random number generator but mostly because I am presenting the paper as part of my one of my courses so can effectively kill two birds with one stone. This will give a basis for random number generation but then we look at what can actually be done with the rather limited capabilities of the 2600. We will then look at a few techniques that have been used in games while creating one or more games that use those techniques. This will give us a test library for the emulator while also demonstrating what is necessary to create a 2600 game.

Friday the 13th

I do not like the code that I wrote and am also considering switching this project to Kotlin as my test project for that language so am going to hold of discussing it this week and instead make an announcement. On Friday the 13^th I will be updating my Spelchan.com site to have a less-ugly look. I will also be posting the first ported Blazing Games title, which will be 13² spikes.

Why that day? After all, doesn’t a horror movie franchise claim that this is an unlucky day? Well, porting games is drudge work and I consider it a horror so what better day than that. I am using Adobe Animate CC for the porting but am thinking that it really is not worth the price so will probably be switching to using direct Create.js code once I finish the games I am porting for the upcoming revision of my Flash Game Development book.

The first few games that I have ported went smoothly being easier to port than I feared yet nowhere near as easy to port as I had hoped. Animate CC converted the vector graphics and tween animations to create.js code for me, but none of the ActionScript was ported over requiring me to re-write the code myself in JavaScript. This is not overly hard as most of the Flash API has equivalent Create.js calls, but remembering to put this in front of all class scoped variables was a bit of a pain and often was the cause of any errors in the game. The speed of the games isn’t that great but I am waiting for the WebGL version of Create.js to be officially released before I start playing with that.

Some readers may have noticed that said I have finished porting several games, not just 13² spikes. My plans are to post one port a month for sure and additional posts of games when it is the appropriate occasion, (so yes, there will be a Halloween game). On Wednesdays where I have not made significant progress on my emulator, or at least don’t have new emulator topics to discuss, I will have a short progress report and apologize for my slow development time by posting another game that I ported.

My current porting plans are to finish the 10 games from my Flash book and then look at the poll results on BlazingGames.com to see what bigger series (right now One of those Weeks or Coffee Quest) is more desired then go with one of those larger projects doing smaller holiday games as appropriate. This plan is not set in stone so could change based on factors outside of my control.

Next week I will either be explaining my switch to Kotlin decision or reviewing why I think that my memory emulation code sucks. I do want to play around with emscripten but Kotlin does look like a real interesting language and may actually be a good language for tablet and web development, with work being done on a native compiler to boot. Tough decision ahead for me. See you next week.

Emulating Memory

The 2600 emulator is going to need memory. As it is based on the 6502 processor, we know that at most it has 16 bits worth of memory which is very little for modern processors. The obvious solution then is the following code:

unsigned char memory[65536];

Sadly, it is not going to be that easy. This is for several reasons. First, the 2600 used a cheaper version of the 6502 which only had 13 address lines not 16 so only 8192 bytes were addressable. Making this even worse is the fact that only 12 of these were for the cartridge, so cartridges were limited to 4096. Some of you are probably thinking, “Wait a second, Bill, weren’t there 8K, 12K, and 16K cartridges for the 2600?” Yes, there were. This leads to the real problem with the above approach.

Because of the memory restrictions of the cartridges, developers who needed more memory for increasingly complex games had to come up with ways around this. The solution that was used was several different bank-switching types of cartridges. The idea here is that a chip on the cartridge would act as a go-between giving the console different memory based on certain actions by the program. The memory management unit could detect things like reading or writing to a certain address and would use this to determine which bank of memory would be in place. This means that we are going to need to be able to know when memory is read or written to so we can handle such situations.

The next issue is the fact that cartridges were ROM. You cannot write to ROM.

As is common with common with computers, some memory is often mapped out to hardware devices so you communicate with this hardware by reading and especially writing to memory within a certain address range. This is how you set up the TIA chip for displaying things on the screen. There are a few other IO operations that also work this way (though I believe they are handled by different chips).

So emulating memory is not going to be that easy. My initial plan is to break up memory into a cartridge loader and a MMU class that can be overridden to support several types of bank-switching schemes. The cartridge loader would be responsible for determining which MMU to use and then giving the MMU the ROM data. There could be different cartridge loaders as well, and I plan on having two. The first would be a very basic file-based loader that would be used during development and would simply load the ROM file from the hard drive. Emscripten, the tool that I am using to compile C++ into asm.js, does let you load files but does so using a virtual file system. This is a bit of a pain so another cartridge loader which would be more web-friendly and be designed to so that I don’t need to deal with virtual file systems to change cartridges on a web page.

This project is being developed relatively live. This means that I am writing this as I work on the project. I am hoping I can get a few articles ahead of what I am posting but do want to keep what I post on this blog accurate to what I am going through as I develop this project so that readers can learn from both my successes and my failures. Tonight I am going to start coding and hopefully next post we will finally start seeing some of the code.

Emulator Project Starting

I have decided that I am going to attempt to allocate a few hours every Wednesday to work on a homebrew project. While going back to my NES RPG would probably be a popular choice, the 2600Dragons.com project that I did for university has me interested in creating my own emulator. I know that there are many emulators available for pretty much any old system that you can think of so the work here is not really needed. Moreover, the emulators available tend to be pretty well written. Still, creating an emulator from scratch would be a very entertaining project.

My choices for target platforms would obviously be the Atari 2600, the NES, or a custom 8-bit console that I created just for the sake of creating an original emulator. Depending on what happens with my Masters degree, a variant of the third choice may be what ultimately happens but for now I am thinking of writing a JavaScript 2600 emulator. I have already created a rough simulator for the TIA chip, though it does need more work. It is the easiest of the three options to work on, and much of the work here can be translated to the other two ideas if it ever proves successful.

JavaScript is not the best choice of languages for creating an emulator but does have the advantage that it works on the internet. For this reason I am also considering writing the code in C and using an asm.js  compiler. Writing the emulator core library in C and compiling to JavaScript would allow me to use the core library in other C projects if I decided to go that route. I haven't used asm.js yet so this would be an interesting experiment.

The project would then be broken down into getting a memory subsystem for loading cartridges working, getting a disassembler working for disassembling the 6502 code on the cartridge into readable assembly language. Once I can get code disassembling then I can implement the emulation of the processor. Get the TIA chip emulated and add some interface code and I will have a rudimentary emulator. This sounds easy but I suspect the path will be a lot harder than I anticipate.

And yes, I do plan on creating a CoffeeQuest2600 game for the 2600 which would run in my emulator.

2015 Plans

I suppose I should be doing a postmortem of Snowman's Fez, here but since I never finished the game the way I wanted (yes, it's playable, is a game, and has a beginning and an end but it is not the game I wanted to create) I am going to instead take this time to write about my 2015 plans.

I am in the process of upgrading my degree to a bachelor degree through online/correspondence courses offered by a B.C. University. I am not entirely sure this is the best way of learning, but it is the way that most companies who are likely to hire me look for. While I would like the cheaper online alternatives to be viable, they are simply not there yet. This is unfortunate, but unlike the tech industry, change is really slow in the real world. The big disadvantage of going with University online/correspondence type courses is that you don't have the feel for what exactly the teacher is looking for so as a result you must learn much more of the material than would be necessary in the classroom. The ability to work at your own pace (within the time-limits the University puts on the courses) to me is worth the extra work learning.

There are probably many people who think that the extra flexibility means that there should be ample time to finish a game a month. To some extent this is true but knowing how easy it is to procrastinate, one has to take care not to get side-tracked on personal projects. That said, many of the courses I am taking do have some flexibility with the projects that are created. When possible I plan on doing game-related projects. This way I will get to combine my University hours with my One Game A Month hobby. This assumes, of course, that there are no issues with me doing this which I simply don't know yet.

When there are no course projects to use for 1GAM then picking an interesting game jam will be an option. Perhaps a better option would be to take one of the numerous games I want to do more with and do another pass on that game. Implementing the rather neat combat system I came up with for Snowman's Fez, for instance. If anyone reading this has a preference between those two options (original Jam stuff or enhanced existing stuff) feel free to email me with your opinions.

One project I am thinking of doing again is my NES RPG project. I would do a post in the middle of each month focusing on that project, and at the end of each month I would do a rant or a postmortem of whatever game I released for 1GAM. Email me if you are interested in this but I probably won't start doing this until March or April.

So in summary, I am going to be focused on my University work, but do plan on continuing with 1GAM. When/if possible both will be done together.