Yeah, just a basic colour difference so it’s obvious it’s not the same as the red ones. No need for anything fancy since this is still a prototype.
One of the better puzzles I’ve found so far. The grey-ish tiles are activated switches, and the purple-ish ones are deactivated switch gates.
Oh, by the way, switches and switch gates are done.
Don’t you think we should finally merge the pull request? It has been there for a while now. I’ll merge it later, if you don’t mind. Never mind, I saw your comments.
1 Like
This has to be sustainable. I work 9-5 as a developer, plus I have kids running around at home, so my hours will generally be after-Isha or after-Fajr. I can try to squeeze in code reviews at work if I get a chance, but don’t count on it.
If you find the code reviews are slowing you down, let me know and we can try to improve that. Or, try branching and see if that allows you to keep working.
Code reviews are just as good as it gets, you don’t have to worry about that.
Speaking of which, fixed previously talked about condition and added timer. Only a handful of things left in the list!
1 Like
Sorry for the delay, went to go check out a local hackerspace last night.
Saw some pretty cool stuff, laser cutters, 3d printers, tonnes of tools and scrap to salvage for projects.
Anyway back in the saddle now. Mashallah you too are working way faster than I expected.
@Ashes the code base looks way more solid than anything we have used in the past, excellent work.
@PythonWantsBoop great work so far with the puzzle gen and switches
Rather than even considering trying to merge my code into what you have built I would rather pull the current version and reapply my changes to a fresh branch. Should be considerably less work overall to pull it together later.
What I am imagining here right now is a more path-finding puzzle orientated implementation of ashes colour swap idea with a balance of reflex and puzzle aspects.
If I may, I would like to take the puzzle generation functionality we have now and throw it into my scrolling grid prototype, replace the randomly placed gate with a repeatable placed gate on the middle of the right wall on each room with the player entering each puzzle from the left side of the area from the previous puzzle.
Once I have that done and pushed I would like to look into the procedural generation of puzzles since that is the biggest remaining point in our MVP list.
I could look at procedurally generating the puzzles to ensure we only get levels generated with solutions.
My approach will likely follow the plan:
- Place N triggers randomly around the grid (N = Roof(Level #/2), maximum of 4)
- Player start point = (0,4)
- Exit gate point = (15,4)
- Path finding algorithm from Start -> closest trigger (Branch generate 3 solutions, pick 1 at random, mark tiles used in this path)
- Path find current trigger -> next trigger (Repeat, not allowing existing tiles to be used)
- path find final trigger -> gate (again, only allowing fresh tile selections)
- place hazard tiles randomly around puzzle grid in locations not previously selected by pathing.
You can go ahead and review my new pull request before merging and pulling. Just to make sure we’re on the same commit.
Will do. Are you working on the master branch still?
Git is reporting that I am up to date.
A quick note about the code that I did pull about half an hour ago.
Code appeared to fail on start.
The index file was calling source with incorrect filenames.
- Index file called file names with capitalisation, IE: ‘winGate.js’ while the file name was ‘wingate.js’
I also just noticed that the MVP does not seem to have the requirement of marking previously visited tiles as hazardous.
Will this be included at this stage?
Hmm, I did rename the files, though.
To be honest, setting previously walked tiles as unwalkable is as easy as one single line. Making them hazardous is a bit more codier, but by no means difficult.
Sooo, it could be included. If you want.
Lets hold on that for the moment,
I would love to see how the current implementation feels with a scrolling stage.
I tend to freestyle code at this stage of development to get a feel for what mechanics work and how much development would be involved in different paths, much to the perpetual annoyance of our courageous leader.
So I will keep to my own branch ‘Severok’ to avoid stepping on anyones toes.
I guess I’ll just have to revert the index.html file. I can’t seem to get them to rename in github.
Anywho, now that I’m pretty much out of things to do, I guess I’ll follow suit and experiment as well.
I have a side scrolling, infinitely long grid.
As objects move off screen to the left, they are repositioned at the right (actor.x = width * widthInTiles).
The pending objects off screen are easily long enough to accommodate the placement of fresh puzzles before they scroll in.
Player moves with snake controls, though is not locked down to discrete lines across the center of tiles. Not sure if this will need to be fixed or not. We could just roll with this as is.
2 things that I am considering might want a change:
- Replace the existing coloured objects with a re-colouring of the tiles they are attached to, IE instead of a green square on a tile for an exit, we could re-colour that tile green when it is selected to house the exit location
- Replace the existing discreet position system with collision events, that trigger callbacks specific to the object type.
Current bugs in my prototype:
- regular stretched tile placement (Possible overlapping tiles) every 32 or so placements
- objects do not respawn off-screen due to their sprite-width being considerably smaller. Resolvable by recolouring tiles instead of placing objects on top of.
- Objects do not interact with player position, temporarily disconnected player placement function in favor of continuous movement. Resolvable by setting up object collision between player and tiles.
This deserves a massive LOL and a +100. This. I couldn’t have said it better myself. I like to think of it as a healthy tension and difference of viewpoints 
Since you guys, especially together, work much, much faster than me, I’ll do my job and get out of the way (as a developer) and put on my project manager hat.
As a project manager, I will remind you guys that our goal is to prototype, and figure out a core mechanic to use; flipping features on and off is extremely important at this stage, as is communicating what we’re working on.
Hence, I would suggest the following:
- Stick to using Git sub-items to log stuff, but please add a bunch of sub-items for ideas and things you want to work on
- Please add a sub-item for each bug you find. These are good fodder for people like me who work in 30-60 minute increments and just want something small to fix.
- Try to put every single feature behind an on/off toggle. We’re prototyping. If we don’t like something, flip the switch and move on; no need to remove code.
- Agree with making previous tiles hazards. As always, add a sub-item and a feature toggle as you go please.
- Renaming files in Git on Windows sucks. The work around I use is three step: 1) rename the file to something else (eg.
INDEX.html=>foo.bar) and commit; 2) rename it back, fixing the case (eg.foo.bar=>index.html); 3) squash the last two commits. - Agree with changing tiles instead of modeling it as objects on tiles. That was always my idea (tile state, not tile contents).
So to summarize: add line items, put stuff behind feature flags, and onward and forward!!!
@ala can take 99% of the credit for that. But, I learned some lessons since we worked together last; I realize that code quality is extremely important (even in throwaway prototypes and monthly games) and that unit-testability is really important too. So I prioritized those goals this time.
If I get a chance, I’ll try to add unit tests to the pathfinding to see if I can figure out how to generate guaranteed-solvable solutions. You guys can leave that to me.
Hey everyone!
I was reading through your threads @ashes987, and mashallah, you are very motivated and passionate!
I just started teaching myself Unity, from not being able to code at all, about 2 weeks ago. I don’t think I am knowledgeable enough yet to help you guys with your project, but I was wondering if any of you have experience with Unity and if I can ask you guys questions when I eventually have them?
Unity uses C#, so I am teaching myself that too.
Had a quick moment during my lunch break today so I grabbed a copy of our code base and threw together a quick diagram showing inheritance of our objects.
You may or may not find it to be a handy reference, but I appreciate a good chart.
Took me 10 minutes to throw together and will Insha Allah save me at least 10 minutes in the future flicking between files to check functions.
Blue squares show objects, Orange shows functions attached to that object.
Just locate the object you are working with, you can see what it is inheriting from and what functions should be available for you to call.
IE; The Player requires TileEntity which requires Actor which requires Common.
As such the Player object is able to call functions such as moved(), velocity(), die() etc.
1 Like
Never got the hang of C# I am afraid.
I have considered giving it another shot since it seems to get used a lot in web-page back-code.
What do you mean by “Git sub-items”?
Done number 4, and 6.
In the checklist right?
Like group tasks together in categories instead of starting a new item for every task.
In the MVP issue in GitHub?
I’d say so. Though we would probably establish a ‘save point’ of our work once we have finished the MVP, then start a new checklist for how we are going to enhance the MVP into a more developed game. Essentially we should have a check list for each phase of development with a backup of our work at each point of completion.
Once we have finished that we can establish the next save point and get some beta testing going as we balance the game, fix bugs and start to develop the art assets.
Moving forward as we decide on what needs to be worked on we will need to keep our goals organized.
- Well grouped
- Short and achievable goals.
- Build the game in such away that on the completion of each objective the game is in a shippable state. If the project gets hit by the proverbial bus we can still revert back to the previous version for shipping.
1 Like
Ah yes, the same methodology in that article ashes posted. I’ve read it.
1 Like