Jump to content

Joshua Bone

Members
  • Content Count

    86
  • Joined

  • Last visited

  • Days Won

    11

Joshua Bone last won the day on June 19

Joshua Bone had the most liked content!

Community Reputation

21 Paramecium

About Joshua Bone

  • Rank
    CASTLE MOAT
  • Birthday 01/23/1984

Contact Methods

  • Skype
    joshua.bone99

Country

  • Country
    United States

Profile Information

  • Location
    Seattle, Washington
  • Favourite Set
    CC2

Recent Profile Visitors

840 profile views
  1. 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.
  2. 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.
  3. Good idea. We may get there eventually. For now the #community-projects and #programming channels in CCZone are the main places for discussion.
  4. 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. 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). 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. 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. 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. 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!
  5. Added an old Create Comp level 'HOW TO ITEM DROP LIKE A CHAMP' to "Last Minute CC2LP2 Submissions".
  6. Submitting NOEN CHEOC, a new level uploaded to the set "Last Minute CC2LP2 Submissions". Per Chipster suggestion, also submitting the following levels from CC2Rejects: Open, Sesame Railroad Sabotage Terrorism Parallel Dimension Trail Mix Road Block Pollution Triple Play Tank Crossing Glacier Facility Against Your Will HSM Titanic Glacier 2 Dumbell Insanity It Takes Two Cannon Fodder Chip's Blunder
  7. Version 1.0.2

    6 downloads

    A place for last-minute CC2LP2 submissions. One level so far.
  8. Per a request from Mobius, I submit the level THAT FIGURES from CC2Rejects
  9. I submit all levels in Walls of Chip's Challenge 1.4.0 except for MULTICHIP, which is busted. I also submit EXTRACTION and OPTIMAZE from JBoneMisfits 1.0.0.
  10. Thanks for the feedback, I'll definitely update the time limit on The Golden Key.
  11. And then I had to go and design DUNGEON QUEST I agree with this point, but also think there are plenty of creative and non-violent ideas for tools that can destroy/remove monsters. I agree I wouldn't want Chip to have a sword or a gun or anything like that, but I think TNT and bowling balls are awesome, and it might be nice to have standard cherry bombs that were droppable. Lasers turrets would be awesome too. Or a 'freeze' gun.
  12. False--nothing is worth waiting a year and a half for. What really happens inside a transmogrifier?
  13. I reorganized the level order in 1.4.0 to be loosely based on increasing difficulty rather than original level order, so that's intended :). Thanks for the feedback too, very helpful as always. The walkers areas on SALMON RUN were designed to require basically no dodging skill to solve, coming as late in the level as they do. I actually was just looking to fill space at that point after a really complicated level. I played through the level again recently just to make sure and I still feel like they are fairly placed. My rule of thumb (usually, but not always followed) is that 'gratuitous' late-game dodging and puzzles on long levels should be solvable close to 100% of the time on the first try by an average player. In this case it should be obvious what needs to be done in both rooms, and it should be almost trivial to execute. If that's not the experience I'd love to hear what makes them difficult. ONE LESS'N BEFORE is nothing glitchy, just standard CC mechanics plus a single well-known CC2 ability. FF behavior in the Steam engine makes it a little tricky to execute, but I can pull it off almost every try. I think altering player position and editor peeks in general fall into the same category. Ultimately it's up to the player how they want to experience the game. Some levels could be absolutely ruined by this; in others, it's a harmless way to get past a single difficult section. I don't mind it. On MY MOTHER SAYS the rest of the level after the opening puzzle was honestly pretty much just filler. Glad to know it's enjoyable filler :). The opening puzzle is surprisingly hard, and was one of those 'I wonder if this is possible' designs that turned into a puzzle that seems to fit the space perfectly.
  14. No prob! It'll be nice if the community can build up a library of useful things like this that can then be used for interesting level designs, so it's not a matter of trying to figure everything out from scratch.
×
×
  • Create New...