Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Alan last won the day on March 15

Alan had the most liked content!

Community Reputation

27 Excellent

About Alan

  • Rank

Personal Information

  • Location
  • Occupation
    Lead Developer
  • Website

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Alan

    Mysql Shim

    As much as I dislike the actual code here - I'm with Ian on this one - it's perfectly acceptable to run shims for considerable lengths of time - quite possibly project lifetime - to address issues of legacy code; unusual libraries etc. Those familiar with the Design Patterns book will note that are a number of patterns which can be considered shim's in their own right -- adapter, facade and proxy if memory serves me. Have a look in your vendor folder(s) ... I'll pretty much bet you'll find at least one instance of these though perhaps named differently in any current project.
  2. Alan

    MySQL JSON field type

    We have ~ 20,000 records per day of API data that needs stored - might be handy in a JSON field; while we don't specifically need to query data within it as I pre-process the data and simply cache it in long text fields; it ~may~ prove useful for future proofing. Saying that, it could be compressed; even a simple LZ compression would yield good results so a blob field possibly with a dynamically created JSON field may suffice.
  3. Alan

    MySQL JSON field type

    Oddly enough, I never considered storing API response data in a JSON field ... makes a lot of sense considering the work we do. Might have to investigate that.
  4. Any have any experience of this ? I have been experimenting with it and while it looks promising, I wonder if there are downsides that I've not encountered yet. For example; this is capable of regenerating to microsecond accuracy player attributes (energy, brave, health, will etc) stored in key-value form with a JSON definition field for each attribute. UPDATE `player_attribute` pa LEFT JOIN `attribute` a ON pa.`attribute_id` = a.`id` LEFT JOIN `player` p ON pa.`player_id` = p.`id` SET pa.`fval` = GREATEST( a.`definition`->"$.minimum", LEAST( pa.`fval` + (a.`definition`->"$.rate_per_hour" * (UNIX_TIMESTAMP(NOW(6)) - UNIX_TIMESTAMP(p.`regenerated`))) / 3600.0, a.`definition`->"$.maximum" ), p.`regenerated` = NOW(6) ) WHERE pa.`player_id` = :player_id AND a.`definition`->"$.type" = "fval" AND a.`definition`->"$.rate_per_hour" IS NOT NULL;
  5. Alan

    MakeWebGames engine?

    Slim doesn't use Whoops - that was simply an addition so that I could debug the code locally - and for whatever reason clearly my username exists validator is wonky! Mixed content - odd, never noticed that on testing; that will teach me for trying to rush something out the door. For those that cba to create an account; you can login with makewebgames/makewebgames. As for big code-bases and caching; yes, you can get decent speeds out of them, however my point was not about speed, but more about reducing the potential complexity of the code. I have multiple applications in the 4-6 million line mark all run sweetly, however with reduced frameworks, the reliance on 3rd party code is reduced (look at Node's problems with ZeroPad for example) and certainly makes for easier debugging since I'm not having to single-step through so much library code - and as can be see from above; even professional programmers make mistakes.
  6. Alan

    MakeWebGames engine?

    So can we assume we are looking for something like ... https://sandbox.node86.com ? It's very simple - running to < 600 lines of code + a small framework of just over 80,000 lines (which is I suspect far too much). Code BTW at https://git.node86.com/?p=sandbox.git;a=summary
  7. Alan

    MakeWebGames engine?

    I think my point about frameworks can still be upheld, however it probably depends on your experience with frameworks in general. Personally, I dislike full-fat frameworks as the massive amount of code that comes from a 3rd party makes for more complex debugging when something funky breaks. Take the quick-start example from Laravel - outside of the fact that the installer fails on PHP 7.2 & 7.3 as it is not quite ready for those, a line-count of PHP files suggests 230,000 lines of code before I have written anything. If you choose a lightweight framework, then that can easily drop down to < 80,000 lines. Yes, there is no question that this means a little more work on your part, but what is the aim here? Adding a couple of lines into your routing for login and register is great when we are at work and need something done in a hurry, but *how* do those controllers actually work? A clean login controller can be written in what? 12 lines or so - and with that you get ability to actually see the code that is doing the work. With light-weight frameworks you are in control, not some third party; this gives you a lot more flexibility however I'll agree it does come at the expense of actually have to learn PHP. Saying that - if you think that Laravel is the ideal starting point - go for it. I'm no expert in Laravel and I'm very willing to see how others would implement a basic core system; I'm pretty sure that given the current marketplace, that is where this project will end up in fact, however I'll stick to my guns and take the approach that actually learning the language is the target here rather than learning a specific framework. I'm certainly very interested in seeing the different approaches by people to solve this problem as each person will have their own views based on their experiences and the sharing of those experiences makes us all better programmers - I'll look forward to seeing your code. While I will be submitting code, I've no reason to think that it will be the winner here; however it may - as is its intention - give people food for thought.
  8. Alan

    MakeWebGames engine?

    @Script47, my friend, have hit the nail firmly on the head. An engine - certainly for a text-based game - should be lightweight and efficient. Bonus points for making it easy to understand and extend. Procedural, well.. that's a little old hat but still viable today though I suspect most of the grown ups are using oops (Sorry, that sounded condescending, not meant in any way). If you consider the market place (these hallowed forums), then in 3,4 or 5 years, the people that hopefully pick up this "engine" will be the next generation of programmers, so getting them on the right footing to start with is the key. @Dave MVC? PHP's never been overly good with that concept though I'm willing to be be disproved. Model, Template, Controller perhaps is sufficient. The view paradigm in PHP always seems so arse about face. $twig->render($template, $context) .. more than sufficient.
  9. Alan

    MakeWebGames engine?

    I'll just go with... Blockchain... pfft, I was writing blockchain code a *long* time ago - good for preventing rogue database admins from changing datasets. Nothing to do with currency. Prizes.. yeah gods. Last time I won a prize here - I got a full copy of Alain's NWE engine - the worlds most friggin' convoluted and standards escaping product known to mankind. Still sitting in my "must-get-around-to-it" folder.
  10. Alan

    MakeWebGames engine?

    Okay ... so what are the parameters / limitations? And how about time-frame since I know most of us are probably gainfully employed.
  11. Alan

    MakeWebGames engine?

    Good points ... I note that SRB may be noice but is not to be trusted 😄 Okay, lets gloss over the language - personally I've been programming in so many different languages that it's probably about time I wrote my own -- the grumpy compiler perhaps? Other languages are useful in that you learn tricks from them that you port to your own code; so being a cunning linguist (careful...) gives you and edge over the monosyllabic? (mono linguist) programmer. It seems we are agreed that naming conventions are unimportant - at least in respect of the project itself. So... it comes down to frameworks .. what is easy for Johnny Newb to pick up, but permits Susy Oldhand the ability to chop and change the internals at will? How about a playoff - Build a few small engines that have authentication, plus one or two *very* basic interactive modules (think crimes, or gym from mccodes), under the framework of your choice and submit those for discussion. I'm more than willing to join in at that level and I won't be using Laravel or Symphony!
  12. Alan

    MakeWebGames engine?

    /me inserts oar... I've rewritten a number of small ""engines"" over the years, and what I personally discovered was a number of things. a) Like a lot of projects, if you start arsing around deciding on the name or the framework ... you are royally fracked. You are talking about Laravel, rather than a PSR-7 compliant system, so as far as I can see, you have already shot yourself in the foot. Laravel is good, but it suffers from a number of problems. A game framework needs to look at a number of issues; there's the core command dispatching which itself needs an event listener - not a framework. Solve *that* problem, and you might be able to make something which is framework agnostic as not everybody has the capability or wish to run a Laravel based system. b) Why are still talking about PHP? There's a wealth of languages out there that are *potentially* better for a gaming project. Python being an obvious choice, though there are some other languages such as Go which may be suitable. @KyleMassacresince you replied before I could post... mm Laravel modules; see point a). Yes, I agree a modular system is a *good thing* (tm), but you have automatically tied yourself to a specific framework. Perhaps something a little more open? Okay, so I've inserted oar... so what would *I* choose? A fully PSR-7 compliant system - Laravel breaks down here as it likes to do things *its* way - And what about a DI? I seldom use the DI that is provided with a framework preferring something a little more flexible. Laravel uses a service container principal which is ... slightly smelly for those who are purists. It's a nice concept but again suffers from some odd problems which will bite you from time to time. Actually, given a choice, I'd choose Python probably using Flask or Django or perhaps Go. Heck even Perl is a decent choice assuming you can tolerate the number of £$%^&*'ing symbols. tl;dr; 1. Don't "name" the project - nobody cares what is called as long as it works (wip will suffice for instance) 2. Look at simpler, cleaner frameworks that are more generic allowing the end-user [programmer] a greater degree of flexability 3. Don;t ever trust SRB - he really does like midgets 4. Look outside of PHP, there is a lot to be gained by looking at other languages
  13. Alan

    WC: Ruthless

    ... all known errors ... 😄
  14. A little point that may be worth bearing in mind. McCodes (regardless of the version) whilst being great fun to play with and potentially worth a few bucks pocket money, is not going to be a good environment for teaching you or improving your existing PHP/SQL knowledge. The authors tried hard, but were themselves lacking in experience, thus the so-called "engine" is barely that, there is a raft of poor design decisions not to mention downright insecure code. And to make matters worse; if you look around these very forums for mods, there are very few that address any of these faults (and I include my own mods in this). Yes, you *can* make a high quality based on McCodes, but it takes a lot of work; not just in programming, you need to understand a little of how servers operate in order to address some of the more obscure bugs, and certainly a good bit of thought needs to go into how to balance the game as 95% of the games I've encountered are badly run, insecure, mismanaged. Getting some experience with McCodes is a good thing, though it may be worth also looking at few of the other small "engines" to see if you can get some ideas from those and perhaps come up with a product that takes the good points from each, and reduces the number of potential bad points.
  • Create New...