Those top angled slopes to the right of the screenshot, and their opposites, are the last ones I need to sort out.
Anyway, I had about five hours of sleep for the last two nights and I’ve been up since half 9 today, so after 17 hours of ignoring sleep deprivation like a boss I’m gonna hop into bed, then carry on with these tile definitions tomorrow.
Another fantastic evening spent with JavaScript and SAT.
Fixed some weird issues with my restrainer/constrainer (still can’t settle on what it should be called) by ensuring that nothing happens if there isn’t actually an overlap, despite SAT.js coming back with a response.
Also, look at all the shapes! Look at them! Beautiful!
This is starting to get reeeeeally tight. My SAT restrainer/constrainer thing is doing a really good job of stopping separation on unwanted axis. The only pain is defining all the possible combinations of neighbouring tiles.
Lately I’ve been making my return to game development, working on a game my girlfriend and I have devised under the working title “Solis”. Maybe this means I’ll finally get round to using texture packer one day.
I’ve been building a plugin for Phaser that introduces sloped tiles to its Arcade Physics engine, something that I couldn’t really find amazing solutions for in many places. I resorted to using the Separating Axis Theorem, specifically the amazing SAT.js.
Thing is, to keep it feeling “arcade” you really need a way to keep the player on the slope, and I’m trying to find out how much of this the plugin can provide without getting specific to any particular game/implementation. So far I’ve tested a decent theory for separating only on the Y axis to prevent sliding down the slope, but of course leaping sliding off slopes is totally possible with high velocity.
Tightly coupled software is like a product that requires other proprietary products
If you’re writing a library, try your best to decouple it from any other libraries. This has always been best practice.
Wherever you can, try not to force your users to use the equivalent of some unique proprietary cable that is required to charge a laptop, for example. Separate your library into components as much as it makes sense to and as much as you can bring yourself to.
Separation makes your software easier to test in isolation - yes, you definitely want this - and easier to maintain.
While this is something that’s preached over and over in the software development world, I think it deserves to also be said that it’s okay to have coupling, to push the idea of cohesion.
“Yes, I recognise this problem as two separate problems... that concern each other.” It’s important to recognise separate components that do a better job when used together. How they interact with each other is the important decision to make.
I stumbled across this issue while writing a router for my CMS framework. There is a clear distinction between the jobs of routing a request to some set of variables, and then using these variables to invoke methods and other magic things that return a response. But what use are these things individually?
While I haven’t begun to separate them again yet (before, they were separated but not in the best way), I know that I shouldn’t feel bad about having one hard-coded to rely on a default implementation of another, because it can always be replaced.
Before, my dipatcher required a router. I look back on this and understand that it’s backwards. Dispatching doesn’t happen first. I look at the problem now and think that a router should use a default dispatcher implementation (that exposes filters for matching callable routes if need be) and have said dispatcher overridden at instantiation if at all necessary.
I also look back on it and think, what was really that wrong about what I was doing? The dispatcher had exactly that; access to the router it needed. Instead of having to expose filters it could just assign them. Maybe I just preferred seeing “$router” and “Router” instead of “$dispatcher” and “Dispatcher”.
Software will always be a mess, but this post documents part of my several year long attempt at finding the best ways to minimise this mess.
I think it’s a good idea to challenge yourself, to better yourself with something that pushes what you think you’re capable of.
How do I do that? Check it out on Github. I’m building a PHP framework that lets me build websites the way I want to, really easily. I’m a long way from being finished (only version 0.4.0 has been released) but it’s become a very important part of my life, quite naturally.
Things I miss working on are my multiplayer HTML5 game, drum and bass production and Dragon Ball Online Revelations, but I’m sure I’ll find time for those too, eventually.
For the past week or so I've been working on an obfuscation solution for the company I work for; they no longer want to rely on ZendGuard. It reminded me of the compilers course at university. It's weirdly satisfying working with abstract syntax trees of the same language you're writing in.
Hopefully my solution is unpleasant enough to deter the majority of reverse engineering attempts.
Lately I’ve been working quite a lot on decoupling the components in this framework I’m building, and I’ve just got to a point where I could consider a small set of its well decoupled classes as a couple of components that can sit in their own repositories.
I’m going to be taking this bundle of /core/*everything* joy and component-ising everything it’s become, open sourcing each component as they become adequately decoupled. Of course there will be sensible dependencies on things where necessary, namely my Request and Response classes for handling HTTP requests and responses.
These two classes could depend on the Symfony 2 HttpFoundation component for some super useful functionality, but I thought I’d try to keep it all from scratch, and as simple as I can make it without it being detrimental to the key functionality.
It’s nice to also know restraint when it comes to decoupling. You also need cohesion; some classes just need to work together, like my Dispatcher needs a Router, like the Router needs to know about HTTP requests and responses. But that’s it. Part of me thinks about merging the entire dispatch logic back into the Router again but I’m still not sure…
Something nice is that this routing component doesn’t need to know about views or anything else like that, it just needs to route and handle HTTP requests and responses. Reading the Laravel source, even though it can sometimes be difficult to follow, has been very helpful to me in this respect.
Using __toString() on views when setting response content instead of checking for an instance of ViewInterface… that idea, that pattern was what allowed me to finally completely decouple the routing classes in terms of their hard dependencies. A remaining problem is that my Dispatcher still tries hard-coded methods on controllers for before and after hooks instead of using something like an event dispatcher. That’s all for another time.
I’m currently waiting for the owner of github.com/darya to get back to me after the Github support team sending them a message on my behalf regarding this project and why I’d like to secure that URL.
I’m very excited about open sourcing my own PHP for the first time, especially about being confident enough to do so and willing to embrace critique and suggestions.
Since the first of day of July I've been working for Claromentis as a PHP developer, mostly helping to build and improve the core of their 15 year old intranet software. It's been a lovely experience so far and I hope my contributions continue to benefit them as a team and as a business.
This has, however, left me much less time for game development or music production, yet somehow supercharged my desire to work on what I now call Darya, a content management system (CMS) framework that will become open source once I'm proud enough of it.
I've been working on it for a long time now (well over a year for sure), and most of this time has been spent refactoring as I've continually learned more about how frameworks like Laravel and Symfony work.
Why not use one of these frameworks, you ask? Why needlessly reinvent the wheel? Simply because I enjoy learning and have too much curiosity not to try it out myself. I love the idea of having built my own quality code-base for building websites. I'm fascinated by this Router->Dispatcher->Controller->Model->View process and seeing it through, in my own way, completely from scratch.
Everyone seems to say "use a framework." Yeah, it could save me a huge amount of time, but they're generally not aimed at content management, and CMS frameworks out there based on Laravel, or whatever, likely won't work the way I want them to. Ultimately, time isn't a problem for me here though. The goal is to learn.
Perhaps this is over-engineering to the highest degree, seeing as my Dad just wanted a new website but I've taken it as an opportunity to learn a tonne about quality web programming and build something that I'll likely be able to reuse to build anyone's site.
That's the worst thing about over-engineering though, isn't it? Thinking you'll find a solution that will work for everyone, when in fact no such solution exists.
Hey, it's using unstyled tables at the moment but at least it's outputting what I want. I feel a bit dumb making this stuff rely on a class comprising almost entirely of static functions; it'll be object-oriented eventually for sure.
Perhaps eventually I'll be able to provide an API for everyone to use; free and easy Brighton bus times for everyone, even developers. Now wouldn't that be nice? :)
Logical Obsession @logicalobsession - Tumblr Blog | Tumgag
turnnoffyourmind
2087
origamiaround
jacobvanloon
blakekathryn
izzy806
areudirty
tangentwithtanner
stormborns