And so it begins

Oddly enough, courses have already started. These units don't even have to be in until 3 hours time (12/90/14) so I have ages. Sort of.

This may be my final post. I never really did finish the game within these posts, but oh well. I can assure you that progress is slow but steady. I'm very busy so my time for these things is usually very short. You'll all have a great combat flight simulator soon :)

As for the physics classes themselves, they're not half bad. Join us, we have cookies. No, but seriously, one of our teachers has a 'biscuit rota', meaning that we get to eat free delicious food and do physics. Fun fun fun.

So far we've learnt that it is no longer m/s, but infact ms^-1. And for acceleration, ms^-2. That's pretty much it, except for going over the good old GPE and KE formulae, and being told that GPE may now be called EK. The teacher's not quite sure, which I am positive is a good omen for the rest of the course.

Thanks to anyone who spent a little time reading these (especially my form tutor who has a name that I have as much trouble spelling as his fellow Greeks have with dealing with their own money. Political debt banter!), i really appreciate it. Maybe I'll carry on with these some day.

Winchester Science Museum 2

The Winchester Science Museum also features an on-site planetarium now. Which I went to. Twice.

The shows there are very interesting, and the dome is one of the largest in the country. The confusion between your brain -which thinks you're stationary- and your eyes -which makes you feel like you're moving as the stars rotate around on the fixed screen- makes your brain think you're floating sometimes. Cool as hell.

The staff are very friendly and enthusiastic about their work (and why wouldn't they be?) and give fantastic talks on current astronomical events as well as old knowledge. I can now find a few more constellations in the night sky, as well as knowing how to find them.

Some talks are 'more sciencey' than others, with a few of them being aimed at younger kids, and the more technical ones are great. There's a detailed presentation on each of the planets (including their distance from earth and the sun, size, atmospheric and ground conditions, etc) and how orbits work, how spaceships and satellites navigate, how many satellites we have, their types, and a whole host of other things.

Summary: Space. Physics. Yay.

SPAAAAAAAAAAAAAACE!

Winchester Science Centre 1

This interactive museum (which was called Intech when I frequented it in my 'youth') is essentially a warehouse with nice architecture that holds within its square-based prism walls a collection over over 100 interactive exhibits. And it's awesome!

The museum mostly deals with physics displays, with everything from a bridge demonstration to crane operation to lateral spin. There are also displays on chemistry and biology, with a few technological showcases such as how mobile phone networks work, too.

There was also a sports section where a camera tracked your jump height and predicted how long it would take for you to run a certain distance. I found it to be quite accurate, and I managed to cover the distance in around 3.6 seconds with a couple of 10 year old absolutely trashing my time. (I need to work out, okay?).

Here's a shortlist of all my personal favourite exhibits:

• The flight simulator
• The crane
• The giant plastic ball twirley-whirly transportation machine (twirley-whirly being a technical term)
• The sound amplification dishes
• The interactive astronomical displays
• The large-feature recycling exhibit
• The biological displays (killing the dummy is fun)
• The light-beam activity
• The infrared camera
• The cafe (foooood)

The que for the flight simulator is usually worth it. Except for the fact that their joystick is incredibly dodgy and you have an almost complete lack of control over the aircraft.

Bletchly Park 2

Also at Bletchly were the renovated huts that the likes of Alan Turing once worked in. Most of the buildings and huts are fully renovated, with the current project expected to finish in 2020. It's hard to imagine the euphoria in those huts when the codes were broken thanks to a few silly German operators sending the same words/messages frequently with the same/similar codes (which was aided further by the fact that their cypher machines couldn't encode a letter as itself).

One of the encryption techniques was to turn each letter into a series of 0s and 1s (sort of like Morse code), and then for each letter in the message add a random letter to it in a boolean 'Exclusive Or' (XOR) style. The same (a 0 and 0, or a 1 and a 1) would make a 0 when added together, and different (a 0 and a 1 or visa versa) ones would add to make a 1.


Imagine you wanted to say "Hi". For the sake of this exercise we're going to assume that A is 0001, B is 0010, H is 1000, and I is 1001. We'll also assume that the key here is AB (as in, we're adding an A and then a B).

H + A = I
1000 + 0001 = 1001

I + B = K (if we count up in binary for the alphabet like we did here)
1001 + 0010 = 1011

HI = IK


The brilliant thing about this system is that because of how it works, when you add the key to the encrypted message it will actually decrypt it:

I + A = H
1001 + 0001 = 1000

K + B = I
1011 + 0010 = 1001


Amazing.

Computer Science Update

School hasn't exactly been very helpful with the whole 'No CompSci for you' thing. I know exactly as little as I did yesterday. Seeing as we get our timetables tomorrow and I haven't actually made a decision as to what I'm going to do yet, this probably isn't a good thing.

My CompSci teacher better name her kid after me...

Anyhoo, as I mentioned before I have a 1% chance of getting into North Notts College for the AS CompSci course. The other 99% seems rather dismal, however. In the likely case that CompSci isn't available at all this year I'm not sure what I'll do. I'll see if I can take ICT AS and A2 this year and then CompSci AS and A2 next year, but I feel like doing both qualifications (I assume A2 is harder and requires knowledge from the AS course for you to understand it) may be too much of a challenge in the same year.

Due to all of this, I may need to just pick a different subject for my fourth option and take the CompSci AS course next year and get by on that. Explaining my lack of an A2 qualification because my teacher was pregnant will look great on my CV, I'm sure.

Bletchly Park 1

Had an amazing idea. I can fit two bridging unit thingies into eachother. I can write about the Bletchly Park visit I made for another bridging unit. God knows why it falls under the subject of physics (the mechanics of the machine, maybe? No sophisticated electrical components and computer code in those days).

Anyhoo, the park was once an estate belonging to a wealthy family, which was commandeered by the military in WWII to intercept axis messages and decrypt them (most notably the Enigma and Lorenz cyphers). A lot of work was made by Alan Turing, who constructed the world's first computer to help with this.

This was the Bombe Machine, and it was incredibly big, with prop shafts and mechanics shifting wheels around with basic electronics all over the shop to turn several sets of 3-columned wheels around. The middle set would turn one increment for every complete rotation of the top set, and the bottom set would turn one increment for every full rotation of the middle set. There were 26 increments (one for each letter) and the system was set up in a sort of 'menu' where hundreds of cables would be set up in an array at the back of the machine. If the machine found a possibly valid combination it would pause until told to continue, with the possible combination to the Enigma code displayed on a separate set of 3 wheels.

Once the code was broken for that day (a new code was set at midnight every day by the Germans, with different codes for the SS, Navy, Airforce, and Army) work could begin on decrypting every incoming message on a modified Type-X machine, which was sort of like a typewriter. After midnight the whole process had to be done again, with a run on the Bombe usually taking around 15 mins. That's assuming it didn't stop and find a valid combination on that run. 'Twas a lengthy process, but many argue that it won the war.

How did we repay Turing? Well, he was gay. That meant that once the war was over he could choose either prison or 'hormone altering injections' to try and 'make' him straight. Arseholes. Instead he elected the fatal way out and the Earth lost one of its greatest minds.

And on that cheerful note, good night.

Goodbye Computer Science?

As most of you reading this will know, I was intending to take Computer Science for my A-Levels. Unfortunately, the only teacher who's qualified to teach us got pregnant, so the school can't provide the course this year.

This gives me a few options:

1. Where I'm timetabled for CompSci school will taxi me to a local college where they're doing the course. This will only work if their timetable doesn't clash with ours (and it's likely that it will), they actually accept us, and if they're doing the correct course.

2. I will instead take the ICT AS and A2 course this year, and then the AS and A2 CompSci course next year. Providing the school lets me. This would be quite good, because here's what I was previously intending to do:

Year 12: Physics AS, ICT AS, CompSci AS,  Maths AS
Year 13: Physics A2, ICT A2, CompSci A2

Instead, I'll be doing this: 

Year 12: Physics AS, ICT AS, ICT A2,  Maths AS
Year 13: Physics A2, CompSci AS, CompSci A2 

I'll still be doing all the courses I want to, just slightly differently.

3. I could pick a totally different option this year to replace the CompSci AS course and then drop it and take CompSci at AS or A2 next year (small problem; I think taking an A2 requires having an AS).

As you can tell, I'm in a bit of a pickle here.

My current situation.

The Four Basic Forces of Flight

For an aircraft to maintain straight and level flight it must match the forces of nature (drag and weight) with what it is able to control (thrust and lift).

For an aircraft to increase its speed it must accelerate. To accelerate, the force pushing it along (thrust) must be greater than the drag (air resistance) it faces. Doing so will naturally increase the drag as it is hitting more air particles per second, but it's not enough to stop the acceleration.

If the thrust was equal to the drag then the speed (whatever speed it is) would remain constant. Be it 0 or 100 KM/H. If the thrust was less than the drag, however, the aircraft would slow down (decelerate).

The same can be said for lift and weight. If lift is greater than the weight the aircraft rises, visa-versa it falls, and if they are equal the aircraft remains at its current altitude.

An aircraft can utilise these laws of nature (like it wasn't already in order to fly) by raising air brakes in order to increase the drag on the aircraft (larger surface area, and less aerodynamic) and help it slow down. Lowering flaps increases lift, making it easier to take off as lift is being generated more efficiently.

Below is a diagram from NASA, explaining the whole thing.

NASA's quite good at making things fly, so I'd trust them on this one.

Control Surfaces 2

I thought I'd make this two posts, because combined they're a bit too long, and it's another excuse to up my post count.

There are a few other control surfaces that I didn't cover before. Here's what they are, what they do, and how they work:

Flaps

If you've been on holiday to a foreign country within the past 30 years, chances are you've flown. You may have noticed that before take off something weird's happening to the wings. These are the flaps going down. Remember my little lesson on lift? Well, extending the distance that the air has to go over the top speeds it up, and in return you get more lift.

Whilst taking off and landing you want as much lift as possible. The former to get airborne as quickly and easily as possible, and the former to be able to come in to a landing safely at a low speed. You don't really need the flaps whilst airborne because you need just enough lift to get you airborne, not to go higher. This would be a waste of energy as you'd have to have the nose facing down in order to stop going up in order to maintain your cruising altitude, and less energy would be put into making you go forwards so much as 'downwards'.

Illustration depicting various flap types.

Slats and Slots

These funky things on the wing's leading edge are like little spacers that can be pushed forward in order to make the distance that air has to cover in order to go over the wing much larger. Once again; faster air, more lift. These are used at low speed for additional lift at takeoff, for the most part. They allow air to go through them from under the wing too, providing additional lift. The slat is the physical beam itself that extends from the wing's leading edge. The slot is the space it creates where it used to be, which air from underneath the wing is guided in to in order to have larger quantities of faster moving air on top of the wing to generate more lift.

Slats and Slots at work.

Trim Tabs

Trim tabs are like minor versions of all the previously mentioned control surfaces, with the exceptions of slats and slots. Trim tabs are small control surfaces that are usually at the very tip of the other control surfaces. their position is generally set pre-flight or during flight to counter any small instabilities of the aircraft. If you find that your aircraft yaws to port with no input from you then you'd set the rudder trim to starboard a bit to counteract this action, rather than holding the rudder pedals yourself. This way the aircraft can maintain full manoeuvrability, even if something is causing small changes of course.

Illustration depicting the position of trim tabs. Note that flap trim tabs are omitted.

Control Surfaces 1

Control surfaces are manipulatable parts of an aircraft that can be controlled by the pilot in order to change the direction of the aircraft.

There are 3 basic axis on which this takes place.

Yaw

The yaw of an aircraft is altered by its rudders. These are typically on the tail and turn in order to for air to make the aircraft 'brake' on one side, pivoting on that point due to the air resistance it meets. This resistance and directional change of airflow turns the aircraft side to side, in relation to the aircraft itself.

Pitch

Pitch is typically altered by the elevators. Some aircraft have canards that do this instead. the difference is where they are on the aircraft. Elevators are usually at the back of the aircraft, on the tail section. The flap up and down like the rudder turned on its side in order to make the aircraft tilt down or up in relation to the aircraft itself by providing more air resistance on one point and directing the airflow in a different direction. Canards are much the same, except they are at the front of the aircraft and fixated tot he fuselage rather than a tail wing.

Roll

The roll of an aircraft is how 'tilted' it is side to side. This is controlled by the ailerons. These are much like the elevators, except they raise and lower in alternate directions. Instead of combining aircraft to make the aircraft go 'up and down', one wing goes 'down' whilst the other wants to go 'up' (all directions being ambiguous and relative tot he aircraft), forcing it to spin on its axis.

Below is an illustration demonstrating what these control surfaces do and where they typically are on an aircraft.

A diagram depicting how basic control surfaces work.

More Efficiency

Ever wanted to do the same thing over and over again in some code, but don't want to write out the code for each individual thing? I feel the same way. It's too much effort and makes your code too large. Therefore, we use a for loop.

However, I don't feel like I adequately explained what was going on before. You see, I need to fill up content on this blog to get into an A-Level course and i really need to spam as many posts as possible. Leaving out information to be filled in later is a great way of accomplishing this, and it's how some companies and religions (*cough* Scientology *cough*) make a lot of money.

Let's say that you have loads of buttons. When you mouse over them, you want them to all do pretty much the same thing. However, writing the code for each button would be non-efficient. Therefore you'd construct a table of all the buttons, and in that loop write the function for the iterated button in question. In the functions you'd write code that applies to all buttons when moused over or whatever.

This can leave you with a lot of flexibility, as if you make the code as ambiguous as possible you can make each button seem more different and customised than it actually is. You can check out what I've done similarly below. As you can see, the loop runs through a series of buttons, and sets up a function for all of them. This way, if I want to do something for multiple buttons I only need to write the one function and be done with it. I can edit it later, change it, etc, but I only have to do it the once.

For looping to clone functions efficiently for multiple buttons.

A limitation with this method, however, if that this efficiency only goes as far as doing the same thing for the buttons you choose. If a button needs its own special thing (like sweeping in a frame or whatever once clicked) you'd have to do that separately, as you wouldn't want all buttons to do that.

A similar idea would be to write out the code like I've done, but add a function at the bottom wherein it checks a table. If in the table there is a value that has a key matching the name of the button it'll run the value as a function. I could write a table of functions and name them after the key, and this for loop would run through them individually.

All of these skills can be used in a variety of applications.

Stalling

A stall is caused when the airflow over the wing is interrupted to the point where sufficient lift is no longer being generated. This means the aircraft is no longer flying so much as falling. Control surfaces tend to become very unresponsive, air intake to the engine can be reduced to the point where the engine cuts out, and eventually death.

The below images depict it rather well:

The point of  "uh-oh".

Geronimo! 

In order to get out of a stall you need to tip the nose of your aircraft down a little, increase thrust, and pull up to level flight again.

As for implementing the physics of a stall in Air: Force, I have two options:

1: I check the aircraft's CFrame.lookVector constantly to compare it with the aircraft's speed and turn the lift on/off (simplified physics).

2: I edit the aircraft's lift dependant on the speed of the aircraft (faster whilst headed downward, slower whilst headed upward).

Both are not exactly accurate representations of real-life physics - thanks to ROBLOX's physics engine - but they should look and feel like pretty much the same thing in-game.

Servers

ROBLOX has fairly recently come out with place API, which allows you to create place instances from a server script in your game. Using this, I am able to create a server for people to play a game in for multiplayer. It's essentially like hosting your own server on an online game, but for free. In this post I'll outline some of the details of the CreatePlaceAsync() API.

CreatePlaceAsync is the call on the AssetService:

game:GetService("AssetService"):CreatePalceAsync(name, templatePlaceId, description)

name is the name you are giving to the new place instance, templadePlaceId is the ID of the place that you are copying to create this new place instance, and description is the description of the new place.

templatePlaceId must be the ID number of a place that is verified for cloning with CreatePlaceAsync.

You have to manually allow a place to be cloned with the API.

This call then returns the ID of the created place, allowing you to teleport the players there with the teleport API.

Data Usage

ROBLOX has an API called Data Stores. It allows you to save information on a key/value basis that can later be accessed or used. This is useful for things like saving a player's settings, scores, and inventory.

However; using the API can cause problems because of ROBLOX's throttling rates on this service. Currently they allow 60 + (10 * number of players) DataStore accesses per minute, with left over requests being stacked. This means that you have to be very careful when using it - as a breach of the throttling rate will cause your script to error and the game to break (believe me, I have experience with this).

You cannot just request things from the data store willy-nilly. You should save things from the data store that are important to values or variables within your code, and then access the value/variable when needed later on, instead of the data stores. This would only work for things that aren't subject to rapid change, such as a user's score or settings to be loaded when they join the game and saved once more when they leave.

It is also important to consider when you should refer to the data store. You can't save and load things all the time, so you should carefully pick when to do so. Making your own counter of how many requests are available and subtracting from it whenever you access the store, adding to it every minute, and waiting until there are sufficient requests available before continuing may be a good idea. We've already acknowledged that we should load all pre-load game data at once at the start of the game to save it in values/variables, but what about after that point?

After you've loaded pre-load game data (preferably saved in a table/array/dictionary format for maximum DataStore efficiency) you probably won't need to actually load anything else, unless you're doing some funky cross-server communication thing - in which case the strain on the store will be so great there probably won't be room for much else. The only other real matter is deciding when to save. Saving all a player's data in a big chunk when they leave may leave you open to errors, crashes, and data loss if there is a lot of data to save and/or a lot of players leave at once. Therefore, you should save at strategic places throughout the game.

Modern games save most round-based data at the end of a round or mission. That way most of the non-critical data is saved here, so critical data can be saved later when a player leaves. That way extra data doesn't clog up the throttling rates. Therefore I will probably be saving some data at the end of a round or mission in Air:Force to free up my DataStore requests.

I'm not exactly sure why ROBLOX imposed these throttling rates (probably to do with their own server access limitations, we don't want to bring down ROBLOX's server farm after all), but at least they now stack. I only hope they invest in more servers so that us developers can save data more freely.

Protecting Data

Data is passed back and forth all the time in a game. Information on scores, a player's position, various events, etc. Transferring data safely is a must. Therefore, encryptions and other means of preventing data being stolen or being tampered with in transit is very important.

Hackers or exploiters can very easily get the values of Value instances these days, so keeping data as an internal variable of a script (which can't be accessed) or in a folder such as ServerStorage is usually needed. Referring to external variables in code (or just saving/reading them in code) that is not human-readable or is very hard to figure out can stop a player from cheating/hacking/exploiting and editing data.

Protecting data from being accessed in the first place is also probably a good idea. There are various ways to detect exploits occurring and who they're from (such as sudden or unexpected value changes, etc). Detecting that someone has done something they shouldn't have done and then removing them from the server is a good way to go about this. Numerous other safeguards such as detecting loadstrings being enabled from the chatbar would also help
.

Jet Engines

The jet variety of engine is generally very powerful. It's why they're used a lot. You've probably been on a plane with a whole four of them before. But, how do they work?

In essence, air is sucked out of the front and pushed out at the back (save the dirty jokes please) with various compressions and reactions happening in the middle (stop giggling) to make it all work.

I feel like the below gifs (they may take a while to load) adequately explain the process without me needing to actually write much. Drinks all-round guys.

A general overview of a jet engine.

A more detailed view of the core mechanics of a jet engine..

A closer look at 2 different types of jet engine..

I bet there's a video on the web of someone cooking on one of these. Gotta love Hot Shots. Great movie.

And there you have it. jet engines. In pretty moving pictures and minimal writing from me. Oh, if only A-Levels were actually this easy.

Target User Audience

Considering that Air: Force is a combat flight simulator, I obviously don't want kids who are a little too young and impressionable to be playing it. I also want it to be popular with the type of person who would play such a game, and is on ROBLOX. In this post I'll briefly analyse what needs to be considered to make the game popular with the right audience.

As for those too young/impressionable to play, ROBLOX has a 13+ system that allows you to check if a player is over the age of 13. They use this so that kids can't buy gear guns on the site. This also means I can check to see if they're old enough to play. This limits the amount of people who can play the game, but it means that the game is more appropriate and I can do more with it on an age-basis. Of course, it's easy to lie to a computer about being born in a different year (just take a look at all the 10 year olds on facebook) but not everyone will do it. I hope.

ROBLOX also lets you detect the account age of a player. This is the age (in days) of the account. Therefore I can discriminate against accounts that have only been active for a very short period of time, so that only users who have gotten to know how ROBLOX works and can fully appreciate the game (or have the attention span of someone mature enough for the game) can play it.

Now, in order to make the game popular with other combat flight simulator enthusiasts one must consider their interests whilst staying true to the game's form. More than one aircraft would, of course, be paramount. Customisation is also fairly sought-after (just take a look at the emblem creator on Black Ops 2), as it allows the user more creative control over their game. For that reason, i will probably create my own Squadron Logo customisation widget within the game.

A user of combat flight simulators is probably between the ages of 15 and 25, so references to appropriate things would probably be a good thing. A more high-tech stylization of UI would probably also be called for. Broad functionality, with limitations or explanations so that the user isn't overwhelmed by the freedom of the game is also a good idea.

One must also consider that something too complicated would put some players off. Therefore, the amount of buttons you need to press to achieve core aspects of gameplay (i.e, firing missiles, speeding up, etc) should be limited to a single key press for faster and more intense gameplay whilst cutting out confusing controls. A controls customisation screen would therefore be a good idea too, so that players can set up their own preferred keys for actions. A default setting in-case of accidental changes should also be present and available for use.

Conclusively, the game should be aimed at 15-25 year-olds with experience on ROBLOX and include features to block people who are too young and captivate those who aren't.

Lift

Lift is essential for flight. Without it we'd be rather stuck here on the ground. Lift itself is not a force, but the result of other forces.

Air flows over a wing (or aerofoil) and is separated at the leading edge. It goes above and below the wing, eventually meeting at the end (trailing edge). The wing is shaped so that the air flowing over it is accelerated and goes faster towards the trailing edge than the air below the wing (along the chord line). This means there is less pressure above the wing than below it, so the wing is 'pushed up' (lift) and takes the aircraft with it.

This diagram shows how a wing generates lift.

In the case of a rotary-winged aircraft such as a helicopter or Osprey (those things are bloody awesome) the aircraft has its wings on an axle that rotates very quickly. Sort of like a giant fan. The lift is then generated to pull it up and hover, rather than having the aircraft to need to be moving forward in order to push air over the wings and generate the lift to take off.

A bloody awesome Osprey.

As I stated in a previous post, ROBLOX is a vacuum-like environment, and not all aspects of physics are accounted for. Therefore, moving an aircraft forward or rotating its wings very quickly won't generate lift on its own, and scripting it to do so can be very tricky. The aforementioned BodyMovers will probably come into play in the case of Air: Force, with some sort of thrust in the Y axis being provided based on speed. In which case, the physics will be simulated and won't precisely imitate the real world, but it should look and feel like pretty much the same thing.

Mouse Manipulation

I seem to be fond of the word manipulation. Probably not a good thing, but when put into practise it can be - such as making an awesome mouse icon.

You are able to do certain things with a player's mouse on ROBLOX, and read certain values from it (such as the size of the icon, its position on screen, etc). There are a few different ways of getting the actual mouse to manipulate (there's that word again) it.

The :GetMouse() method, when called on a Player instance, will return said player's mouse. You can then mess around with it at will, but it doesn't let you change the mouse's icon (ROBLOX's API is wierd, don't ask me). If you want to change the mouse's icon you have to use the .Equipped event of a Tool, or the .Selected event of a Hopperbin. The function/event returns the mouse as an argument. This is quite annoying as a character is therefore required to actually use the tool/hopperbin.

The best way is to :Clone() the tool into the player's character. That forces them to fire the .Equipped event, which you can detect and then connect it to a function where you delete the character (and tool) so the player can't reset and ruin your sequence, and then do anything else you want to do with the mouse within the same function.

Assuming that you already have the tool ready somewhere, it looks something like this:

tool.Equipped:connect(function(mouse) --mouse given to us by Equipped
character:Destroy()
mouse.Icon = "" --Mouse icon link here
end)

Below's a picture showing it in use.

Clever use of a tool to manipulate a player's mouse in a GUI gamestate.

For loop for efficiency

Most coding languages (or at least the good ones) have some sort of for loop. This is where you can iterate a task a set number of times given specific conditions, and it helps keep the code shorter.

Say, for example, I wanted to have loads of buttons all do the exact same thing when your mouse goes over them. I wouldn't create a load of individual functions for each button, because that would be very inefficient and take up a lot of space in the script! Instead I use a for loop. I iterate through a table (list/array) of the buttons, and connect a localised function to the MouseEnter event of the button that is being referenced on that iteration.

Using this method very mundane or even complex tasks can be solved with ruthless efficiency. Not only that, but if you decide you want to change something you only have to do it the once. I don't want to have to repeat the same code over and over again now, do I?

Additionally, these for loops can be built upon. You can have for loops within for loops and references within references. It may look confusing to someone not familiar with the language, but a quick overview on how it works should clear up any confusion.

A fairly intricate example of efficient  coding for GUI buttons with for loops.

Fledgling Flight

ROBLOX has instances called BodyMovers. When applied to a physical object they enact a force on that object. The force in question depends on the BodyMover used.

In the case of the aircraft for Air: Force which are very small and light (enabling me to do certain things as a developer that I couldn't do with a scaled up aircraft) and ROBLOX's physics engine isn't spot-on. The world is in a vacuum, and more complicated physical interactions such as lift aren't simulated on the platform. This means that not only can I not generate lift via wing shape and a BodyThrust BodyMover, but forces are very very touchy and delicate.

For these reasons I have to simulate my own physics on ROBLOX by working with its engine and making a sort of simulated pseudo-physics within a physics engine. The writers of inception would have a field day. I'm starting to feel like DiCaprio already.

As previously mentioned, ROBLOX already has basic physics facets that are immediately ready to use. You can get the 3-Vector directional velocity of an object and its magnitude (which is used for calculations of speed in my own mini physics system and displays on the HUD) and gravity does 'pull' objects down ( Vector3.new(0, -1, 0) ).

What I have to do is essentially make a free-floating object that almost ignores gravity and moves 'fowards' in the direction it's pointing at a certain speed. Then I have to account for the physics of stalling, etc, which I'll get on to later.

You can already tell that this is going to be fun, can't you?

A little GUI Manipulation

ROBLOX allows its developers to script things in the Lua programming language (call it LUA and you'll be shot) to create interesting and intricate things. You could code the launch sequence of a rocket that you built, make a computer operating system, code a fully-fledged game from scratch, or manipulate existing instances.

With Lua I've created what I consider to be a very nice interface for Air: Force. As you can see in some screenshots below of both code and GUI a lot of it is just tweening and making transitions work, but there is a little bit of more complex methodology there. Simple manipulations of GUIs make for great interface/user feedback and transition between GUI elements.

Efficient coding is always a must. The smaller the file size and the more quickly it runs the better the game. It goes without saying that some inefficiencies can probably be found within my own code in the screenshots below. Rest assured; I'll fix it as development progresses.



Click on an image to make it larger.

Meticulously searching for assets to preload on the server via the ContentProvider in the ClientManager. Code is cloned in a LocalScript to be replicated for each client. Also in this picture: configuration for new players entering the server.

A view of some of the code for the loading sequences of the game in the client-side LocalScript.

Ruthlessly efficient coding for the buttons in the main menu.

And that's pretty much how the whole thing works. Sweep in the GUIs, detect when a button is clicked, and on said event perform an action (function).

In Lua terms, it looks like this:

--[[

Code to sweep in UI here

]]

uiButton.MouseButton1Click:connect(function() --The event, connector, and function

--Perform some action such as a new transition here

end)

Well, more or less anyway.

Laziness and GUIs

Minimalism has certainly been an emergent theme on the internet recently. Gone are the cluttered websites of the past with content spilling all over the place, and in their place are cleaner and more organized looking sites. This is great for people as lazy as me, because it means that less work needs to go into a design to make it look good to the general public. Minimalist GUIs are simple to make and they look gorgeous when done right, so that's what I hope to do with Air: Force.

Whilst Air: Force's GUIs won't be written in HTML and CSS like the designs of most minimalist websites are (ROBLOX has its own GUI engine where you utilise instances) certain recurrent themes do emerge; such as basic colour palettes and organised layouts. The less clutter the better.

You can check out the game so far yourself - you have to install the client engine for ROBLOX, but it shouldn't take up much room, and if you don't intend to use it again you can just go ahead and un-install it afterwards - if you want through the link above, or just take a look at these screencaps if you want to be boring like that.

If you don't develop on ROBLOX yourself then some of these images may seem a bit alien to you. Quick explanation: the 'Explorer' pane to the right of the screen illustrates the hierarchy of all the game's instances, the 'Properties' pane below it displays the properties of any selected instance(s), and the big screen that's more or less in the middle shows the game 'world' itself. The 'Output' pane below it shows error/debug messages for testing the game.



Click on an image to make it larger.

A blank view of the initial loading screen.

The loading screen in action.

A gorgeous colour palette.

As you can see, the GUI isn't cluttered. There are hardly ever more than 4 colours on screen at once, which helps keep things looking simple and clean. The blue/grey matches the idea of aviation and combat (it's a mix of gun metal grey and stormy sky blue) and the highlights of a more toothpaste/cyan colour pop in contrast.

Because GUIs are dealt with as objects of data that are then transferred into pixels on a screen by ROBLOX's rendering engine it is very easy to overlay and use ZIndex manipulation to perform elegant GUI trickery. Two cyan lines on the Blue-Grey background? The background invading the Cyan? Nope. A simple overlay of a smaller bar on top of the cyan bar that matches the colour of the background.

As you can see, GUIs are a heavy focus for me. To make a good game the interface needs to be good. It should be obvious, because it's what a user interacts with (sort of the definition of interface), but many games don't have something that feels smooth or clean enough to really 'bond' (if that's the right word) with the user.

Let's hope it looks better than MySpace did, at any rate.

An Introduction

Well, this is nice, isn't it? My own blog. It's doubtful anyone will read it other than my poor parents and teachers that I force to drown in a misshapen fog of unplanned words that fight for place as my mind races along somewhere up in the clouds.

Somehow the confusion of language in my mind all gets transferred to my fingers who batter a keyboard on my little Toshiba laptop that is the powerhouse of this whole sordid operation without loosing too much meaning in transit, and from there it's up to the internet to let you view my inconsistent bleatings.

Firstly, however, a quick introduction to and clarification of my nickname. Which I seem to be unable to change. When I was younger I somehow managed to get on the global high score leaderboards for some game or other. I was smart enough to not put down my own name, and not boring enough to enter a dull pseudonym. Instead, I put wowzaboy. It sounds better written down and not said aloud. My being male, amazing, and superb talent for making people say wow (whether in disbelief or anguish is up to you to decide) contributed to the name. Ever since it kinda stuck, and I apparently attempted at making a blog some time ago with the same name and my current email. I tried changing it but apparently that didn't work, and I quite frankly can't be bothered to make a new account. Enjoy readiong a blog written by someone called 'wowzaboy'.

Now on to something more interesting. The purpose of this initial post is to highlight the general point of this blog and its future after its primary directive to get me into A-Level courses is complete. Don't you just love Michael Gove and the English school system? Me neither.

As indicated, this blog is here to get me into A-Levels. That's pretty much it I'm afraid. After a long relaxing period in which I did absolutely bugger all  after my GCSE exams until the proper summer holidays started I got a letter. Inside it was the English equivalent of manure so rich a farmer would sell his children for it. I have to complete 'Bridging Units' and rack up 300 'points' to get into my preferred A-Level courses. Optionally, an additional 200 points would secure me a 'UCAS Recommendation'. Hoorah.

At the time of writing I've trawled through about 7 tasks on MyMaths and written a review on a python programming guide which should net me some nice points, and to my understanding a blog on a specific subject with at least 12 posts should get me a nice 100 points. That's where this CSS graveyard of a blog comes in, as explained below (I like short paragraphs).

For A-Level I intend to take AS Maths, IT, Computer Science, and Physics. Now, maths sucks big style - as if you didn't already know that - but I can't make a blog for it. I can only slave away on MyMaths. Therefore, if I make 36+ posts - 12+ on each subject - I should theoretically gain 300 points. Not only does that get me into A Level, but in conjunction with the tasks I've already completed/will complete it should get me that UCAS recommendation.

<sarcasm> I think at this point my Nana would like me to point out that she totally didn't nag me to do this. </sarcasm>

Being an avid user of the ROBLOX platform (yes the community is full off moron 12yo kids, but then again every 12yo kid is a moron - and at least it gives me a nice player base/target audience) where I play around with GUIs and physics -quite often to create games- I thought that a great way to encompass everything I love, -plus the A-level Bridging Units, would be to wrote a blog focused on the development of a combat flight simulator. I'll probably never finish it, but at least it'll give me something to jabber on about until Tuxford Post 16 agree to let me in.

The physics aspect is focused on the actual flight physics within the game, whilst the computer science aspect will be the coding, and the IT will be focused on the interfaces and data usage. I'll make sure to tag the posts somehow so that you know which subject I'm talking about in case my illiterate mind doesn't quite make it clear.

As for the future of the blog latter to the completion of the bridging units; that'll probably be given over to further development on ROBLOX, various ramblings about something or other sciencey/cool that you may find interesting.

Bon Appetite.


05/09/14 Update: Due to course changes I cannot do AS Computer Science and am instead taking AS and A2 ICT. Therefore I have added an ICT tag to my CompSci posts (and kept the CompSci tag) as they are now dedicated to ICT instead (it's basically the same when it comes to the blog) so that my CompSci posts are still worth something. Class them as ICT posts.