OldSchool Runescape Game Review

OldSchool Runescape (abbreviated as OSRS) is an MMORPG (Massively multiplayer online role playing game), released in 2004 on personal computers and 2018 on mobile phones. Although old, the game still has a large active player base, 100,00 players daily.

Thrown into Gielinor, the world’s name for Runescape. The player is surrounded by a fantasy medieval theme. A player must first complete the tutorial on Tutorial Island

Fun factor

Everyone starts the same in Runescape, there are 26 different skills the player is given. A skill starts at level 1 and ends at level 99. Every skill is independent and unique in its own way. An example of that is:

  • 60 Attack allows you to equip dragon weapons, you can hit higher damage and do special attacks.
  • 40 Defense, rune armour is now equippable, a strong armour that helps you in combat.
  • 14 Runecrafting, able to craft fire runes to use in magic attacks or teleportation around Gielinor.
  • 85 Fletching, craft your own magic bow along with dragon arrows for the best range setup.

Platform differences

Desktop

Mobile

  • GUI works well
  • GUI can be hard on smaller phones and seems like it could be improved
  • Performance is great, can be played on any computer
  • Performance is heavy for what the game looks
  • 3rd-party clients are available for enhanced or easier playing experience
  • Can only play on the official client

 


PC version
Mobile version

Controls and game play

Using a point and click user interface design, it is very simple and easy to understand. Runescape’s PC interface is used for the mobile. In my opinion, it is a bad design and should be redesigned, my reasoning is that you shouldn’t be using a 15 year old interface for a 2019 mobile game.

Graphics

Low-poly and mediocre textures, the game still features the same objects and terrain from its initial release in 2004. The sky is black and the render distance is low.

OldSchool Runescape does not have much to offer in this aspect. Running bare-bone graphics means that it can run on low-end computers and mobile phones great.

Lumbridge

Above, is a town named Lumbridge. It is the first town new players will spawn in after Tutorial Island, a famous island to every veteran of the game. The bridge connects to the entrance of Al-Kharid desert and various farms belonging to Lumbridge.

Sound

Runescape offers ambient noises, background music, sounds based on combat and other various skilling. MIDI format is used for all of the game sounds, although outdated, it still fulfills the immersive experience.

Replayability

Starting over again can feel monotonous if you do not have a new specific role. It becomes not very fun further you go, as you feel like you have already achieved the goal.

References

Lumbridge. (2019). Old School RuneScape Wiki. Retrieved 5 August 2019, from https://oldschool.runescape.wiki/w/Lumbridge

.

Slither-Classic

Slither-Classic is a game that emulates classic snake game and slither.io the main objective that drove its design was the result of combining the two games.

A player is a blue dot in the middle of the screen, to start the game a player must only have to press the control keys

Slither-Classic Controls

  • [W A S D] OR [LEFT, UP, RIGHT, DOWN] Arrows to move
  • [SPACE BAR] to speed up

Objective

The player must at all cost try to avoid colliding with other colours that aren’t the same colour as there head.

You can download a copy of it here

Remote-Control Claw

The final prototype remote and claw

The Remote-Controlled Claw is an assistive device designed for people who may have troubles in mobility or trouble working complex machines such as the elderly. The robot uses a simplified remote control for simple use of the robot itself, allowing the user to be able to drive the robot into places where it would not have been possible with a regular humans hand.

The robot has a motor fixed to both sides with a touch sensor from the remote control to work the claw on the front of the robot. All of these functions are made possible by connecting both bricks with Bluetooth, with extensive testing and developments to enhance the abilities of the machine. In doing so we believe that a robot such as this could be a success on a commercial market, as the need for a simple and lightweight assistive device is one that is lacking for those that need it.

As the controls to operate the robot are very basic everyone that uses it could be able to operate it without much problem, the only downside to the robot is that there are no guides to tell the operator if the claw is lined up correctly to pick up the object surrounding it. A sound or light flash to signify this maybe would’ve helped the owner use the claw easier, although there was a clear plan to not over-complicate it given what the target audience would be if put on for sale in a commercial aspect.

Top- Remote / Bottom- Claw

Group Members – Calen & Daniel

The Whiteboard Wischer

An initial prototype of the robot climbing up the vertical whiteboard.

Our robot is designed to help teachers, and other whiteboard users, to automatically clear a whiteboard of writing. Using magnets to hold the EV3 brick up, the robot is able to effortlessly glide across vertical surfaces and uses felt along the bottom to erase the whiteboard marker.

 

INSPIRATION

Xavier said, “Ooh… maybe we should do a whiteboard wiper.”

“No, that’s dumb,” said Jack, “we should do a Whiteboard WischerTM

“Alright,” said Matthew.

 

PROCESS

We started the project by brainstorming ideas and solutions on a provided document. We designed a robot and got to work recreating it with LEGO and the EV3 brick.

Our initial prototype was a brick atop wheels with a bumper on the bottom which pushed the wiping device along the whiteboard.

A mix of duct tape and magnets to create a blanket

We ran into a problem when trying to get the robot to climb up the vertical whiteboard. Using duct tape and magnets brought in by Xavier, we created a blanket that would stick the robot to the surface. Some complications arose from this design. We used so many magnets that the robot couldn’t be moved using the wheels, and the magnets were too tall and they stopped the wheels from reaching the whiteboard.

After realising our last design suffered from an over-abundance of magnets, we decided to scrap the blanket idea and start over. This time, we chose to strategically place the magnets in places that would allow the robot to not only stay on the whiteboard, but move around as well.

 

Magnets duct taped next to the wheels

Placing two of the stronger magnets next to the wheels, the robot’s wheels would stay attached to the whiteboard, and could move around too. Everything was working swell, until the magnets decided to disrupt the peace again. One of the magnets was getting stuck to the whiteboard instead of hovering over it and this caused the robot to go up on an angle instead of driving sideways.

Next, we had to come up with a way to control the robot. There were two options; create a remote control, or automate the robot to move around the whiteboard. Obviously the second option was way cooler so we chose to try make an autonomous cleaning robot. We started by creating a simple program that moved the robot forward (creatively named ‘FORWARD’) and tested it on the whiteboard. The test was a success, so we moved on to harder programming.

Using white reflective tape, we could use a light sensor to… sense the change of light. If taped around the outside of the whiteboard, the robot could tell where the edge is. We placed light sensors on the back and front.

Finally, we readjusted the magnets (again!), in order to place a proper wiper. We moved the magnets to the centre of the robot, and put felt over the top. The magnets pushed the felt on to the whiteboard allowing it to wipe instead of glide over the top.

Felt along the underside of the robot, with a light sensor on the front, and one on the back

 

PROGRAM

Here is our final program (click on it for a larger picture)

Our final program

 

Bug Glove MK IV – Tim, Jonathan, Jayden

Our project is a haptic claw and car controlled by a glove and D-Pad. It could be used for precise operations.

The way we did this is we had it set up so when the buttons were active the glove would lock and when the glove moved the claw closed.

The original concept for the Bug-Glove was to have it automatically lock when the pressure sensors are pushed in.

This was later removed for safety reasons concerning malfunctions.

Code for the car and claw

STAGES OF BUG GLOVE

Bug Glove MK II- The original prototype, basic frame, basic coding and lots of glitches

Bug Glove MK III- Larger wrist strap

Bug Glove MK IV- The later model, advanced frame, advanced coding and few glitches

Some of the code for the glove

 

 

Remote Control Obstacle Course – Dylan & Connor S

Our haptics project is a remote controlled robot vehicle, with a built-in timer, put into an obstacle course for people to race around.

The robot and the controller are connected via Bluetooth. The robot uses light sensors so that it does not fall of the table or go over the boundary lines. The controller uses touch sensors to increase and decrease speed. We used haptics in the steering so that people cannot over steer. Detects finish line with an infrared sensor and stops the timer and cuts controls.

We chose to do an obstacle course because we wanted to do a spin on the classic remote control car. The obstacles are because we wanted to make the game difficult. Most of the obstacles were made out of Lego because we wanted to incorporate it as much as possible.

We learned that our robot was hard to control when the speed was greater then 20. We also learned that there are better options then touch sensors for changing speed.

The obstacle course was good and worked well. The only component that did not work where the spinning blades on the front of the robot.

We would modify the controller so that it is easier to use. The speed of the robot would also have to be reduced so that more people could finish the course without crashing.