Firstly, I’ve changed the category on my 2014 projects menu to be “Plasmation”, but it’s seemed to remove it from all my old posts for some reason. Anyway…

Framework

After last semester creating Cornstar, and working on Game Faming, I’ve begun to realize that CakePHP is more annoying to use than it is useful. Don’t get me wrong, it’s a good framework, and its helpers and security are great. The issue I have with it is that all my assumptions of what certain things do when typing them are usually wrong, and it takes longer to get something stupid working by searching Google than it would be if I created the framework myself and knew everything about it.

So, I’ve decided to use the MVC framework I developed for Cornstar instead of CakePHP. I received pretty good grades for it, so It can’t be all that bad. The advantage of this is that I know exactly how it works, and it stops me hitting any brick walls with knowing or having to search up how to properly use something in CakePHP.

A disadvantage of this is of course, if I get stuck with something I can’t look it up. However, I know more about PHP its self than the CakePHP framework, so if I get stuck on any PHP treated thing I’d have to look them up. Luckily the PHP community is enormous. All and all I think switching to my own framework is the best option.

The Framework

So deciding to use the Cornstar framework, I will also need to be updating it, so it can be used in other programs. Ther way it is now is that some code in the main library of the framework is Cornstar specific, meaning to make the framework modular, I’d need to re-organise some parts, separating things that will not change. To achieve this, I will simply move the program-only files into a folder called “corn”. After looking around, the only reference to “corn” in the Linux world is one at some university. Ideally, if I decide to make my framework public, it’d need to be able to be installed via “apt-get install corn” for example. Therefore I will simply be calling the framework “Corn”. This is because it is based off Cornstar and a corn on the cob typically has a nice juicy golden array of kernels, which could represent the functions and classes of the framework. Also, who doesn’t love corn?

Tracking goals

After doing a big fat “todo” list for this project, it made me realize how important setting goals and giving them achievable time is. many times I’ve sat around stressing and trying to reach for the main goal of “project finished” but without smaller steps, it just feels like it’s unfinished ALL the time. It’s like trying to climb to the top of something without a ladder; the ladder has rungs, which can be treated as baby steps towards an ultimate goal. It’s also important to set a time or date for which something should be complete to stop feature creep and achieving the feeling of “done this on time” at the right time. The other night I made a list of things to do and a time limit in which I was to do them. I couldn’t meet the time so I kept pushing it forward but it helped me track how long I was actually spending on something which helps set reasonable time for the future. Programming time flies. So fast. Maybe because I enjoy it?

I think what I’m trying to say here is basically: break tasks up and set a (reasonable) time limit to do them. It makes it a lot easier to manage and track time. Tracking time on things helps improve estimations on things. This means I can charge people more and not be late on projects.

Initial plan

The initial plan for this is to first set up the localhost, set up databases and shiz, and then get a demo of the page layout and interface up and running. Another thing I want to do is to create unit tests in the actual application. This will help with debugging and make it easier to test things once another feature of bug is fixed. This is because commonly, when something in the code has changed, it causes something else to break.

Tests

The way the unit tests will work is I’d set up a controller called “TestsController”, and it will simply contain a view called “All”. When going here (/tests/all) it will show test results. The tests will be for every component added by me. This benefits in many ways including making it easier to make sure everything is working on the slightly different live Unix server (compared to local Windows environment), and helps in re-factoring code. This Wikipedia article gives a good example about the design of unit testing that I want to try and achieve.

To make tests easier, I thought of a possible database idea where there will be 3 databases on both localhost and the live server, one will be for the real data, and the other for tests. The test data will be manually removed and re-entered at the end of the testing. The reason why there’s 3 is because there needs to be a database that can have data wiped and added to from another database. SO there will be the live data, test data template (with sample entries) and the actual test data (that is copied from the template). Using MySQL allows me to copy data to a database from another one, but does not allow me to create a database using pure scripts, this is why there needs to be a spare database.

The issue with the above is that I’d have to maintain 2 databases, having to re-enter test data every time I wanted to test it if the database changes. This should be okay, however, if the database doesn’t change much.

After some research, I can see that this sort of testing is a feature of test driven development development methodology (TDD) where tests are written first and then specific results for each test need to be met in order for it to pass. The important part of TDD is the specifications. Therefore these must be made and use case diagrams should be done for most of them (the complex ones). This meas that perhaps the development methodology for this project could be TDD.

Some test ideas:

• Create account username field:
  • isBlank – checks to see if a string is blank
  • isOneChar – checks to see if string is a single character
  • startsWithNumber
  • etc.

Other development methodologies

Although, TDD seems like a good one to use, I am still in the process of researching others, and therefore I may change my mind of which one to use. But if I don’t, then using TDD in this project will be a good experiment, as long as I record results.

Design changes

As for the design documentation, I didn’t really change anything apart from the way the camera is set up. Thinking of Photoshop and Flash, they both don’t really have a “camera” of sorts, but instead just clunky ways to change the object size in the scene. I think for Plasmation I’m going to include a camera that acts like both a camera in a 3D editing software and Photoshop. The way this will work is the camera can be moved around in a sort of “camera mode” (holding right mouse button in the scene) and using WASD to move like a FPS game (and how Unity does it) except you won’t have control over the camera in another view, the view will ALWAYS be the camera. This saves on having to have the 3 tabs at the top of the scene (edit mode, scene, side-by-side). However it makes the design different as the user will now not be able to control the camera using a scene edit mode or anything.