This is a totally optional read, it’s sort of the behind the scenes thread on why I do x instead of y. What I’m working on now, etc


summary
 the immediate goal is to de couple the code from the design. After thats been done I can make the real mode
ization push 

The old alacrity co mingled design, code, with no code/design reusability at all. It also uses a very old version of php which prevents me from upgrading the server or php. The database functions are not wrapped, tables are hardcoded into the pages. so I have to go line by line fixing each.

It is impractical to use a mode
 program design (heavy JavaScript calling back end API) without first untangling and identifying everything first, because the api would end up changing every few days as I discovered something new. And also because the php pages would then have copious amounts of JavaScript added on top of the php /html already .

Modifying the design requires a programmer to implement a design at the moment. This is very inefficient 


I think the biggest question is probably , what’s with the pop ups? 😂 

Pop ups allow me to split the player actions from the page, without having to redraw the page every time a player does something.

These can be quickly cut over to mode
 design after I finish the rewrite.






The background 
 Alacrity 1.0 uses a series of 300 pages, with no backend libraries, no real configuration and a ton of global variables. It uses a very old version of php, which was going out of style when alacrity was going live. The html design code is co mingled with the backend code.

The pure backend cron jobs (daily resets, breeding , trials , etc) are similarly written.

In game events and player actions are generally in-line within the code. 

The databases also suffer some design flaws (text key lookups, case sensitive column names, incorrect designs, confusing variable names, etc etc 

Due to the lack of back end libraries, there is a lot of repeated code.

The html design is such that the webpage is co mingled with the software.

In short, this is a Web 1.0 project. What makes it extremely impressive, is the size of alacrity. It’s sort of like building a pyramid in ancient Egypt. There is a lot of love that went into its design.

It’s probably 500,000 lines of code. This is a large project, even by today’s standards.




Methodology to fix 

Normally, it is not recommended to fix a project, but rather start from the ground up, leaving whatever is there in place until you are ready to construct a replacement.

This wasn’t really possible because of the lack of backend libraries, and the file structure (300+ 50-10k line each pages in 1 directory, with inconsistent methodologies) .Code was in-line, oftentimes repeated with subtle changes each repetition .

There are many Easter eggs in alacrity (some of which require manual enabling, and I haven’t even found yet)

Things like the dog rendering have “glitches” (software and design errors )since glitches are an important part of alacrity, I had to preserve these errors into features .

In short, if I rewrote alacrity, I would sterilize instead of revitalize it!

My goal was to keep as much of the look and feel as possible 


So renovation it was.

Steps (in no particular order)

1/ sketch out the minimum libraries  required to manage

2/ identify and isolate player actions from the design flow

3/ modernize database interactions (this is a major problem) so we can move to new server

4/ break code into re usable modules 

5/ modernize HTML from old table designs , which are not very flexible, into divs 

6/ split all pages into a “code section” vs a “template section”

7/ remove all global variables 


The leap to the future 

1/ move all “code” to an api
2/ make most pages pure JavaScript/ html as possible, which then call the api for data.
3/ implement a proxy to sit overtop of alacrity api to route to the core api so that the next generation of features can be seamlessly implemented