Inveteratus

Melvor Idle Forge of Empires

Hmm, 2016 yet apparently no backups. I swear I was making backups in the, admittedly late, 70s - I guess that process must have skipped a generation or two! Mind you, had the most recent poster noticed the date (Sep 2016), perhaps they would not have not been too concerned about demos or images!

Well, I considered doing another deep dive into some of the fun bits of Mccodes, maybe looking at the job system and seeing how to improve it, or looking into the very poor casino games and seeing what could be done to turn them around, but I kept hitting stumbling blocks. When the code was open-sourced, I think lots of people including myself have high hopes of many people starting to turn it around, but what we see is very little work on the code if anything. Cronless crons and a role-based access control system, both of which are frankly pretty poor bits of work - I'd suggest ripping them out and returning to the old v2.0.5b base. At least we all know the problems with it! For reference, running static analysis tools on these modules shows a wealth of problems, so much so that I'm not going to examine them in detail. No deep dive, however does not mean the end of my foray into the world of Mccodes, far from it. I've started from the open-source edition, and have: Introduced a full template system using Blade as the template language. Created a front-end controller to direct new code into name-spaced controllers rather than individual files in the public folder. Added repository classes so controllers talk to the database only through the repositories, make it easier to change database back-end, table and field names. Used PDO as the core database driver rather than MySQL(i). Improved the docker stack considerably - though to be fair, it's for local development, not production. Rebuilt a number of pages using the new template system which allows for easy integration with the old code. Used Tailwind CSS as the CSS framework to get up and running quickly. Ensured the controllers are all PSR7 compliant, so dropping middleware in (for guest/auth redirection, and performing cron tasks) will be simplified. Started to flesh out the houses, crimes, jobs, cities, courses and items with fixtures as a "get you started" set of data. Used PHP 8.3 in the docker stack though I aim to get 8.4 in shortly, and MySQL 8 is also present along with Adminer for simple database management. Created a routing system for the front-end controller ensuring that all new code is defined by the routes. Checked the code regularly with static analysis tools to ensure no new bugs (or features as we used to call them) are brought into the system. Used Alpine JS to enhance the site to help with things like tabbed controls, show/hide password controls, modals etc. Stripped out the logging and replaced with Monolog with a database adapter. There's a lot of items on my roadmap: Finish of the core code rewrites to address all the common modules available from the menu and explore screens. Redo the crimes formula system. Refactor the attacking code to simplify it and better address how weapons can be used. Increase the amount of equipment slots for armor - thinking legs, body, hands, feet and head here. Use Alpine JS to enhance the site to help with things like tabbed controls, show/hide password controls, modals etc. Bring in some modules including the stock market, auction rooms foraging, and some as yet unnamed one. Add tests with PestPHP. Ensure where necessary, complex updates are handled within transactions to ensure atomicity. Documentation! Images for the relevant fixtures - cities, houses, etc. Visually, it does look at lot better, the templates allow me to get rid of the one-page lag often seen when committing crimes or training in the gym, but I've tried to retain the original look and feel to a certain extent - at least for now. At some stage, I intend forking my own work to spin up a game, though I pull push what I have online as soon as possible as a playable demo. During development, it will be refreshed on a regular basis until all the modules are rewritten to ensure none of the older code causes problems.

Some very good suggestions - culling inactive actives is thoroughly recommended though I'd be inclined to mail them 30 days in advance of a cull with the option to opt-out - they may be unable to play temporarily after all. I think I like the idea of only earning interest up to a set amount; it would help keep a cap on games where the interest rate has been set high, which may be deliberate. Charges, I've considered but I've never found a satisfactory mechanism that allows me to bleed funds out as a standalone measure - it seems too much like taxes in real life which I usually try to avoid ... and in real life! I suspect the key point to take from these discussions is that balance is very important. And while you won't manage that with an out-of-the-box system, with careful play-testing and no doubt hours slaving over a few spreadsheets will result in a game that lasts. There will always be areas that need tuning up, but if you get the basics right, the fine tuning can be done over time.

So what if I told you how to make $135,259 just by sitting on your hands just by giving me $100? Or how about if you give me $100 and I will show you how to make $5,323,942,470,216 again just by sitting on your hands? I've no doubt at this point, you are probably reaching for the "Report Spam" button, but bear with me a moment .. This is how MCCodes games are designed from the get-go. There's no need to play the game, just sit and wait and you will soon be richer than ... well everyone! Okay, some explanation .. lets look at a couple of critical lines in MCCodes in the cron_day.php script. UPDATE users SET bankmoney = bankmoney + bankmoney / 50, cybermoney = cybermoney + cybermoney / 100 * 7 Will that doesn't seem so bad .. or does it? Since MySQL will be rounding the result so if we look at the basic bank to start with given you save $100: After 1 day you will have $102, after 2 days, $104... even after 10 days you will only have $120. Weill again, that doesn't seem to bad. It's not going to introduce too much money into the system - after all $20 in 10 days is peanuts. But wait, after 20 days, it's risen to $147, after 30 $177. After 50 we are up to $265, after 100, $713. In fact, its doubling your initial money every 36 days or so. So after 1 year,. you will have $135,359 in the bank for an outlay of only $100! I wish I got that in the high street! Before we look at the frankly frightening cyber-bank, a little math. $principal = 100; $futureValue = 135359; $annualPercentageRate = $principal * $futureValue / 100 + $principal; Yipes - that's a rate of 135,259% Now for those of you paying mortgages, you may be lucky to have a rate as low as 2.5%, I believe I'm paying around 4.5% at the moment, while my bank is giving me a meager 3.3% rate on my savings. So what about the cyber bank. This one is truly scary. It doubles your money every 10.5 days ish. So in 10 days you will have amassed $197, in 20 days, that's gone up to $388, in 50 days we have a rather nice $2,953, while in 100 days we've got $93,092. These figures a truly scary! And after a year... Well we would have $5,323,942,470,316 but as that overflows the data-type in MySQL (a signed int) we would have the maximum of $2,147,483,647! Phew! Well clearly, the banks calculations are bringing in far too much money into the game, so what can be done about it? Well the first thing I suggest is to shut down the cyber-bank. It might be a nice idea, but it's going to ruin your game in double quick time. Since it's doubling the principal every 10.5 days, then every years, the amount of cash in the game will be fatal. With 10 players not a major problem, but with 10 players joining every month .. you have a financial crisis on your hands in well under a year. Next suggestion is drastic. Remove the bank-money and cyber-money update statements from your daily cron. In fact you don't need crons to work out what your bank value will be - again it's all down to a simple bit of math. (We'll see how to do that in a bit) Now of course you want to reward players for having a bank account - how about 100% APR for premium players and 50% for non-premium players. That's still way more than any of us will ever see in real life from a high-street bank, but it's not introducing too much money into the system. Again .. a little bit of math $principal = 100; $annualPercentageRate = 100; $futureValue = $princial * (1 + $annualPercentageRate / 100); Will let you play with the APR figure to see just what sort of cash you will be bringing into your game. To apply this as a multiplier on a daily basis... $daysInYear = 365; $dailyMultiplier = pow($futureValue / $principal, 1 / $daysInYear); So for 100% APR, this yields a daily multiplier of 1.001900838. If you insist on using crons then you could adjust your daily cron to : UPDATE users SET bankmoney = bankmoney * 1.001900838; Caveat, due to rounding, you won't actually see any interest until you have around a $270 in the bank, but after that it will kick in - maybe that's a good thing! This is a lot more gentle on the amount of money coming into the game and is actually quite manageable - at least from personal experience. If you are feeling brave, then as long as you have the date-time the user deposited money into the bank, and the principal amount, you can compute the present value (I use the term present rather than future here but it means pretty much the same thing) at any point to show them what the have now. For reference: $dailyMultiplier = 1.001900838; $prinicpal = 100; $daysSinceDeposited = 50; $presentValue = pow($dailyMultiplier, $daysSinceDeposited) * $principal; With these calculations, I've never need to use a cron to update my bank, and in fact I can actually claw a little money bank from the player by rounding the number of days down to a whole number (which may be have 3.5 days) so they lose out on a little interest but still get the benefit of an apparent 100% APR interest especially if they leave their money alone! The moral of the story here is ... well I'm not sure. It probably goes a long way to explain why so may MCCodes fail - their inflation turns rampant as smart players bank their money early and often. There are some nice solutions I've found such as variable APRs depending on key stock holdings and/or premium status, limiting the amount of cash that can be deposited by combat level (so the higher combat level you are, the more likely you will have large amounts of cash on you to entice players to PvP). You might also look to variable APRs where it reduces to try and keep the overall interest across all players to a certain value, so as more players join, the global APR reduces slightly. What's your take on it? How do you stop players making money? If you are happy to run an MCCode game with the original SQL in the daily cron - let me know a link to your game! I always enjoy breaking the bank!

I've seen some stock markets in MCCodes-based systems, and sadly most fail for a number of reasons. A classic example being one I came across a year or so back. From what I can ascertain from playing it; it had a cron running every 5 or 10 minutes changing the price to a random value with a set range. This meant that any smart player would monitor the market for a few days to determine the lower and upper bounds, then buy when within lowest 10-20% of the price range, and sell in the upper 80-90% of the range. Oddly, I had a mail from the admin/owner asking how I was managing to make so much money so quickly... Despite telling them, they failed to understand the underlying problem, and banned me a day or so later. My fault ? Possibly, I guess it is abusing a bug, but it's a bug that despite explaining it, the owner failed to take steps to address it in a timely manner. There's actually a number of problems here : Random values do not a stock market make. Using crons to update the prices. Failure to log actions on the market. And critically, not play-testing prior to release. So who to we address these ? 1. Use a noise generator There's a number of decent noise generators out there, though I find that Simplex is probably the best for mimicking a stock market. Remember, in a real market, prices are driven by "market forces", which essentially means the amount of stocks that are being bought and sold. As a game simply won't have the number of players to drive this, then using a noise function seems to produce the best result. 2. Crons are unnecessary when you can generate the values via your function in real time. Assume your noise functions is defined as : function noise( float $x ): float then you can pass in a UNIX timestamp scaled by (say) 1/255 (i.e. multiply by 0.003921568627451), then may get a result in the range -0.7888 to 0.6373. Multiple this by (say) 128 and add 127 you would see a range of 26.023 to 208.583. So while the main input into your noise function is essentially a time value you would actually be using it like: $timeScaleFactor = 1 / 255; $rangeFactor = 128; $rangeOffset = 127; $result = noise($time * $timeScaleFactor) * $rangeFactor + $rangeOffset; This gives you plenty of scope to vary the stock prices by changing the input variables, and the best bit is, being deterministic, the $result will always be the same for the same input values - so no need to use crons, you can generate the price at any time on the fly. 3. Logging actions There are multiple options here, probably the simplest is just to store the player-id, the transaction type (buy or sell), the stock-id, the number of stocks, and the price they were bought or sold at. Of course, you may not really need to log transactions assume you follow the next step closely. 4. Play testing This is extremely important, and sadly something that is often missed by owner/admins. Ideally unit and feature tests should be present to ensure the site actually works using either PHPUnit or PestPHP. After that, you can consider acceptance testing or simple just make sure you manually test EVERY page in your project. And that's not just a case of seeing if the page loads - drop in some bad data; i.e. try and buy -1 stocks, or putting string data into numeric fields. There's a number of techniques that people favor here - I tend to rely heavily on feature tests; but they may not pick up everything if you are lazy when writing your tests. Going back to the original example what would these points have addressed? Well for one, using a non-random system makes it more difficult to predict the outcome of the stocks despite being deterministic. Time is one factor, but you still may have to consider limiting the number of stocks available, or perhaps ensure that you cannot sell stocks for maybe 14 days. Without crons, we've got rid of a hidden problem and extra load which simply is no longer needed, though you would need to to do more work to present a stock graph rather than just pulling data out of the db. Logging is of course a simple one to address, and may not be needed if you trust your code and understand any potential pitfalls. Finally testing is probably the biggest one here. Without testing your code, you run the risk of missing something that may seem stable and fits in nicely in your project but suddenly introduces massive amounts of funds making your game highly unstable. If anybody has suggestions in improving the buy/sell experience, let us know - it's a potentially useful module for many games as it can tie up money for long periods of time. Finally, for reference, here's an example but of code you might want to play with: function noise(float $x): float { $permute = [ 151, 160, 137, 91, 90, 15, 131, 13, 201, 95, 96, 53, 194, 233, 7, 225, 140, 36, 103, 30, 69, 142, 8, 99, 37, 240, 21, 10, 23, 190, 6, 148, 247, 120, 234, 75, 0, 26, 197, 62, 94, 252, 219, 203, 117, 35, 11, 32, 57, 177, 33, 88, 237, 149, 56, 87, 174, 20, 125, 136, 171, 168, 68, 175, 74, 165, 71, 134, 139, 48, 27, 166, 77, 146, 158, 231, 83, 111, 229, 122, 60, 211, 133, 230, 220, 105, 92, 41, 55, 46, 245, 40, 244, 102, 143, 54, 65, 25, 63, 161, 1, 216, 80, 73, 209, 76, 132, 187, 208, 89, 18, 169, 200, 196, 135, 130, 116, 188, 159, 86, 164, 100, 109, 198, 173, 186, 3, 64, 52, 217, 226, 250, 124, 123, 5, 202, 38, 147, 118, 126, 255, 82, 85, 212, 207, 206, 59, 227, 47, 16, 58, 17, 182, 189, 28, 42, 223, 183, 170, 213, 119, 248, 152, 2, 44, 154, 163, 70, 221, 153, 101, 155, 167, 43, 172, 9, 129, 22, 39, 253, 19, 98, 108, 110, 79, 113, 224, 232, 178, 185, 112, 104, 218, 246, 97, 228, 251, 34, 242, 193, 238, 210, 144, 12, 191, 179, 162, 241, 81, 51, 145, 235, 249, 14, 239, 107, 49, 192, 214, 31, 181, 199, 106, 157, 184, 84, 204, 176, 115, 121, 50, 45, 127, 4, 150, 254, 138, 236, 205, 93, 222, 114, 67, 29, 24, 72, 243, 141, 128, 195, 78, 66, 215, 61, 156, 180, ]; $i0 = $x > 0 ? (int)$x : (int)$x - 1; $i1 = $i0 + 1; $x0 = $x - $i0; $x1 = $x0 - 1.0; $t0 = 1.0 - $x0 * $x0; $t0 *= $t0; $n0 = $t0 * $t0 * $noiseGradient($permute[$i0 & 0xFF], $x0); $t1 = 1.0 - $x1 * $x1; $t1 *= $t1; $n1 = $t1 * $t1 * $noiseGradient($permute[$i1 & 0xFF], $x1); // The maximum value of this noise is 8 * (3 / 4) ^ 4 = 2.53125 // A factor of 0.395 scales to fit exactly within [-1,1] return 0.395 * ($n0 + $n1); } function noiseGradient(int $hash, float $x): float { $h = $hash & 15; $grad = 1.0 + ($h & 7); if (($h & 8) != 0) { $grad = -$grad; } return $grad * $x; } And just for giggle ... something I was experimenting with -- apologies for the un-formatted dates

Why not use something like omnipay? It supports a huge variety of payment gateways - including Paypal, with all the same interface so you can chop and change to suit. It has the added advantage of being free. (Sorry Dave!)

Ah, the days of CE - fun was had, money was made, games were written, bugs were rife .. all good stuff! A merry Christmas to you all and here's hoping for a good New Year.

I'd argue the point - however there are some valid points. In the old days, when CE was in existence; pun intended, MCCodes was a vibrant product despite its many faults, with plenty of active developers willing to push out some freebies. As time progressed there were other games, and people willing to put their time and effort into helping people get off the ground. These days, of late, we've seen GRPG and MCCodes both turn open-source, though considerable work needs to be done to turn them into viable long-lasting products. But to what end ? It would be nice to see one or both of them brought up to scratch with a decent front-end controller, requests, controllers, validation, templates, unit testing etc, but that's a fair amount of work for anyone. There are a few developers I know or rather knew here that I've worked with, some in real-life that I've enjoyed their company, their insights and indeed their knowledge, but where are these people now? Most have moved on away from IT, the few that I'm aware off are probably too busy with real-life problems to return to what is essentially legacy code-bases that with the best will in world, simply costs too much time to be realistically viable. Hosting these days is simple - and cheap. DO, AWS are both fine environments, there's really nothing to stop developers from grabbing an account on either and getting setup. The marketplace ... well it's no github - and that is what I suspect is needed. Look at the larger open-source products, they have a lot of products in version-control, once there is sufficient mass, then and only then, should a marketplace be considered. There's also no point in having a marketplace for a product until the base issues are sorted out - and ideally, the product is brought kicking and screaming into the current century. So what's the solution ? Well, I'm a developer, I'm not production management, so obviously I would be dusting off an editor and firing up a project ... if I had time. I've enough experience to refactor projects and to maintain them, but it's not really something I'd wish to do alone. There lies a possible solution of course, if somebody were to pickup the mantle of managing pull requests, but it really needs a group of probably 3 people to drive the direction forward, otherwise you run into the age old problem, of mine is better than yours ... I'll create a fork and work on that myself. I'll leave others to draw a conclusion to all of this. As a side note, my apologies to GRPG developers especially if I've maligned the code-base, I'm not fully familiar with it. MCCodes developers... well sorry lads, you probably needed to communicate a bit in the first instance! tl;dr; we need a new open-source game or people willing to spend time bring an existing one up to current standards and be willing to teach the why's and wherefore's as they go.

Further to the above ... https://github.com/inveteratus/slim4 Has a small but working demo written using the Slim framework. I may extend it to add in other features in time, however this may give you a leg-up. You will need docker to run it, although it's easy to alter it to run under nginx (or apache), php and mysql natively.

With Slim, you really want to install a few extras. You'll need a PSR7 library - sliim/psr7 is perfectly decent. Slim does come with a container, but it's limited, so get yourself php-di/php-di. Drop in twig/twig of course, vlucas/phpdotenv for parsing your .env file and I like to use respect/validation for form validation. monolog/monolog for logging of course and finally, though I often forget about this one, is slim/csrf for CSRF protection though tbf, it's not difficult to do yourself. composer require slim/slim slim/psr7 slim/csrf php-di/php-di vlucas/phpdotenv monolog/monolog twig/twig I could rustle up a bare-bones skeleton, however there are plenty out there that are very decent and probably better than I can produce. Unlike many other frameworks, there are so many ways of booting Slim - you could for example place all the code into your index.php apart from the controller (and presumably repository) code, however I find I tend to split things up a bit. It's really up to you to choose what tools you need. Your container (usually php-di) allows you to instantiate any class and access that via DI, so you could (for example) have both Twig and Smarty in the same project potentially sharing some templates. CSRF, you can do yourself thought there is a package for that. Monolog is probably the standard logger as it supports writing to a huge variety of endpoints - files, databases, etc. Validation, well I tend to use Respect as it seems to fit my needs. and so on. I'd suggest you experiment with some of the basic examples in the Slim docs first have at look at the original author's skeleton akrabat/slim4-starter as it's a great starting point. For databases, use the container to instantiate a PDO instance, and ideally use repository classes that access the PDO instance - it keeps your code nice and clean. As for linking with JavaScript .. your choices are unlimited. It makes no demands whatsoever, on JS or CSS, so that's all up to you. As mentioned above, look into Alpine and Tailwind as both fit nicely and are powerful enough to produce some amazing applications. If you run into trouble or need some advice, give me a shout; I'm always willing to lend a hand. In the meantime, I'll pull apart one of my apps to leave it the basic index/login/register/home/logout endpoints and pop that in a repository for people to play with.

Sadly not 200 (I little less anyway) - and hopefully not upsetting anybody. I'm just trying to point out that providing limited code snippets without any context or useful error messages is not always the best way to ask for help. By all means - ask away - if I/we can, I'm sure help will be forthcoming.

While I feel it is probably a little too obvious to point out the frankly bleeding obvious, perhaps in this case it is necessary: "text" => 'You successfuly stole a '.$carName.' with '.$carDamage.'% damage.' So that looks like it's setting an element on an associative array, yet you appear to address $text later on. I'd also point out the lack of trailing comma here (not perhaps 100% necessary, however potentially good practice. You could also perhaps use inline variables here, ie "... {$carName} ... {$carDamage} ..." -- both of which will be expanded correctly due to the double-quote. (n.b. ensure both variables are of course correctly escaped). )); ... Closing an array by any chance ? or nested array ? - If so, you probably want to be using the short array syntax these days. - [] $labour = mt_rand(1, 100); Let's use random_int(1, 100); -- it's a lot better at random number generation even at some ranges, something mt_rand() is pretty poor at. foreach ($cars AS $c) { Yeah gods man - use lower case for keywords already! if ($c['C_successText']) { $text = $c['C_successText']; } } Let's just gloss of the use of short variable names .. ( foreach ($cars as $car) would have been a much better choice - even on code this small ). I suspect this could be shortened to .. $text = $c['C_successText'] ?? false .. or similar but where's the code that determines the success? if ($labour) { Where does this come from - it's not referenced above. $text .= " And you earned ".number_format($labour)." Quarter Master"; Okay, so we like mixing single and double quote for no real reason. Stick to single unless you have a replacement variable ( "... {$var} ..." ) - just make sure it is escaped properly! $rewards[] = array( 'val' => number_format($labour), 'name' => 'Quarter Master' ); } Was $rewards initialized above ? And again, what's with the short array syntax ? I have a nasty feeling this is being edited with a simple editor - maybe sublime text, maybe vscode, maybe notepad, or maybe even rped (before your time I image) - Do yourself a favor and get a copy of PhpStorm, it's free for evaluation purposes for a month iirc, (and can be rolled on forever) - it may help point out potential bugs in your code before having to ask for help or run on a production box - and no doubt upsetting a few regular players. It would also be useful to see any error messages your system may be throwing up as well as the original file in full (credentials, if present, masked obviously). If you don't feel happy with presenting the whole file - toss us a function or a method - it makes for so much easier debugging and thus swifter turnaround of problems.

I've been experimenting with this for a while now and it seems to have stabilised quite nicely. This particular screenie is from my mccodes project. specifically the new cores editor within the staff console although there are a couple of missing top-level entities. Both the requirements and the benefits fields are essentially simple tag lists, however the code is validated and evaluated enabling any number of skills to be applied to a player, with any number of abilities. I'm using expression evaluation for the requirements, this will mean that to; in this case anyway; start this course, you will need to pass all the requirements. Expression evaluation thankfully works nicely for the benefits here as well and using reflection is able to access any detail connected to the user. Obviously both fields are heavily validated, essentially being whitelisted so nothing untoward can ever creep in. My main goal of this is to bring about the ability to change the game dramatically without touching code as many areas will use the requirements field i.e. entering the travel agent might require you be carrying a passport `user.inventory.has(PASSPORT)`. Simple stuff, but proving very useful

Personally, I'd forget income for the moment. Look to your design steps; there's a lot of problems that will need to be solved, a lot of content to be generated, some of which will no doubt lead to further problems and further content. Balances need to be sought to ensure that players cannot get too powerful, in-game currency needs to be carefully tended to prevent runaway economies and only after a lot of play-testing be it with beta testers or with spreadsheets will you see where adjustments can be made which would allow for real-world currency purchases. Of course you then run into problems of how to charge. There's a lot of payment gateways out there, but on mobile's, especially iOS, I suspect you may run into restrictions; ie you may have to use Apple's own payment system. On Android there are probably less restrictions, and of course a PC/Browser is pretty easy going. You may have charge-backs, you may have players who expect items, facilities etc in return for real-money, you may have break-downs in communication between the player, the payment provider and yourself. You may even have server issues where players expect some level of service having ""paid"" to play your game. This brings in some basic but wise-to-have legal protection. There was game I recall that held weekly gang-based challenges; the system relied on people purchasing some form of in-game currency which was used to further their gang's resources. The winner of the competition won either a small token gesture of real cash or occasionally some gizmo, the runners up received some of the in-game currency thus putting them in a slightly better position the following week. It worked extremely well; even a beginner could derive a lot of fun and occasionally some in-game currency if they took the time. Prizes went up quite nicely, I seem to recall iPods at one stage and prize money did reach into the hundreds. So while it's possible, I'd suggest you work out the concepts first, get the first draft of the code in place; get it play-tested and balanced and then and only then should you look to developing an income from it. Sadly very few games make it this far but a few products do survive. Being careful with your design process, and continuous monitoring of the overall balance, is probably key to making something that can last. Best of luck!

Some other questions do arise; for example - you say you have 10 years experience, congratulations; but just how far forward are you with the project? For instance do you actually have a specification with wire-frames, clear definitions of the calculations necessary for say gym gains, or how combat works? Without these, there is a lot of core, internal leg-work to be done before you can get of the ground. Sure, you can release and "see-what-happens" which appears to be common in the Mccodes world, but I hope we've grown past that. How about back-end data structures? It's all very well putting together a system (thinking of Mccodes here), that works, until you have more than 20 people playing simultaneously at which point the database grounds to a halt due to poor design. GL is better but still suffers from scalability from what I've encountered (feel free to correct me on this!). Caching? Job queues etc.? Yes it's a lot of open architectural stuff which I don't expect an answer for, but is of interest to the prospective programmer. Angular? seriously? Okay, I must be out of touch (and not the first time). React? not my favourite by any stretch of the imagination, a few here who know me will attest to this! Rest API and sockets; okay I can get behind them, but then I'm much more of a back-end developer! Sockets do run into scalability problems quite quickly, Rest API's not so much; at least with a decent LB in front of them. The offer of part ownership is potentially laughable, but then I've been in the industry for a while (>45 years); and few projects have survived to make this even a viable proposition. I'd hope that your abilities would help create a good working group of people who collectively can combine their efforts towards this. Looking back, I don't think I've ever had ""ownership"" of a site last past a couple of years while the admins drive it into the ground with poor management or just walk off leaving the site to the vagaries of it's users with no DB/code access. The iOS, Android, PC bit ... hmm, there's some interesting problems with that mix. Graphics; don't they need higher resolutions - 2x, 4x, 5x? on iOS which introduces potential bandwidth problems assuming you are hosting this on any sane system (AWS, DO, RS etc). Both Android & iOS marketplaces require some sort of recurring payment just to be able to list; that's going to hurt billing unless you have a cunning plan for a .. and I hesitate to mention it .. "pay to play" or "pay to win" system. PC is easy enough - heck with speeds these days, it's possible to host demos and small sites from home not that I'd recommend it. Responsive websites get around the initial iOS/Android problems which may be a way around the iOS/Android marketplace pricing. And that brings about the question on how the site generates income. Adverts (god forbid), pay to play/win, or are you bankrolling the whole system? I assume some form of bankrolling is in place to begin with - AWS/DO/RS + Github/BitBucket/Gitlab accounts and tool-chains. In the early stages of any game, donations seldom work as the product is not public facing, so the costs mount up. This has to be offset somewhere; I remember an individual here who ""hired"" programmers for a projected income, but was paying a massive amount for an highly over-spec'd development box. I guess it would be useful to know your background as well; 10 years is a decent timescale with one language but these days, programmers need to be savvy in so many fields; there's potential for a lot of overlap which may not be desired. I suppose finally Torn ... I mean ... why? Sure, I play, but by ""play"" I mean I log in once a day, read my messages, commit a few crimes, run a quick gym training session and bugger off. To me, Torn is a social club, with a lack of content. Oh and why crimes? Isn't the market flooded with crime based systems over cooperative play? So here's where you could make a massive difference; by coming up with something fresh; something no-one has seen before - and no, I won't ask you about it here as that's unfair to you. Anyway, my best of luck finding a team to work with you.

I'd argue with ags_cs4's suggestion that you need to use PDO to provide an extra layer of protection from injection; as it's not fully correct. It is still possible to perform SQL injection attacks against a site using PDO for it's queries even if they are prepared. And the MySqli library can be perfectly safe if used correctly! Sadly Mccodes has shown us how poor queries can and do result in broken games very quickly. The first point about helping make a site more secure; note "more", not "fully"; is to ensure the data you have is sanitised wherever possible to protect against a number of problems. Passing any request variable to SQL is going to be a recipe for disaster. Check your inputs properly; using for example ctype_digit for positive integers, filter_var for pretty much anything else; there's a decent range of FILTER_VALIDATE_xxx constants with support for options for example integer minimum/maximum values, regular expressions for strings etc. Once you have sanitised the input, you can still have strings which would prove dangerous were they passed directly to SQL, so you need to prepare your queries. The basic concept is very simple: // Assuming $location and $username have been filtered correctly, and $pdo is an instance of PDO: $sql = 'SELECT * FROM users WHERE location = :location AND username LIKE :username'; $stmt = $pdo->prepare($sql); $stmt->execute([ 'location' => $location, 'username' => $username, ]); $data = $stmt->fetchAll(); It is a bit of a contrived query; potentially finding a user in a particular location; however it serves to demonstrate how data can safely be passed to SQL. I suggest some research into filtering and using PDO yourself; it's not difficult. Converting mccode's poorly written database classes into PDO is not difficult; with care you can add a function to the basic database class that uses PDO, then it's just a case of slowly converting each and every page to use that method. As a side note; well worth reading (The only proper) PDO tutorial. I still occasionally find myself referring to it from time to time.

I can't help but wonder why your are "coding" on a production server? Local development is surely the answer using docker, nginx/php-fpm/mysql, or even php's builtin-server and mysql - all of which have been proven to be highly successful with GL and mccodes. Deployment is equally easy assuming you have SSH access to the server. Failing that, you can usually setup CPanel to permit deployments from github.

The error message should be sufficient to determine that there is a misplaced ' symbol - and it does point towards the $r['] I suspect the url tag should be [url='viewuser.php?u=" . $r['userid'] . "']" . htmlentities($r['username']) . "[/url] however it would probably be wise to provide more context; i.e. a few lines above and below line 120 in order to provide a more accurate response.

Yes, I just got that message. Seems there's a lot of problems with this game, not least is overall balance. The premise may have some merit, but the implementation is simply not there to make it interesting enough.

(Answered in game)

Lots of nice bugs, missing files (404s), interesting names files (tiddlesverifybitchmuhaha.php), poor layout, poor use of css ..., as a game it rings a bell, I've seen something like it but can't remember what it was. Needs a lot of work prior to production especially with the in-game currency, far too easy to make $$ which suggests either some major bugs or some very bad planning.

Try ALTER TABLE `users` ADD `mine_level` INT UNSIGNED NOT NULL DEFAULT 1; ALTER TABLE `users` ADD `mine_exp` INT UNSIGNED NOT NULL DEFAULT 0; ALTER TABLE `users` ADD `mine_needed` INT UNSIGNED NOT NULL DEFAULT 1000; Notice: The ADD keyword is needed. INT(11) -- The (11) is useless, it has no bearing on the size of the value that can be stored. I've used UNSIGNED as it's unlikely your mine level and/or experience will go below zero. I've change the default mine_exp to 0 -- feel free to adjust to suit.

There's more faults in that bit of code than you can shake a stick at ... but you could try a couple of little of changes that help as you've not provided any information on what is going wrong. Changing the error messages to make it clear which part of the code is failing is useful, but I ran successful test by changing just one line: <?php function do_pic_change() { global $db, $userid, $h; if (!isset($_POST['verf']) || !verify_csrf_code('prefs_picchange', stripslashes($_POST['verf']))) { csrf_error('picchange'); } $_POST['newpic'] = (isset($_POST['newpic']) && is_string($_POST['newpic'])) ? trim($_POST['newpic']) : ''; if (empty($_POST['newpic'])) { echo 'You did not enter a new pic.<br />&gt; <a href="' . gen_url('preferences', true) . '&action=picchange">Back</a>'; } else { //if (strlen($_POST['newpic']) < 8 || !(substr($_POST['newpic'], 0, 7) == 'http://' || substr($_POST['newpic'], 0, 8 == 'https://'))) { if (!filter_var($_POST['newpic'], FILTER_VALIDATE_URL)) { echo 'Invalid Image - Invalid URL.<br />&gt; <a href="' . gen_url('preferences', true) . '&action=picchange">Go Back</a>'; die($h->endpage()); } $image = getimagesize($_POST['newpic']); if (!is_array($image)) { echo 'Invalid Image - Cannot retrieve image dimensions.<br />&gt; <a href="' . gen_url('preferences', true) . '&action=picchange">Go Back</a>'; die($h->endpage()); } $db->query('UPDATE `users` SET `display_pic` = "' . $_POST['newpic'] . '" WHERE `userid` = ' . $userid); echo htmlentities($_POST['newpic'], ENT_QUOTES, 'ISO-8859-1') . '<br />Pic changed!<br />&gt; <a href="' . gen_url('index', true) . '">Go Home</a>'; } } I've made a few changes: * Removed unnecessary references to global variables * Added extra information in the error messages to help debug the problem * Change one line leaving the original commented out Testing this against the url https://upload.wikimedia.org/wikipedia/commons/4/40/Image_test.png works nicely.

You know, if somebody at work posted two files totalling over 400 lines with the simple "I'm getting big numbers" complaint, my response would not be unkind, but I'd suggest that perhaps they went back to the drawing board, tried to find out what the problem was themselves, better yet, explain what the problem is with screen grabs where appropriate, and provide description of what is happening, where it is happening, and what the expected behaviour is. A lot of the people here are lucky enough to work in the industry, but looking through poorly formatted code, without a clue as to what the issue is strikes me as being more work, less play! Saying that, the whole delta updates i.e. timestamp based rather than cron based updates looks very messy, especially as it can be done in a couple of queries and not within a loop. If you had for example a user that hadn't logged in for one month, that loop could run over 8,000 times, generating over 1,500 queries when 2 would suffice. Given you know the current time, you know the time the user was last updated, that gives you a time difference in seconds. Assuming that is greater than some small figure (say 300 seconds) then you can update the user's fields: will, brave, hp and energy with the time difference multiplied by the increase per second of each field which is simple to calculate. The problem with doing this, is loss but this is only addressed by using real numbers for the four fields; the maximal values can remain integers; which in turn does cause a couple of other minor issues. Nothing against the original author of this, conceptually it's a neat trick, but anytime you have a query in a loop, you need to start asking questions. With the default DB schema, even a simple SELECT operation will lock the entire table for all other operations, so this method will quickly limit the amount of simultaneous users you can have on any system, and has the potential to cause unpredictable and difficult to debug timeouts. Finally, it's great to update your own player like this; I use a similar technique, but what happens to other players? NPCs being the obvious example. If you have a number of NPCs that people can fight against, how do their stats regenerate? I simply pose the question, I don't offer a solution here, though it is simple to implement.