Goal: Create a virus-escaping-the-network strategic puzzler.
Team (listed alphabetically):
Tech Stack: Javascript + CraftyJS
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.
Action items:
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.
Thoughts/feedback please?
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.)
Awww yeah, we’re doing this thing.
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 have gone through the previous prototype and understood it pretty well. JavaScript truly is fascinating. There is, however, one little piece of syntax which has confused me greatly, and which no amount of googling ever shed over it any light. It is as follows:
resolveFirst = typeof resolveFirst !== 'undefined' ? resolveFirst : true;
Particularly, the usage of the question mark, and all that follows it. Everything else, alhamdulillah, is remarkably clear.
This is the “ternary operator.” It’s syntatically equivalent to:
if (typeof resolveFirst !== 'undefined') {
resolveFirst = resolveFirst;
} else {
resolveFirst = true;
}
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?
Done no.3, plan to do no.4. Made a pull request.
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.
Currently considering:
Player has 4 directions -
Right (1,0)
Left (-2,0)
Up (-1,-1)
Down (-1,1)
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?
MashaAllah tabarakallah.
We didn’t talk about this, but we need to talk about code reviews and code quality. The TL;DR version:
Code reviews are great for learning, but slow. We’re on a small-scale timeline, so let’s go with commit-first, ask-questions-later. As long as we’re open to changing code later, that should work well.
Code quality is a curve. The code should be self-explanatory (if not, add comments, but sparingly) and easy to change.
PR approved, well done!
Jazak Allahu khairan,
No.4 is done, pull request made. I do have a feeling that my code is a bit too messy.
I think that’s enough for today. I’ll take a look at the list tomorrow, insha’Allah.
So should I just commit into the master branch? I don’t know, man. whenever someone does that, bad things happen.
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:
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.
Added that tile class. I’ll see if I can’t get the win gate working.
Update: Win gate working, along with restarting the game. See previous pull request. Will work on red tiles now.
Update 2: Well, that was easy. Red tiles are ready, same pull request.
Update 3: Managed to get myself cornered.
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.
Jazak Allahu Khairan, akhi.
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?
You have some code-review things you can fix first. That shouldn’t take long.
Yes, the idea is that it’s an antivirus block with a switch; stepping on the switch deactivates that specific antivirus block.
Made the changes you wanted.
I take it that the switch tiles should have a different color? Perhaps a darker red, and yellow switches to accompany them.
