There. The tws file I've attached is all of my CC1 MS scores as of today.
I completed that set some time ago (not sure exactly when lol) and only found the tws file just yesterday, so obviously most of the scores are unoptimized I'd say, but I'll probably come back and post an update once I get around to try and improve my score.
CC Zone attachment: /applications/core/interface/file/attachment.php?id=168" data-fileExt='tws' data-fileid='168'>cc-ms.dac.tws
My name is Patrik Nilsson and I used to play Chip's Challenge as a young kid. I struggled to get past level 61. Now, nearly 25 years later, I decided to return to the game and finally finish all the 149 levels without solutions. Afterward, I began to pursue some of the easier bold times (according to the CC1 MS Easiest Bolds list) and found it rewarding. I have accumulated numerous bold times over the last couple of weeks and I thought I would play the game casually until I had bolded half of the levels. So without further ado, I would like to submit my full set of bold times (75 to be exact):
Ah, summer. Our weekends are packed. Last weekend was a Saturday mountain climbing adventure + a Sunday Father's Day celebration. This weekend is a massively compressed trip to Alaska to tour Denali National Park and go whitewater rafting. Next weekend is a 4-day trip to Indiana. And so forth.
The Unity project has not been forgotten. On the contrary almost every free moment during my weekday evenings has been going into designing and building the class infrastructure which will either make or break the project.
I've been spending a lot of time on how to ensure a clear separation of concerns. Here's what I have so far.
Gameboard
The Gameboard class is the stage on which the action takes place. The Gameboard object gets instructions on how to set itself up initially from some type of Level object. So far, it only reads CC1Level objects, which are parsed from DAT files. In the future I plan for it to be able to set itself up from CC2Level classes which will be parsed from C2M files, and eventually a 3rd level format which we have yet to define.
Gameboard objects include the time and chips counters, global states for toggles and tanks, the current replay sequence, etc. They also contain a 2D array of MapCell objects which are defined later in this post.
The most important rule here is that "A Gameboard is not a Level". This means:
You don't save Gameboard state (even for checkpoints I'm hoping to load the level up from starting position and then use a replay to get back to current state).
You don't modify Gameboard objects from any level editor. You modify Level objects, which are instructions for how to set up a Gameboard.
You don't reuse Gameboard objects. It would be error-prone to try to reset each stateful field. Instead, actions like level restart or checkpoint reload should always set a new Gameboard up from scratch.
Engine
Classes that implement the Engine interface contain a set of rules for how to modify/mutate the Gameboard object. The Engine interface defines a single method:
void call(Inputs inputs);
It is expected that normal gameplay will call this method at 60 times per second (to accommodate CC2 electricity at a later date), with the Engine incrementing a tick variable internally and filtering out ticks as needed to achieve movement ticks at the desired rate.
IMPORTANT: The Engine and everything below it (Gameboard, MapCell, Element, Level, etc) are intended to be written in pure C#, without any reference to Unity-based classes.
In theory this means that the C# code is fully decoupled from the Unity platform, which could allow a couple of advanced concepts:
Running a server that handles levels/levelsets/ratings/high scores/replays, which could potentially validate replays by running the game engine server-side.
Running a server that handles the gameplay serverside, and sends graphics updates to a browser-based implementation. (this seems far-fetched, but it's a cool idea).
MapCell
The MapCell contains all the elements that are at a given x-y coordinate on the Gameboard. As described on the Discord server, the MapCell is a hashmap. The keys are the Layer enum (Terrain, TerrainPlus, Static, Pickup, Creature), and the values are the object at the given layer. This allows for two important things:
A single object can occupy more than one layer (e.g. the green toggle bomb, which needs to occupy the Pickup layer as a green chip, but the Static layer as a green bomb.)
The MapCell is smart enough to deduplicate such items when returning its contents for processing Enter/Exit rules.
Elements
All Elements inherit from the Elem class. The Elem class is abstract and contains a lot of useful default code, mostly related to 3 concepts:
CalcMove actions. These are typically the standard testEnter, testExit, startEnter, and startExit methods that determine whether an ICreature object can enter or exit the given element.
PostMove actions. These are typically the standard finishEnter and finishExit methods that determine what happens on move completion. For MS-like engines, the PostMove actions will occur immediately after the CalcMove actions, while for Lynx-like engines, they may occur 1 or more movement ticks later.
Occupies rules. These are the layers in the MapCell (almost always just one) that an element occupies.
All moveable elements currently implement the ICreature interface (name subject to change). I'm still figuring out how this should work with the Engine for processing movement logic.
GraphicsManager
This class has read-only access to the Gameboard. (Honestly, my code isn't clean enough yet to ensure it doesn't have write access also, but that must never, ever happen! I think the answer is to use the internal keyword for methods that mutate the Gameboard, such that the Engine has access but the GraphicsManager does not.)
The graphics manager reads in the contents of the Gameboard (within the viewing window) and builds/reuses and positions Unity GameObject classes. These classes contain the bitmaps and animations needed to view the game window.
InputManager
Reads user input and supplies it to the Engine at 60Hz.
GUIManager
Handles the layout of the screen including text boxes, inventory, positioning of the game window, menus, and navigation.
Next Steps
My immediate goal is to get CCLP1 levels working with just 5 elements (Floor, Wall, Player, Chip, Exit). All other elements will be processed as a NotImplementedElement and behave as acting floors or something.
So here's a fun little tileset I've been working on. I call it Chip Kart. It's for MS mode in Tile World.
So what it is is basically a tileset where every monster is on a kart, even the tank!
Chip, of course, is also driving a kart.
Most of the rest of the tileset is like the original MS CC tileset. The differences, besides the kart drivers, are tools being special kart tires, flippers being an emergency floatie, the thief has a light blue helmet, and the exit has a checkered finish line.
To install, rename the file tiles, and paste it in Tile World's res folder, if you must replace a tiles file that was already there, you might want to make a copy of said file before you replace it.
So here's a fun little tileset I've been working on. I call it Chip Kart. It's for MS mode in Tile World.
So what it is is basically a tileset where every monster is on a kart, even the tank!
Chip, of course, is also driving a kart.
Most of the rest of the tileset is like the original MS CC tileset. The differences, besides the kart drivers, are tools being special kart tires, flippers being an emergency floatie, the thief has a light blue helmet, and the exit has a checkered finish line.
To install, rename the file tiles, and paste it in Tile World's res folder, if you must replace a tiles file that was already there, you might want to make a copy of said file before you replace it.
So, I hadn't meant to let it slip quite yet that I'm in the early stages of working on a CC-like game which will eventually (hopefully on the scale of a few months) become an open source community project. I mean, we're talking very early stages. So far I can read in CC1 levelsets and convert them into an in-memory format. And there's a sweet random number generator. That's not much. That being said, however, I've spent thousands of hours working on stuff like this (Puzzle Studio in particular), and I'm pretty confident that this project will go somewhere.
The project is unnamed so far. Every name so far doesn't seem to fit. It's not Super Tile World or Tile World 3 because Tile World is an emulation of Chip's Challenge, and this project has no intent of emulating a ruleset, but rather inventing a new one based on the best parts of old engines. It's not JBone's Challenge because I want this to be a community effort, and JBone's Challenge is really a different game I want to write (and which may eventually be branched from this). So it's just The Project or The Unity Project for now, name suggestions welcome.
Is the Unity Project open source?
The Unity Project is meant to be a community effort. I intend to release all of the C# code under an open source license of some sort, probably either the MIT or a Creative Commons license.
HOWEVER, I have a set of criteria (Phase 1) that I want the project to meet before I open source it:
The game has a new experimental ruleset which has received positive feedback from a large number of community members, particularly from the optimizer crowd.
The game can open and play any Lynx-compatible CC1 levelset.
All official levels in CCLP1, CCLXP2, CCLP3, and CCLP4 are solvable or at least are expected to be solvable (I'm certainly not going to solve all of them!) in the new ruleset. Depending on the engine it may be possible to apply an algorithm to the public TWS files to generate replays in the new engine, and then manually test the levels where that strategy doesn't work.
The game uses a forward-thinking internal level format for things like button connections, global toggle state, level size, viewing window, controls, etc. which is expected to accommodate most of the CC2 gameplay. (I would like to be able to open CC2 files and use many of the elements, but I have no intention of ensuring that all CC2 levels are solvable under the new engine.
The game has a robust testing framework.
<ul><li>
Unit tests for single elements (e.g. assert Player.testEnter(Wall) == false)
Integration tests for as many gameplay situations as we can think of (e.g. make a 3x3 level with force floors, assert that after input "URDL" the player is on square X).
Replay tests for a significant number of CCLP levels (e.g. if I apply this series of inputs to this level, gamestate == WIN_LEVEL).
</li>
</ul> Why the emphasis on backwards compatibility?
Lots of reasons!
Might sound silly, but here's one of the biggest for me:
We don't have to design a level editor until we get the core gameplay down!!!
This is HUGE! I've probably started a half-dozen CC clones in my life, and none of them got very far. Part of the reason is I didn't become a software engineer until 2 years ago. But time and time again the part that I've gotten bogged down on is how to create a freaking editor and save and load my files. If we start by loading DAT files, we have tons of gameplay testing right out of the box.
We don't have to decide on a save file format yet.
Tons of world-class content available immediately for new people.
Maximize engagement from existing community members.
<ul><li>
Level designers stay connected to their creations
Familiarity of existing levels and gameplay.
Spending time on CCLP5 submissions vs working on this doesn't have to be either/or.
Best chance of moving future community level pack design efforts away from the two-ruleset tyranny.
</li>
[*]
By setting clear definitions about what features the core gameplay must support, it allows the project to begin on a strong software engineering foundation, with a clear initial direction.
</ul> How can I help during Phase 1?
Get involved in the discussions. I'm going to have a lot of questions about things like boosting, spring step, trap behavior, etc. I'm trying to take the best parts of MS but I haven't spent a lot of time playing it.
Even though the code isn't open source I do intend to share parts of it that I'm working on for feedback.
Start learning C#. Unity tutorials will help a little bit, but I'm really just using Unity for the easy graphics and the cross platform support.
Make animated game artwork!
Make sound effects!
Start designing the new features and tiles you want to implement. It's one thing to say we want lasers, it's another to specify what they will do and exactly how they should interact with other tiles.
Playtest and aggressively look for bugs (as soon as there is something to playtest).
Keep asking for progress and showing support. This is 100x more likely to happen if the community stays enthusiastic!
