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.