Alan

My learned friend above is quite right; using PHP Storm can be a lifesaver in reducing the number of bugs reaching production; although I'd still point out that testing is ultimately key as many errors have been seen that escape Storm's otherwise beady eye. Test, test and test again. Use PHPUnit for writing tests; use Xdebug for profiling your application; between the two you can produce test coverage in excess of 100% which makes future modifications, upgrades, additions etc a lot safer.

unexpected { or ; are pretty much game over as far as PHP is concerned and while logs help, packages have limited use here as syntax errors often prevent them from operating. I would suggest that any changes where you may be unsure you test locally. Assuming your local system works ... (you are testing aren't you?) ... then there should not be a problem - negating minor version differences in OS/PHP version etc. Next is to run your files through php -l: find . -iname "*php" -exec php -l {} \; this will point any any syntax errors in your code along with a handy line number that suggests where the problem is. You can also run this on a file-by-file basis with php -l <filename>.php If you are using git, it is possible to add this as a pre-commit hook which can save a few headaches.

... Ah, you've met the wife then ?

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.

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.

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.

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;

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.

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

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.

@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.

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.

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

Love it!

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!

/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

Pfft; real programmers use: cat > filename.php << EOL ?

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.

I didn't realize they made anime miget pr0n ? ?

Well it also depends what you mean by text-based games. We can assume that something like ZombieWars is indeed text-based, but what about Tribal Wars or indeed Ikariam? Each of these are text-based with the additional of some professionally made graphics; Torn is again text based with some rather good CSS though little graphics from what I remember. Certainly I know many games that are in reality text-based however they are made to look like a graphical game. Sure, they are not No Man's Sky or Gran Turismo, but they are nevertheless presented in such a way as to appear graphically orientated. For personal developers or very small teams it would be almost impossible to break into the full graphics market as the standard is set extremely high; consider the amount of work that goes into making a game that run on multiple platforms; with 4K graphics, and Dolby Surround music . I know I certainly play a number of text-based games (in its loosest sense of the phrase) and occasionally fire up the PS4 if I fancy a quick drive around Brands Hatch. For simplicity however a good text-based game, with pleasing graphics is ideal - you can login, play a few screens and logout without all the hassle of games consoles.

@dave - Yup - and on a remote box rather than a home desktop.To be fair was was young, inexperienced and foolish in those days; now-a-days he's ... well ... ?

Welp, I use a variety of OS's - at work; a mix of Linux Mint/Ubuntu as my desktop, server architecture is generally Debian based, though I still run a number of CentOS boxes and I believe I have an old SlackWare box kicking around. For heavyweight production boxes I run BSD in a few places, and my current home OS of choice is Ubuntu with RDP to open up a window to various Windows boxes. Personally, I find using Linux favourable for development work over Windows/Mac as I'm not fighting the OS all the time nor dealing with oddities introduced by the OS, and I can very quickly re-install it (< 10 minutes) if I seriously break something or just fancy a change. I also keep a few virtual machines lying around, though there are some pretty obscure OS's in those. Best advice for Linux installs (on personal kit anyway) - use an SSD for the OS, ideally an SSD for /home though an HDD will suffice, you can reinstall in no time and never lose anything as /home is on a separate partition/drive (unless of course you happen to execute one of the more serious commands - ask @SRB about that). Perform minimal installs where possible for speed and script the post-install procedure into a single shell script.

Quick question for all you programmers out there; how many of you are running an active McCodes game (any version), have plans for one in the near (< 9 months) future, or indeed know of any actively managed games out there? I have only one; a stock code-base used purely to demonstrate new mods etc (so not really an active game). I do run a couple of other McCodes esq. games however one was written in Python, the other was a complete redesign from the ground up and since neither contain original code; they don't really count. I ask as I have a set of mods that I would like to showcase; some of which are free, some open-source, and some commercial. I've no doub it would be good to build up a list of active games for some of the programmers to try and get their own mods publicised - there was an old post somewhere on this board but I suspect that everything on it will be out of date!

hehe, I'm sure we are all guilty of a) being that, b) calling somebody else that - I'd point fingers but I'm too old to straighten out those knackered digits. And seriously? 12 years old? Dayum, I've got t.shirts older than you not to mention production code that's been running for longer than you have inhabited this earth!

Been a long time but I'm glad this place has been resurrected. Some may remember me, some won't. For my part, I'm an old school developer with over 40 years programming experience in more languages than I care to remember. Some may recall some of my mods for the venerable McCodes platform, hopefully, with permission from the powers, I may release some of the more extensive ones. To those that don't know or remember me, don't be shy. Got a problem you can't solve, give me a shout. I'm always willing to give a helping hand. -- Alan AKA TheGrumpyScot AKA Nyna