Dissertation: crisis averted

It’s ya boi Shark here, and it is about time I write an update in regards to my dissertation with an extra important lesson for y’all!

Because it has been a while since my first post about it, a reminder is in order! The gist of my dissertation project is to develop a game that utilises the principles of Einstein’s relativity. I’m building my project in VC++ and OpenGL (or so I was). My project is due in 3 and a half weeks.

OKAY okay, you mentioned a crisis?


You see, it is to do with that OpenGL bit and I’ll cut to the chase. I TOTALLY underestimated the amount of work needed to develop the game with it, and the work towards it was pilling up rapidly. You could sectionalise making a game with OGL as the following; creating the OpenGL context, developing a basic game engine, implementing your mechanics, building the UI and control setup, and bug testing.

Getting the game engine I wanted up and running took a while, and I hadn’t even considered UI! So in light of this, last Friday I made the call to abandon OGL and turn to the Unity to focus on getting a working game! Now you’re probably thinking “why didn’t you just use Unity to begin with? It’s designed to get you into making the game ASAP!”

Well for better or for worse, I’m the sort of person who enjoys pilling work onto myself and I wanted to convey my relentless effort. This time, it turned out it was for worse. The work I was doing in addition to what needed to be done was comparable to what some other students outright have a dissertations! You could I got a little too cock because realistically, a working OGL solution in three weeks complete with UI and gameplay was not going to happen.

So because my project title is literally “Relativity Simulation: Develop a physics-based game that utilises the principles of relativity, complete with GUI” without any mention of OGL, and I think it is for the best I mothball this solution and just concentrate on meeting that criteria as best as I can.

It’s not a disappointment, though…

In fact, I could use this to my advantage!

Firstly, I know have something interesting, critical, and self-reflective to add to my writeup! I can show the OGL solution as a sort of trial, which will then support my written rationale for choosing Unity over OpenGL + my own custom engine. I also put a lot of thought into how I was structuring my game engine, which in part is still applicable to explaining how I am using Unity!

Secondly, the physics implementation itself is transferable! The work I have already done is far from wasted, and since C++ and C# syntax is similar, most of physics stuff can be ported. It’s just implementing equations in code and attaching them to the game objects, at the end of the game.

Thirdly, I know have something else to keep my occupied over the long summer break between third year and my master’s year! I could never conceive abandoning my hard work, so I’ll just complete it without the pressure of meeting deadlines in my own time!

And lastly, just look at what I’ve already been able to do thanks to my prior experience of making a space-based Unity game last year!

And now, the lesson

Creative and ambitious are great, but sometimes complete realism is more important when working on a deadline as academic and report-driven as this! The OGL route would have been a great technical accomplishment for myself, but this Unity thing will likely give me more marks since it was done with actual academic reason!

I suppose this is a common caveat when you are in control of your own project, because you obviously want to show off the best you can do but sometimes it is hard to know when to stop.

I indeed came close to disaster on this one, which could have cost me a first-class grade. But I’ve realised my error is judgement, and I WILL make the most kick-ass game possible and focus on what is needed! Also my supervisor was always aware that Unity was my backup option, so there shouldn’t be any additional problems from hereon. I just got to keep my head down for the next two weeks as I iron out the actual game, and then another week of writing my results and conclusions down!

You can do this, Shark!

I should also point out things might be quiet on here during that time, so bear with me y’all! I’ll leave you with some more screenshots!

Also once this is all over, I’ll be going through some of the OGL stuff on here!

Shark out!


Forward unto Chapter 3


An update!

Planning of Chapter 3

As of this moment, you can see the outline for chapter here! It briefly describes what will be in the chapter and the current roster of ships to be featured. The chapter’s working title is “Starfleet”, and as you might expect will focus on the early years of United Earth Starfleet (UESF), through its stagnation at Warp 2.5 to the breakthrough of the NX project.

Some of the secondary topics will be the usual competition between starship design & manufacturing giants, the development of warp reactors, Earth’s colonial progress, and the beginning of the end of the Earth Cargo Service’s “space boomer” community. The planned ship roster is as follows:

  • 2120 – Y-class freighter, as seen from Star Trek: Enterprise
  • 2121 – “Archer’s Model” demonstrator, as seen from Star Trek: Enterprise
  • 2127 – Neptune-class surveyor, mentioned but unseen from Star Trek: Enterprise and designed from scratch by me
  • 2128 – DY-950-class multi-mission ship, referenced but unseen from Star Trek: The Next Generation and based off Kris Trigwell’s design
  • 2130 – “BBI-993”-class explorer, referenced but unseen from Star Trek: The Next Generation and designed from scratch by me
  • 2134 – “Warp Delta”-class destroyer, as seen from Star Trek: Enterprise
  • 2137 – “Arctic One”-class research ship, as seen from Star Trek: Enterprise
  • 2140 – “Sarajevo”-class transport, as seen from Star Trek: Enterprise
  • 2143 – NX demonstrator, as seen from Star Trek: Enterprise (NX Alpha and NX Beta)
  • 2145 – Bison-class adaptable ship, fanon design from Masao Okazaki’s Starfleet Museum
  • 2146 – DY-1200-class multi-mission ship, referenced but unseen from Star Trek: The Next Generation and based of Kris Trigwell’s design
  • 2149 – Z-class freighter, fanon design by me

Below is a little taster into some of those ships (click for credits)!

Status of Chapter 2

Chapter 2 is basically finished, although I’m wanting to give it one or two read overs in the near future and refine it a little more.

Timeline feature


New and based in the History section is this timeline feature, which serves as an easy to digest overview of the events relating to the UE’s and the Federation’s starship history. It is updated and added upon as per the development of the chapters.

People database


As mentioned in the last post from March, the latest part of the Database section was finally finished last night after 4 months of delays (not technical, just didn’t get around to it). It is inaugurated with pages on Alexi Zhukov and Zefram Cochrane, the founder of the UESPA and the first human to fly at warp, respectively.

(Technical) Internal data structure rework

Continuing the trend of offloading parts of the website to the MySQL database was resulting in multiple new classes and unique methods in the SearchEngine to accommodate the new data that was needing to be fetched and displayed. However, since a lot of them have basic properties in common (all data in the database have IDs, names, and a revised/last modified dates), I created a simple class inheritance structure to cull the amount of unique classes required. For non-programmers, this basically means that the classes (which are, in theory, data structures with a collection of functions inside) that represent the data used for different features of the website are coded to reuse code via a hierarchy of extensions. In the screenshot below, you can see an implemented but basic example of this in PHP used by the website. The class Data is known as the “superclass” (also referred to as a base or parent class) and it stores the most universal and shared variables of data – and functions (known as class methods) for accessing said data – needed by all other classes. Class TimelineEvent is then a subclass (or derived or child class), which extends from Data so it has all of Data’s variables and methods defined alongside its unique variables and methods. If these classes were completely separate, Data’s variables and methods would have to be written again inside an independent TimelineEvent class. Which will eventually (and would in my case) add up when you’re dealing with lots of data that share some properties but have their own unique ones as well.

Example of the classes used for data representation in the website’s backend

I know to programmers of any object-orientated language this does not seem high tech and is a basic use of inheritance at best (since I’m not dealing with overriding methods or any complex design patterns etc. etc.), but I thought it was cool to mention none the less and shows how OO concepts can make life easier.

More stuff offloaded to the database

Organisations, the database section mentioned in the last post, has been offloaded to the database. Yet another step towards a completely dynamic MySQL database-driven website!

Instant matching of search terms

To improve the search experience, I’ve added the ability for it to automatically redirect you to the correct result if it is an obvious match. For example, entering UESPA will instantly take you to the United Earth Space Probe Agency page without seeing the rest of the results.

Possible settings/control panel page

As things with the website become more complex, I’ve been considering adding a settings page for user preferences such as how section togglers behave (are they always open or closed by default), or whether instant search matching is enabled or not. Other ideas for settings include native light and dark mode and a purpose-made reader mode. My options for storing these settings are either a user account system or simple cookies. A user account system would allow these settings to be portable across the user’s devices as long as they’re logged in, but just cookies would be much quicker to implement and I could avoid the headache of dealing with user account security. There’s deffo a bit to consider before deciding to proceed with this feature!

BBI-class early concept


As I’ve mentioned before, BBI is to be an RT-class successor and is in the same tubular lineage featuring Masao’s Bison-class of 2145. I drew this concept a few months ago and have not touched it until now since I’ve been busy elsewhere and my energies here were focused on getting chapter 2 finished. With chapter 3 finally upon us, I will be revisiting this design soon.

SS Voyager detail rework


In keeping with the changes to the designs below, Voyager‘s details have been reworked. The changes are better colour shading, added RCS thrusters, visible separation lines between hull panels, and a longer main hull with a curved transition from the habitable hull to the engine hull.

Polaris-class detail rework


Changes to Polaris are about the same as Voyager. The fore-most windows have also been shrinked, and some details moved about.

Patterson-class detail rework


Whilst also including the same sort of changes made to Voyager and Polaris, Patterson has been made to look more robust with a strengthened neck structure. The 250mm guns are now fitted to visible barbettes and the command hull has been ‘blunted’. Also finally, the UN logo has been replaced with a UESPA one!

Yoyodyne II-type reactor

The Yoyodyne II-type is written to be the DY-732-class’s reactor, and will also be used by several period ships. Read about it here!

RT-class 3D model

I have been considering using 3D models for content development, whether it is using them to screencapping sideviews clearly at certain sizes thanks to anti-aliasing or for using WebGL to provide interactive ships on the database. Not entirely sure yet, but I have been attempting to model my RT-class explorer design to test my competency and develop my skills. I do 3D modelling for my other game-related projects as well, so this could be mutually beneficial for me here and on my portfolio!

A very early RT rendition

Upcoming stuff!

In the near future, the ship reports for the BBI and DY-950-class ships should be done. Alongside it, I’ll be deciding the final class names and production volumes for various Starfleet ships destined for chapter 3, and I will be beginning the design process for my Z-class ECS freighter. In the near-ish future, expect some more flesh to the UESPA database. I want to start including information about its divisions and composition, as well as its transformation into Starfleet. I also want plan database sections for ship components like weapons, shuttles, and impulse engines etc.

In the longer term, I will be pursuing the user preferences thingy I mentioned above. I will probably start with a mock-up of a user account system and go from there.

Chapter 2 nearing completion!

It has been over a month since my last update for Path to 2265. Since then, there have been some big and exciting changes!

SearchEngine upgrades

I’ve once again made large improvements in the search department. Natural ordering, more meaningful weighting, complete and proper tag finding, and basic filtering are now present! Numerous pages benefit from the improvements, but the site search itself gains the most by finally getting a basic filtering mechanism that allows you to view search results of a specific category!


Dynamic content

In order to promote better reusability of data, I’m starting to offload various parts of the website to the database. Since January, the UESPA/ECS ship registries and the reactor pages now use the database to grab data. Another advantage to this approach is that it allows cross-referencing to happen for certain items in the future – for example to reduce data duplication, I can now stop writing the unit listing for ship classes twice (once in the ship database and again in the registry database) by allowing both sources to reference one place.

New font

A new font is being used for the website’s header (navigation bar) and side menu on mobile devices. It’s called “Airborne” and is the font used on Federation ship hull marking.

Status of Chapter 2

Chapter 2 is about 75% complete as of now. Now under the chapter name “Expansion towards a United Earth”, the report focuses on early freighter development under the Earth Cargo Service, advances in explorers by UESPA, the Earth-Kzin Wars (from Star Trek: The Animated Series), and Warp drive limitations being experienced by Earth in the 2100s. Ships currently added, being added, or due to be added include Y-500-class freighter, Polaris-class diplomatic escort, Emmette-class surveyor, J-class freighter, Patterson-class battleship, Declaration-class demonstrator, DY-732-class multi-mission ship and RT-class explorer.


The first new ship is Y-500, a conjectural design of a canon freighter class mentioned in Star Trek: Enterprise. I’ve assumed relation with the DY-500s, so I quickly designed the ship as a cargo-only variant. The class’s specifications are currently being drawn up, and thus has not been included in chapter 2 yet.



Previously completed personal design. Designed to be fast and reliable diplomatic couriers for Earth that play a role in early diplomatic successes and trade deals. Registry starts at UESPA-20.



Emmette is a canon ship seen briefly in the Star Trek: Enterprise intro, but suffers with very little details available about the design and the ship’s history. Specs and missions are completed but are purely conjectural. Registry starts at UESPA-27.



A well-known and documented canon freighter from Star Trek: Enterprise. Registry starts at UESPA-47 for UESPA service and a large number of ECS registries have been created. The only true canon ship of the class is the Mayweather family’s ECS Horizon. I’ve placed the canon named but not seen ECS Constellation as a member of the class.



This is my latest developed design, based on an old UESPA-9 (SS Voyager) concept I drew up around early September 2017. It is supposed to be Earth’s first battleship and an instrument to help describe the Earth-Kzin Wars. They are heavily armed for the period, power hungry, and unwieldy. Registry starts at UESPA-57.



Another canon design with conjectural history. The only thing we know is that XCV-330 (SS Enterprise) is a class member. Given their obvious difference compared to other early Earth designs, I’ve written them to be a series of demonstrators for a new type of Warp field generation that ultimately fails to gain adoption. Registry starts at XCV-300.



Exists in canon as a class name only. The original design was made by Kris Trigwell – I redrew the ship with modifications for Path to 2265. Like the preceding DY-500-class, I designated the class as a multi-mission ship. I even included a mention of the [N] variant! Currently the design’s specifications are complete and it is present in chapter 2, but it still lacks a description on its ship article page. Registry starts at UESPA-68.



Another conjectural design of an unseen canon ship, this time the RT-2203-class from Star Trek: The Next Generation! I designed the ship to be on the same lineage as the Polaris and Patterson-class, with design inspirations coming from Masao Okazaki’s Bison-class. Registry starts at UESPA-82.


Addition of organisations

This is a new database section for various organisations and companies in the Star Trek universe. At the time of writing this, four organisations are currently available for reading about; Cochrane Institute of Alpha Centauri (non-canon), Earth Cargo Authority (canon), United Starship Agency (fanon by me), and Yoyodyne Propulsion Systems (canon).

Large ship renders

Due to the rising prominence of higher resolution displays, I am making it a priority to offer large renders of ships to cope with the larger and better displays becoming more and more available. Catering for up to 1080p might not be enough anymore, so I have started to redraw some of ships that are not original from to match the 2500px+ width of my personal design renders. Four examples exist at the moment; above with Declaration and DY-732, and below with DY-500 and DY-950:

DY-500-class render (canon design):

DY-950-class render (original design by Kris Trigwell – modified by me):

Upcoming additions

Before chapter 2 can be deemed complete, a few supporting database articles need to be completed to support the narrative – namely Yoyodyne II and Cochrane III reactors and the beginnings of the People database section (Zefram Cochrane and Henry Archer).

Once chapter 2 concludes, work towards chapter 3 will begin immediately. The chapter will focus on the early years of the United Earth government, the founding of Starfleet (as a division of the UESPA), the struggles of the Warp 5 program, and the beginnings of the NX program that leads to the development of first Warp 5-capable starship. Approximate timespan will be 2115 to 2150.

Currently planned ships are (in no particular order):

  • “Archer’s Model” demonstrator
    • Early Warp 5 program testship
    • Will be the same design as the remote-controlled model ship built by Henry and young Jonathan Archer in 2121 as seen in the pilot episode of Star Trek: Enterprise
    • Ship name to be decided
  • “BBI-993”-class explorer
    • Follow up explorer to the RT-class
    • Mentioned only on an ‘okudagram’ in Star Trek: The Next Generation episode “Up  The Long Ladder”
    • Class name to be decided
  • DY-950-class multi-mission ship
    • Second-to-last member of the DY-family of starships
    • Conjectural design already completed based off Kris Trigwell’s vision and interpretation
    • Mentioned only on an ‘okudagram’ in Star Trek: The Next Generation episode “Up  The Long Ladder”
  • Y-class freighter
    • Canon and well known freighter design
    • Seen in multiple Star Trek: Enterprise episodes
    • Written as a ship to use up previously discarded reactors
    • ECS-2801 (ECS Horizon) is a canon member of the class
    • Canon mentioned but unseen ECS North Star is written as a member of the class
  • Neptune-class surveyor
    • Canon mentioned but unseen surveyor
    • Earliest class of ship to be explicitly stated as belonging to Starfleet
    • Purportedly has the same captain’s chair as the later NX-class explorer of 2151
    • Mentioned in dialogue in Star Trek: Enterprise episode “Singularity”
  • “Warp Delta”-class destroyer
    • Well known and fan favourite early Starfleet ship
    • Frequently deployed on defence missions
    • Starfleet’s workhorse and single most numerous ship of the 2140s and 2150s
    • At least 50 ships in the class
    • Seen in multiple Star Trek: Enterprise episodes
    • Despite numerous on screen appearances, ship names and even class name remain unknown
    • “Warp Delta” is the behind the scenes nickname given by the design staff
    • Class name to be decided
  • “Sarajevo”-class transport
    • Well known Starfleet ship
    • Seen serving as a personnel transport
    • Seen in multiple Star Trek: Enterprise episodes
    • Sarajevo is a canon member of the class
    • Class name to be decided –  Sarajevo is currently the placeholder lead ship
  • NX demonstrator
    • Late Starfleet-Warp 5 program testships
    • Three known ships; NX-Alpha, NX-Beta, and NX-Delta
    • Only Alpha and Beta were seen on screen
    • Delta was only mentioned in dialogue
    • Both appearances and dialogue mentions from Star Trek: Enterprise episode “First Flight”
  • “Arctic One”-class research ship
    • Well known Earth ship
    • Seen serving as an arctic explorer and a moon-based transport
    • Seen in multiple Star Trek: Enterprise episodes
    • Arctic One is a canon member of the class
    • Class name to be decided –  Arctic One is currently the placeholder lead ship

Secure site search

In my last update for Path to 2265, I briefly described the major improvements made to the searching capabilities of the website. Today, I’m going into detail about these changes and why they are important for security and code quality. Examples included!

How it was
The decision to add a search to the website was made fairly early on, during a time where other aspects of the website like the visual layout design were more important to me. This resulted in a crude but working search solution that you can read about here. It is a very linear search in that it just finds and returns the results sequentially in the order they were found by the SQL query. And that was fine back then, but something better is needed now!

I should mention that in November, the search feature got a little attention with the conversion from raw MySQL calls to PHP Data Objects (PDOs) with prepared statements. Whilst this was a major plus for security, the implementation was still ugly and quick.

The new concept
A search that is to be deployed on the WWW needs to be functional AND secure. It is not hard to find reports about SQL injections and other malicious acts against site searches that can be a pain in the butt to deal with. With that in mind, I decided to rebuild the search engine from the ground up with security (and good code quality) in mind. The new concept calls for class encapsulation as well as PDOs – the usage of object orientation allows for controlled access to the code querying the database by only providing a set amount of methods and required arguments to interact with said code.

How does this all benefit security?
Well, PDOs alone do not help much in terms of security. But the usage of prepared statements does by separating the variable part (in our case, the search term) of an SQL query into a method that can safely bind the variable and exclude any nasty code. Here’s a good page about SQL injections and prepared statements!

Class encapsulation also does not actually affect the SQL’s ‘secureness’ directly. But if it is used right, it can provide a reduced interface that could be used for code security purposes (as well the usual benefits of using object-orientated code). If the core code is not in a class, the code will be executed in a procedural manner where there are no barriers to what you can supply that code. But if that core code is in a class, you can then write a select few methods inside that class that can access that encapsulated code with a parameter set that can be as wide or as tight as you want. In my case, I want to tighten how the code is accessed, hence “reduced interface”. All methods that can be called only take in data that I believe is needed for operation and nothing more.

Example – class specification
This is a listing of the class members for an example I will be using to show off these concepts at the basic level. The class structure is based on Path to 2265’s engine – the major difference is the exclusion of the experimental ordered tag search (more about that in a later update) that I am still working on.

  • private $dbHandle
    • stores instance of PDO object with database connection details
  • private $statement
    • stores prepared statements
  • private $query
    • stores last-processed query string
  • public __construct()
    • class constructor
  • private cleanString($string)
    • removes special characters from any input string
    • $string – input string to ‘clean’
  • private processInput($input)
    • breaks down an input string into an array of characters for tag searching
    • $input – input string to break down
  • public createStandardSearch($class, $col, $term)
    • executes a linear search
    • $class – table in the database to search from
    • $col – column in the table to match from
    • $term – input string
  • public createTagSearch($class, $string)
    • executes a basic unordered tag-based search
    • $class – table in the database to search from
    • $string – input string
  • public countResult()
    • returns a count of results matched
  • public getResult()
    • returns result for when a single result is expected
  • public getResults()
    • returns result for when an array of results is expected

Example – implementation
I have uploaded an implementation of that class specification that works almost out of the box (you’ll need to enter your database’s details etc). As I said earlier, it is based on Path to 2265’s code for the same functionality.


Disclaimer: if there are any errors in that code, I am not liable for any damage they may cause – the code is provided for demonstrative purposes only.

An example of how you could interact with the SearchEngine class from the ‘outside’

Other possible applications this example can do
The great thing about this implementation is the fact that it can be used for things other than just ‘normal’ searching. By using the standard search feature and retrieving a single result, you effectively have the main thing you need for making a dynamic website!

So if your website has something like a database-style section (many in the case of Path to 2265), you can get rid of those countless HTML pages and have a single page instead that calls upon the SearchEngine to find and retrieve the desired page data (indicated with a unique ID through a variable in the URL) in your MySQL database and display the information accordingly.

The best example of this on Path to 2265 is the Database section: clicking on any of the ships (take http://pathto2265.com/resources/apps/ship?ID=2095_ECS_J as an example) takes you to the same page for all of them, expect they all have a different IDs in the URL. A provided ID on that page is fed into the search engine via a standard search call and the single result is fetched and echoed into their destined positions in the markup for you viewing pleasure. It’s great, isn’t it?

Anyway, I think that’s it for today! I hope this has been an interesting read!

Site name simplication, PHP classes, and more

So I’m gonna be shaking up how I do updates for Path to 2265 from now on. Firstly, these updates are going to be more structured because I want to make them easier to read. Secondly, I want to make it so people can either briefly look at the change list or read details depending on what they want to find out. Also I am removing any set times for posting updates since I’ve missed almost all the targets for posting them these last few months. So with out further ado, here’s we go!

Sitename simplication
I have decided to drop the “Starfleet” part of the website’s name. I believe “Path to 2265” is a more clean site name and it matches the domain name now! Plus, both sides of the “to” are ‘balanced’ with four characters each now (as long as you’re not counting spaces)!

Reimagined search engine capabilities
For a long time, the searching capability and ship report part of the website have continued to rely on the fairly crude MySQL calls demonstrated all the way back in September. By early November, I upgraded to using PHP Data Objects (PDO) for enhanced security and code quality. Now, I have moved to class encapsulation as I become more and more proficient with coding in PHP! So with this object orientated approach, the code required to connect and query the database can be contained and interacting with the “SearchEngine” object can be securely controlled by only allowing certain methods with certain argument sets to be called. The search is also now (FINALLY) a tag-based search and I am currently developing an algorithm that can weight the results of one or more SQL queries and display the most relevant results to the user! I’m thinking about making a separate post to describe the process of doing this and its benefits in more detail, so stay tuned for that! But for now, I’ll leave you with this screenshot:

searchengine class
Most of the code has been collapsed from view since it may have sensitive data

Thanks to the new search engine capabilities, I have been able to reuse the SearchEngine class for other new features such as the website’s sitemap. Essentially, constructing the sitemap is done by querying a database for a result containing all the pages belonging to the same category. The SQL code is the same as a user searching (for now though, more about that later), so a SearchEngine object can be used without any problems.

Click here to see the sitemap!

SS Polaris progress
There is finally some progress on my second design project! I have taken a u-turn on the nacelle placement, and I have stripped some details that I thought made the design too advanced. In return, I tried to pepper in some details that make the design both more unique, polished and maybe industrial. Instead of having that weird dual deflector system mounted on top, the nose of the ship has been cut away to reveal one large deflector/communication array that I hope adds emphasis that the design relies on communication (since it is a diplomatic vessel). The new dish is also surrounded by some missile bays. The design will not have any energy weapons.

It’s quite funny, this design was developed without specs and was required to be developed in a week! Yet, it’s taken like two months or so to get to this stage… xD. Hopefully lesson learnt – ALWAYS iron out design specs ’cause it will just cause headaches later on.

Polaris: before (top) and after (bottom)

EXP-type Warp Reactor
I have added a new early UESPA reactor to the database. It is an attempt to explain how and why Earth had a matter/antimatter reactor (on deep space probe Friendship 1) so early on.

You can read about it here!

Progress gallery & milestones article
I’ve added these fun articles to show the progress and effort that was put into Path to 2265. Progress gallery is already up to do (mostly), but milestones still needs it content.

Chapter 1 proofreading
After discovering some grammatical errors on this chapter of the History report, I am currently in the process of thoroughly proofreading it!

Discontinuation of the “Todo” page
In all honestly, the page was only created for myself as a temporary tracker whilst I worked on the website. It was a place where I could list issues when I found them for later solving. Now that I use GitHub for issue tracking and source control, it has become redundant and will be removed from the website soon.

What’s the come!
My main focus is developing the search capabilities further right now. I soon hope to have an intelligent tag search with proper result ordering and sorting.

SS Polaris is nearly completion. So I might roll that out soon. The design documentation for both SS Voyager and SS Polaris need proper attention and revamping.

Chapter 2 (“Space Boomers”) should be completed in the next few weeks too!

And I think that’s that for today!

An interesting term!

As of last Friday, I’m now off university for a few weeks. I thought it might be neat if I make a post about what I have done these last few weeks for university, so here goes!

“Project FallingStar”
…is the single biggest thing I have been involved with this term. For the Professionalism module, we were put into groups (four, five (as it is for ours) or six people) and tasked with planning and building a 3D game from scratch whilst still learning the engine we have to use (Unity). I am pleased to say I have thoroughly enjoyed the project so far! The idea for our game is that the player builds modular space probes to send out on exploration and defence missions in the solar system. Despite initial doubts that our idea was too ambitious for a bunch of UNI students, our team (designated Team 1) is working well and our recent demo was well-received! My main contributions to the team have been physics programming (producing the gravity model) and leadership (defacto, since it was something that I naturally slipped into rather than being designated).

“A little peak” – credit to team member Luke Probert, who developed this splashscreen!

OpenGL coursework
This coursework was also fun. In the Computer Graphics module, we have been learning the basics of OpenGL and the assessment was to compile a 2D OpenGL scene that makes use of advanced OpenGL features (compared to just using immediate mode rendering) such as Vector Buffer Objects (and Vertex Array Objects), hierarchical modelling, and transformations. Whilst I have to wait for my grade, the demonstration I have to my lecturer was well-received!

Python + Pygame
This coursework was interesting ’cause I both did and did not enjoy it. The coursework was split into two tasks; building a missile command game clone with Pygame and then developing a small physics sim “Marble Madness” with a lecturer-created engine. Both tasks had their merits, which for me was mainly the fun of programming. What I did not like was that we could only develop the second part on Linux since the engine (PGE) is Linux-only. Whilst I have Linux at home nor is Linux THE problem, there is really only one computer lab in the university (where I work better at than home) that has Linux. This meant I could not always be guaranteed a computer since the lab was in high demand. I was even asked to leave for another class on two occassions, with can really be inconveniencing!

So yeah, that’s what I have been up to academically! In my spare time, I am continuing the development of Path to 2265 as another personal priority. I’ve recently made some huge underlying changes that I’ll be posting about this week!

Enjoy your day!


Using version control and forking, reviews are now overviews, SS Polaris delayed (again)

So I haven’t been making good on my Sunday updates in a while. In fact the last update was the 5th November! However, there are some big updates for today (Tuesday since I was busy this Sunday).

The website’s development is now being tracked and controlled with the version control solution Git, which in the simplest terms allows me to log every change I make to the website and reverse them if I made a mistake. It’s a huge safety net that gives me more peace of mind in case something goes wrong and effectively allows the core files of the website to be mirrored in the cloud somewhere. Git also allows me to branch the website into two separate solutions where I can work on multiple things without them interfering with each other.  When its time to compile the final product, these branches would be merged into one with the differences of each branch carefully accounted for.

Traditionally branching is used to allow multiple people to work on one project at the same time, but I have used it to fork the website into two branches:

  1. master: main website source. The layout and design of master is considered stable and I can add new website content without fear of issues.
  2. designDev: design development source. Here I am free to experiment with layout and design changes without fear of messing up the content. When a compiled change is polished to the point I want to apply it to master, I can merge the two branches’ stylesheets so the changes can be rolled out to public view.

The GitHub repository for Starfleet’s Path to 2265’s complete code and assets is hidden (a necessity since the PHP code of the website contains sensitive information such as the MySQL database password etc.), but you can view master as it is by simply using the site as normal or view designDev‘s progress by navigating to it via the link under “Site development” on the homepage. Whilst version control for the website was not necessary, I think its a cool thing that can really help the website’s development in the long run! Practicing version control is also an industry gem for software and game development.

In other news; Ship Reviews has been renamed Ship Overviews, a decision made in order to reduce any “authoritative” connotations from my opinions. These overviews are intended to give a brief about the ship in canon or non-canon, some basic background information, my opinion on the ship, and (if applicable) how I integrated the design into the website. To launch the change, the overview of SS Valiant is now up! SS Polaris has also been delayed again due to time constraints.

There are a few upcoming changes/fixes as well. A gallery of the website’s development progress will be up in Articles soon, intended to showcase how far this website has come! The search results are kinda messed right now and grossly out of date, so that needs fixing. Some layout fixes and improvements to the side menu will be rolled out soon as well (some of the first major things to come out of designDev).