GitHub repository:Virus Escape Summary: Create a virus-escaping-the-network strategic puzzler. You navigate the grid, grabbing the gate keys to unlock the gate, while avoiding detection – you also can’t go back on tiles you already walked on.
To be clear, I’m going to help orchestrate and coordinate our efforts inshaAllah. This can be our official MO as far as communication goes; I’ll try to keep things in GitHub as far as project management (tasks to do).
Let’s focus on getting an MVP done (absolutely smallest playable version of our game) – as a reminder, everything will be coloured boxes until pretty late in the game; no tutorial, UI, etc.
Are you guys cool with the name Virus Ecape?
@Severok are you cool with making this procedural? i.e. the levels are all generated, not hand-made.
@ala Can can you clone this previous prototype on the same stack, run index.html in the browser of your choice, and poke around with the code? Ask questions please.
@rec can you please clarify what your contribution will be? Playtesting is cool too if you want something easy to do and valuable to the team.
Please review the MVP backlog here and sign up for stuff (by editing, and putting your name next to sub-items). As a safety/coordination thing, please post a comment in this thread both when you start working (explaining what you’re working on), and when you’re done – please commit/push.
Edit: I just broke out a bunch of items. There are a couple hard ones (path-finding and guaranteeing a solution) that I can work on with @Severok, inshaAllah.
Edit 2: lesson learned from the last game : it is extremely important to separate data from view. We absolutely need an internal grid representing the state of the board which is separate from the visual tiles we show. This should be be the first commit. I’ll take a crack at it later tonight if someone else doesn’t beat me to it.
Clocking in now. I’ll add the basic repo, try to establish a non-visual model (grid of classes or types of tiles), and see if I can get path-finding going so we can generate boards that are guaranteed solvable. I’ll edit this post when I clock out.
Edit: Done. We generate an empty 8x8 level, with a clear separation of the model/data (map) vs. the actual view/controller (level). Here’s how it looks.
It’s not much, but it’s enough for me to solve the hard part (generate an exit and make sure there’s at least one path to the exit). InshaAllah I’ll work on that later, I want you guys to take the helm now
Edit 2: I added QUnit and some unit tests for the map class. For future reference, please run /tests/index.html before you check in, so we know you didn’t break anything. This is all foundational stuff for the part where we have to generate a solvable puzzle. (I may limit the game to 1M or 1B possible puzzles, but I can at least then test that all of them are solvable.)
I will checkout the repo tonight Insha Allah once I have my son in bed and my wife is done shooting zombies.
Procedural is cool with me and Virus escape is fine for a working title. No need to get too committed to a name or even a theme at this stage.
Goal 1 should be in the first week making a bare-as-possible game that is fun.
We can play around with the prototype kigiggering the mechanics to see what fits and what doesn’t.
Often you would find that what feels enjoyable in concept is different to what is enjoyable in reality.
@ashes987 do you have a specific task in mind for me at this stage? IE write a functional script that generates coherent procedurally generated levels?
How much creative reign do I have at the moment?
I don’t have something specific (I’m not going to assign specific tasks unless there’s a very good reason). For now, pick something from The List and work on it inshaAllah.
Creative freedom is quite open at this stage, although I will recommend we try the approach of “here’s the idea, prototype it, no it’s no good rethink and prototype,” and recycle. The worst thing would be to work on several prototypes at the same time. (So please update the list if you have ideas, and let’s coordinate.)
Have at it.
P.S. you can use separate branches, and or config.json feature toggles, to keep separate features toggleable / easily remove them if you don’t like them.
I think the intent of this line of code was: if resolveFirst is undefined (null and not set to any value), set it to true; otherwise, leave it as-is.
You can clone the existing repo and poke it, it’s very very simple and small-scale and it should be easy to understand.
I’m not sure how well you understood/distinguished JS vs. the CraftyJS library vs. the prototyping framework, but as long as you can figure out how to Get Stuff Done, you should be able to learn and make changes as you go.
How about taking one of the tasks on the list to start?
Added a config to scale the tiles to fill the screen size for the specified # of tiles, specifically it scales against the screen height vs heightInTiles
Adding function to set actor position to center of specified tile instead of hard coding pixel positions. actor.setPos(x,y,scale) accepting the tile position + size. Essentially calls the actor.move() function with the pixel positions calculated from the provided parameters.
Gave the player an initial velocity of (1,0) and gave all the game tiles an initial velocity of (-1,0).
Playing around with the look and feel of a scrolling world instead of a static grid.
Player has 4 directions -
game world should scroll left @ 1 position/second (Add parameter to config?)
player should move @ 2 positions / second (Add parameter to config?)
Player moves with ‘Snake’ like controls allowing the player to change directions as it passes though the center of each tile moving to a new tile
new interception occurring ever half second
actual movement speeds being scaled against the players screen size.
Game world consists of a 8x32 grid constantly scrolling horizontally (8x16 is visible at any one time, the rest is held to the right of the map ready to scroll in). Puzzles consist of a series of 8x16 grids each terminating with a gate. Gate is initially closed with a set of trigger tiles needing to be touched by the player before it opens.
Player has a limited time to reach each trigger (Roughly 16 seconds / grid given the scroll).
Under the hood, as each column moves off the screen it is repositioned to the far right, when previous puzzles has been entirely shifted off screen, the next puzzle is procedurally generated and placed off screen to the right ready to scroll onto screen as the player progresses from their current puzzle.
On the far left side of the screen the tiles moving off screen become insta-kill barriers (Files being searched by the anti-virus software?), If the player falls behind too far or is unable to open the next gate in time they are caught in a searched file and deleted.
I am picturing it with more of a color-switch feel to the game-play where the player is rushed into the obstacles from the endless scroll.
It has been awhile since I last used git, so I will have to refresh myself with the syntax before I go pushing my code. @ashes can I go ahead and push a branch containing my modifications? I never feel comfortable pushing straight into the master.
Also I appear to be getting 403’d when attempting to push. Do I need permissions set to push?
Full screen is out of scope, it’s not necessary for the MVP! Oh well, too late. Feel free to commit, but try to keep it to only MVP stuff. We don’t want to go 15 days and end up without even our proper core game loop prototyped and finalized (we should get that done in the first week).
I thought about this too, thanks for actually doing it.
Scrolling world is definitely out of scope for MVP. Plus, this is something we would prototype later, after we have the actual core game done (walk around on the grid + avoid red + get green + exit). If you check the MVP, I laid out the items in chronological order to support finishing the core game loop first.
+1 for this, this is what we should work on. But I thought this is discrete motion, like tile-based? It sounds like you implemented something continuously-moving.
Rule of thumb: Magic Constants are bad (numbers interspersed in code), they should be extracted to constants. I take it a step further: they should be in config.json. I’m pretty sure @rec or @wulf will have a fun time tweaking config values to find some fun optimum.
Sounds like the core loop is done. This is interesting; I anticipated something different: a discrete tile-based puzzle, no scrolling, you move around and it gets done – as you said, less reflexes, more strategy. Cool, let’s see if it’s fun and maybe we can prototype a more “static” version later/now?
For all the hype, Git has really hard-to-remember syntax. I google things. All. The. Time.
We should actually do this, as Ala did: push to branch, open a pull-request to main. As long as you guys merge each others branches into your code fairly often (like daily), we shouldn’t get the branches diverging too much, and things will progress quickly.
Again, that workflow is:
Make some changes, test, done.
git pull --all (pull all branches)
git merge <other person's branch name>
Yes, my bad; I always screw up the permissions. Should be fixed now. Please merge ala’s changes into your branch too! What’s next for him to work on?
It’s honestly fine either way. The code is small, and you guys shouldn’t be conflicting with each other too much. For now, sure, go with your own branch but please merge Sev’s changes often if you can, so the branches don’t diverge too much.
I think the biggest problem right this second is that Severok made several changes, including the stuff you’re re-doing; so we have to figure out how to properly integrate these changes together. Can you guys please sort it out?
Your code is not messy, but leaves a lot to be desired in terms of code clarity. Removing the single-letter and double-letter variable names should be 80% of the work.
@Severok it looks like we need per-person branches. You guys probably made conflicting changes. And I think you did a whole bunch of stuff that @ala started working on piecemeal
Can you please figure this out? I don’t want to be the official branch merger that’s a horrible job and basically we just need to better coordinate changes (and push smaller changes at a time) so we don’t run into this.
Plus, @Severok please open pull requests for your changes too, at least @ala can review them and approve even if he doesn’t have any feedback on changes (although I suspect he will).
I’ll start opening PRs too for my stuff. Maybe it’s better to try review pre-commit; we can switch to post-commit if it ends up slowing us down too much without adding quality.
MashaAllah tabarakallah your work is excellent and your code is quite good.
I’m very happy you got stuck. That just proves that I was right to worry about generating “winnable” levels. That’s back on my plate now that you have the win gate and the antivirus blocks in place. (TL;DR: I plan to pathfind from the player to the gate and make sure all blocks in that one path are always free of antivirus blocks.)
You can ignore that aspect (generating winnable levels) and keep moving inshaAllah with your changes.
I think I can start working on the switch gates, but I’m not exactly sure I’ve got the right idea. They’re supposed to be the same as antivirus blocks, but de-activatable by stepping into a switch tile?