Jump to content

All Activity

This stream auto-updates     

  1. Yesterday
  2. CCLP4 (MS) 68: [983] (+3, b+1) [Cold Fusion Reactor] Route is worth [984] and I will score it eventually, but for now I want to just get this in. 6,111,210 (146 bolds) CCLP4 (Lynx) 68: [965] (+2, b-1, pc) [Cold Fusion Reactor]
  3. How do I run it? I've extracted the jar file but what next?
  4. CC2: 46 (LONG LOST FRIEND): 27180 (+110, b+90) | 418 (+11, b+9) total score: 14,534,261 total time: 37,462 and now J.B.'s in second 🌞
  5. CC2: 143 (CAVERNS): 74740 (+50, b+10) | 324 (+5, b+1) 155 (VENICE): 85710 (+60, b) | 821 (+6, b) total score: 14,534,151 total time: 37,451 This makes me tied for first in time bold count
  6. Last week
  7. CCLP4 (MS) 107: [889] (+10, bc) [Combinations] 6,111,210 (145 bolds) CCLP4 (Lynx) 107: [884] (+9, bc) [Combinations]
  8. CC1 (MS) #23 (BLOBNET): 426 (+20, b-10, m-18) #24 (OORTO GELD): 430 (+2, b) #89 (BLOCK BUSTER): 365 (b-37) #94 (NOW YOU SEE IT): [906] (+87, b) #110 (CHILLER): 276 (b) #127 (SKELZIE): 452 (b-2) 123 b
  9. CC1 (MS) #23 (BLOBNET): 426 (+20, b-10, m-18) #24 (OORTO GELD): 430 (+2, b) #89 (BLOCK BUSTER): 365 (b-37) #94 (NOW YOU SEE IT): [906] (+87, b) #110 (CHILLER): 276 (b) #127 (SKELZIE): 452 (b-2) 123 b
  10. CCLP1 (MS) 068: [949] (+2, bc) [Flames and Ashes] 6,006,020 (149 bolds) edit: Lynx snipe 068: [948] (+2, b+2) [Flames and Pieguy in Ashes] double edit: 068: [949] (+1, b+1) [Heated Report]
  11. pieguy

    Pieguy's scores

    CCLP1 MS #68 (Flames and Ashes): [949] (b+2)
  12. CCLXP2 #133 (Block Maze): 818 (b+3) joint bold with Jeffrey ?,???,??? - ?? b
  13. CCLXP2133: 818 (+31, b+3) [Block Maze *] (joint bold with James Anderson) edit: 131: 253 (+18, b+4) [Time Bomb LX] second edit: 143: 445 (+1, b) [Trapped]
  14. CCLP2 MS #133 (Block Maze): 834 (+2, b+2) joint bold with Jeffrey 6,050,810 (+20?) - 144 b
  15. CCLP2 (MS) 133: 834 (+2, b+2) [Block Maze] (joint bold with James Anderson) 6,047,670 (144 bolds) And with that, I'm finally in every evolution history! More importantly, 4 way tie for 1st in CCLP2 MS bold count lol CC2 045: 129 (+19, b) | 23790 (+190, b) [Middle School] 052: 181 (+13, b) | 32010 (+110, b) [Confusion] 053: 15 (+1, b) | 26650 (+10, b) [Rovers Are The Worst Creature] 095: 81 (+33, b) | 50430 (+2350, b) [Ouroboros] 098: 233 (+110, b) | 51330 (+1100, b) [Sibling Rivalry] 101: 135 (+15, b) | 51850 (+150, b) [Tank Blocker] 102: 427 (+57, b) | 57290 (+2590, b) [Obstacles] 105: 117 (+7, b) | 53670 (+70, b) [All-in-One] 107: 39 (+5, b) | 53890 (+50, b) [Wing and a Prayer] 183: 87 (+47, b) | 92370 (+470, b) [I'm an Idiot] 30,749 seconds | 14,359,254 points And a bunch of CC2 stuff. 99 time/98 score.
  16. CC2: 170 (PRACTICE TO PERFECT): 90160 (+240, b+40) | 397 (+25, b+4) total score: 14,534,041 total time: 37,440
  17. CCLP3 Lynx: #100 (Sardines): 220 (bc) #101 (The Ghosts at the Massingham Mansion): 606 (bc) #139 (Rotation): 518 (bc) #141 (Bug Arranging): 334 (b+2) #149 (Mr. McCallahan Presents): 760 (b+1) 127 b
  18. CC2: 179 (IN & OUT II): -1 | 831 (+3, b+3) total score: 14,533,801 total time: 37,415
  19. pieguy

    Pieguy's scores

    CC MS #116 (BLOCK BUSTER II): 717 (+1, nr) 5977710
  20. All sounds pretty workable. I would suggest naming the interface for movable elements "Mob", which is short for "mobile object".
  21. As soon as I wrote this, I realized the solution to the read-only Gameboard problem. I plan to make a ReadOnlyGameboard interface, which Gameboard will implement. This interface will expose only the methods which do not mutate the Gameboard state. Then the GraphicsManager will get the gameboard as a ReadOnlyGameboard.
  22. 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.) Adding new layers (thin walls, canopies, electricity) requires minimal code changes. 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.
  23. CC2: 179 (IN & OUT II): 99690 (+640, b+190) | 828 (+35, b+12) total score: 14,533,801 total time: 37,412
  24. Chip Kart View File 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. Enjoy. Submitter Hash1 Submitted 06/20/2019 Category Tilesets  
  1. Load more activity
  • Create New...