A Simple Side Scroller Design

This post is part of a series on beginning game creation with Monkey-X. You can find the previous article in the series here.
——————-

For your first game with Monkey-X (maybe your first game ever) we are going to create a simple side scrolling shooter.

Whenever I am getting ready to make a new game, I usually start with a simple 10 point check list called 10 things every game needs. I borrowed it from a fellow name Mark Rosewater who does some game design on a game called Magic: The Gathering for Wizards of the Coast, and we are going to use it here.

This is not the only way to design games nor is it super thorough, but I have found it useful to go through this exercise when I am getting ready to make a new game.

1: A Game should have a Goal

Your game should have pretty much 1 major goal. This is often the way the player wins the game. Like Checkmate in Chess, or getting the enemy flag to your base in some Capture The Flag.

For our side scroller, the goal will be to beat the Big Bad Boss.

Simple goal, to the point.

2: A Game should have some Rules

Whether it is a classic board game like Chess or an FPS like CS:GO, games need rules so the player knows what they can and cannot do to achieve the goal.

In Chess the rules layout which pieces can go where. In computer games, the rules are usually built into the code of the game and manage things like keeping track of the score and keeping players from doing things they should not be able to.

For our game we will have simple rules.

  1. The player can move up and down, back and forth but cannot leave the screen.
  2. When the player or an enemy gets hit by a bullet, they lose armor.
  3. When the player or an enemy’s armor gets to 0 (or below), they are destroyed.
  4. If the player destroys the Big Bad Boss, they win the game.

    5. This is a simplified set of rules, but you get the idea.

    3: Players should be able to Interact

    If you do not have a way to interact with your opponent, you might as well be playing by yourself.

    This is usually more relevant in a multiplayer game, but we will pretend the computer is a player in this game.

    Our interaction mechanic is shooting and being able to destroy enemies.

    4: Players who are behind should be able to Catch Up

    There are few things worse than playing a game, falling behind and never having a chance to get back in it. Might as well give up at that point.

    A lot of sports games have this built in. When a team scores in Football or Basketball, the other team gets the ball and a chance to score.

    In video games this is often accomplished with powerups or extra lives that you can get.

    We will build in both powerups and extra life mechanics into our game.

    5: A game needs some Inertia to make sure it ends

    Games that never end make players get tired of them very quickly. The ideal length is just a little less than what the player wants to play.

    Regardless, you need something that pushes your game to end. Lots of games do this with a time limit. When the time runs out, the game is over.

    We will sort of do this, but manage it by having our player move forward in the side scroller at a constant speed, and when they reach the boss, they have will beat him or lose.

    6: Games need some element of Surprise

    If you always know what is going to happen next in a game, it quickly becomes boring. Adding a little unpredictability or hidden information can make a game more fun.

    For our side scroller, we will randomize the enemies and some of their movements to keep the player guessing.

    7: Players need to be able to use Strategy to be able to get better at the game

    If the game is completely random and no player skill is involved, players will see it as unfair and that there really is no point to play.

    You need to have some element that the players can control and master to help them win.

    For our side scroller it will be using their ability to dodge enemies and get kills. Maybe not the highest form of strategy, but not left up to chance.

    8: A game should be Fun

    You will notice that this is not number 1 in the list. Often the fun will come out of the other elements that make up your game and fun is hard to predict.

    Often you find a fun mechanic and build your game around that. Sometimes you borrow from ideas you already know are fun like side scrolling shooters.

    If you want to learn more on the subject of fun, I would suggest reading things like 8kindsoffun.com and theoryoffun.com.

    9: Games should have some Flavor

    Flavor here is meant to mean the setting or world, often referred to as the theme, that the game takes place in. Is your flavor a galaxy far, far away or maybe in the Caribbean on a pirate ship in the 1700’s?

    For our shooter, the player will be captain of a submarine fighting through undersea machines and beasts.

    10: A game should have a Hook

    Last but not least, people need a reason to play your game. We call this a Hook.

    You may have a great game, but if you can’t convince people to play it then it won’t matter.

    Our hook will simply be, “Save the planet from the alien invasion”

    Design Done

    Going through some sort of process like this every time you make a game will be really helpful.

    You don’t have to go through these 10 steps and even if you do, your game does not need all 10. I have simply found this a helpful exercise for designing games and would recommend it to you as well.

    Now to the hard part. Making the game.

    Tutorial Part 3
    Tutorial Part 5

How to Get SVG Images to Cooperate

Recently I was converting a mocked up webpage to an actual webpage and was using the <svg> element to handle some image resources. If you don’t know what SVG is, it stands for Scalable Vector Graphics. Its all in the name.

This element has not been common in most sites I have come across but is pretty powerful for handling the scaling of images and maintaining their resolution.

However, it is a little tricky and I could not find documentation that clearly explained how to work with them effectively so I will attempt to do that here.

The Image Tag

This is specifically about the <image> element inside of the <svg> element.

There are several tutorials on how to use svg to draw what you want in your webpage but none sufficiently explained how to handle an svg image that was already created.

Adding the image to the page is easy enough, just put it in an image element inside an svg element.

Sizing On The Page

Since the <image> element is contained within the <svg> element, to determine how large the area it will display in on the page, you set the width and height attributes of the <svg>:


<svg xmlns="http://www.w3.org/2000/svg" width="150" height="150">
</svg>

Using the Viewbox

<svg> has an attribute called the viewbox. This is like a little window that you can set for which part of the image you want to see.

It gets set to a string of 4 numbers separated by spaces, like “0 0 300 150” or something like that.


<svg xmlns="http://www.w3.org/2000/svg" width="150" height="150" viewbox="0 0 300 150">
</svg>

The first number is the x offset of the viewbox which controls where we start viewing the image from the left hand side.

The second number is the y offset of the viewbox which controls where we start viewing the image from the top.

Both of these can be negative, which moves the viewbox off the image.

The third number is the width of the viewbox. If your image is 300px wide and your viewbox width is only 100, then you will only see about 1/3 of the image horizontally when you display it.

The fourth number is the height of the viewbox. It behaves just like the width. If your image is 300px high, and your viewbox height is 150, you will only see about 1/2 of the image vertically.

I would recommend that you play around with these values on JSFiddle to get a solid understanding of what is happening. On this particular fiddle I put the Mozilla Developer Network example of an svg image.

Image Element Width and Height

The width and height attributes of the image element are where you start seeing why svg’s are useful. You can scale the image pretty much as large as you want or as small as you want while still maintaining resolution.


<svg xmlns="http://www.w3.org/2000/svg" width="150" height="150" viewbox="0 0 300 150">
  <image xlink:href="some_svg_image.svg" width="25" height="25" />
</svg>

This is great for logos and icons, especially when viewing on mobile devices compared to desktops. It allows you to reduce the number of viewable assets you have to make.

Note About Browser Compatibility

One of the reasons that I even did this post was because of the various behaviors across browsers. Initially I was not messing around with viewboxes and the various x and y attributes, but when I started testing my work in different browsers, I found that if some of these values are not set, certain browsers render the images differently.

If you want consistent display across browsers you should make sure to set all of these attributes correctly.

Additional Resources

Although not exactly what I was looking for, the following still have many useful details about working with SVG images in html.

Basic Game Structure

This post is part of a series on beginning game creation with Monkey-X. You can find the previous article in the series here.

A Basic Game Loop

Most games follow a similar pattern of running through the game logic, drawing updated information to the display, then repeating until the game is over.

The special functions that we discussed in the last section handle this loop in Monkey-X, OnUpdate and OnRender. You can control how often they are called by setting the SetUpdateRate. Using SetUpdateRate(30) would update and draw your game 30 times per second. And SetUpdateRate(60) would update and draw your game 60 times per second or be 60 fps (frames per second).

** Note: the SetUpdateRate function does not guarantee that it will be able to run that fast. It all depends on the machine the game is running on, how complicated your game logic is, and how many things your are trying to draw to the screen each time.

game_loop

Game States

For most games, what is run during the update section of the loop and what is displayed is controlled by state.

When the game is in the MENU state, we draw the menu and watch for player input for which state to move to next. When the game is in the PLAY state, we draw the player’s character and the map, and whatever else and listen for input to move the player around, check for collisions or perform other game actions.

This is what we will use to manage what goes on each time Monkey-X calls OnUpdate and OnRender.

So let’s get you started making your first game.

Tutorial Part 2
Tutorial Part 4

September 2016 End of Month Goal Review

The weather is changing, the goals are not.

Goals

  1. Write 3 Blog Posts Per Week and Publish 2 – Again I only got out 5 posts. This is the third month in a row at this rate. The writing goal was 12 and the publishing goals was 8. It is obvious to me I have not been keeping to my schedule. Time to draw it up again and stick to it.
  2. 1 Game Designed, Created, and Released Per Quarter – Drone Tournament (Game #2 of 2016) programming is nearing the glorious day of launch. These last few weeks the server and client sync bugs were worked out and some serious refactoring work has been done. I might even finish it before the end of the year. No work was done on Game #3.
  3. 1 Book Read Every 2 Months on Game Design – Read several more chapters in the book on creating games with PhaserJS. Learned about some new technologies I had not heard about and some resources that will be valuable in making games in any language. Will be adding these to the resource page soon. Also had some good ideas about using a Monkey-X physics engine just from reading this book. Well worth the investment.
  4. 1 Article Read Or 1 Video Watched About Game Design/Creation Per Week – I found a series on game balance that has some long, supremely valuable articles on the basics of designing games. Some really excellent material and would highly recommend the read.
  5. Get 100 People Reading Evolving Developer Per Month – Progress = 100%. Wow. Went from 0 readers last month to just over 100 people getting their eyes on the blog this month. How you ask? Well I did something absolutely crazy. I shared a couple posts. The first one I shared on Hacker News and in a programming Facebook group I am a part of. This alone got just over 100 unique viewers. The second was not quite as popular and I only shared it through Hacker News but still showed a small spike in traffic. So getting 100 viewers was slightly easier than I thought. Now we have to figure out how to get them to come every week.

What Went Right

Finally made progress on the viewership goal. In fact hit it for September. And it was all accomplished from taking a single simple action. Why didn’t I do this before? Also the game is working. Core game mechanics are finished and refactoring has begun. Slow steady progress marching forward. Additionally, getting great ideas from the book I am reading and the articles that I have found.

What Is Not Perfect Yet

Writing volume is still lower than intended. This is partially to do with assigning more of my time pie to getting Drone Tournament finished. Also, did let the amount and number of articles I read / videos watch of game design drop a bit. Main issue is the writing volume though.

Corrective Measures

It all comes down to routine. Must not let the routine get so easily interrupted. The writing must go on, both in code and in articles. Additionally, I am revisiting my article writing schedule and planning out which articles need to be written on which days.

First time to hit 100 viewers in a month, not much but it is progress.

Don’t Leave a Festering Pile

One of the most memorable statements from Clean Code was the author describing some of his own example code as a “festering pile.” And he doesn’t just use the term once, he uses it multiple times.

The most important statement however comes after he goes through how he cleans up his code and he is going over key points at the end of the chapter.

It is not enough for code to work. Code that works is often badly broken. Programmers who satisfy themselves with merely working code are behaving unprofessionally.
– Uncle Bob in Clean Code

Get It Working, Then Clean It Up

Don’t get me wrong, you should get your code working. If it does not work, it is completely useless.

But that is not where you stop.

When you stop here, it becomes difficult to add features to your program and makes it more likely that you will introduce errors later.

As a professional programmer and creator, cleaning up your code after you get it working is a must.

What’s That Smell?

As I am working on my current game, I started noticing that some of my own code was becoming a bit of its own smelly, festering pile.

Classes were getting a little clunky, functions where getting a little too long, and it was taking longer to make small changes.

Since I am trying to write the same logic in 2 different languages (Monkey-X for the client and Ruby for the server), having clean code was even more important to be able to replicate the logic in a second language.

And with the code getting a little cluttered, there started being some hard to figure out bugs where the client would show one thing, but the server would do another.

I finally got the code behaving the same and it took longer than it should have.

Programming Febreeze

Now it is time to get rid of some of these smells. The way to do that in programming is refactoring.

This is basically what Clean Code was all about. Changing your code to be more clear and designing the classes and methods to be easier to change (think DRY and SRP) have your code smelling like fresh linen.

That is what I am working on now with Drone Tournament. My original goal this year was to finish a game every 3 months, but I don’t want a half baked game. So I am taking the time to refactor the code and clean it up because I am a professional.

Be a Pro, Clean Your Code

Ruby Mod Operator Does Not Behave As Expected

I am writing the multiplayer server for my current game in Ruby using Sinatra. Since it is turn based and not particularly performance heavy, this is not a problem. One of the cardinal rules of making a multiplayer game is don’t trust the client.

This means I needed to write the game logic for the game on the server.

Modulo

Part of the game logic involves taking an angle and a position and calculating a new position and angle based of a units performance stats. In order to simplify the math, I wanted to keep all the angles positive.

So if the angle is negative, I Mod it by 360 and then add 360.

If the angle is positive, I just Mod it by 360.

But then I change it either adding a units turn rate to it or subtracting the turn rate from it.

The client (written in Monkey-X) was working 100% as expected. But the server was giving me some weird results.

Negative Numbers Behave Differently

I have always understood Mod, often the % operator in language, to return the remainder from a division operation. And that is what it is supposed to do. In Monkey-X that is exactly what it does (incidentally it is the word ‘Mod’ in Monkey-X). And in Ruby, all of my positive angles where behaving as expected.

But for negative numbers in Ruby, something like:

-21 % 5

is not going to return -1, it returns 4 (go ahead and try it in irb).

How Do You Get The Remainder?

Funny enough, in Ruby you need to use the .remainder function on a numeric type to get a consistent result. So:


num = -21
result = num.remainder(5)

and result will equal -1 as expected.

TL:DR

In Ruby if you want the remainder of a number, use the .remainder method instead of the % operator, especially if you are going to hit negative numbers.

Game Balance Concepts

In my search for articles to read about game design, I came across an excellent series that was done in a course. You can find it at gamebalanceconcepts.wordpress.com.

I have not finished yet (there are 10 lessons and each of them is a good long article) but have already found it to be valuable and would recommend checking it out. Here I will be discussing a few of the valuable ideas I learned just in the first 4 lessons.

Terms

The first lesson is mostly concerned with getting you familiar with certain vocabulary that is used when referring to different types of games. Determinism, solvability, intransitive, symmetry, and the meta game are a few of the terms discussed.

Near the end of the first lesson there is a section called “Game Balance for the Lazy.” In it the author gives a hypothetical example that describes an interesting method of having players balance a game for you. In the example it has the players bid on the stronger starting side in a game. The player who won the bid then loses the resources that they used to bid on it. This gives people who have played the game a way to tell you how unbalanced it is by the amount they bid and gives you an idea of how to change the power level to bring things into balance.

Numbers Are Related

In Lesson 2, there is a great discussion of the different numeric relationships and patterns you might find in a game or use in your own game design. There is discussion of linear relationships such as getting +1 armor is similar to adding 1 health, and triangular and exponential relationships such as the bonus cards in Risk where every time you trade in a set of cards you get an ever increasing number of soldiers (I forget the pattern but am pretty sure the number grows in an exponential pattern).

There is also a discussion about how various things in a game all relate to one number like the number of lives in Super Mario. If you die you lose a life so the number of enemies in the level might mean you are more likely to die. Also every 100 coins you get is an extra life, so the number of coins you collect can mean an extra life.

One Resource to Rule Them All

Lesson 3 sort of follows the number theme set in lesson 2 and revolves around having a single resource or number with which to calculate a power curve or cost curve on. The author uses the example of the TCG Magic the Gathering and how everything in the game is somehow tied into the resource of mana. He then breaks down a few cards and determines whether or not those cards are on curve, above the curve, or below it.

As someone who occasionally plays MTG and since I am trying to design a card game myself that has some similar properties, this was especially fascinating. I would encourage you to do a little exercise of your own with a game you enjoy that involves resource management and analyze item and/or unit power levels.

Highly Probable

Lesson 4 is a crash course in probability. Lots of games have probability involved and there are countless times I have heard lamentations from gamers over the RNG screwing them. In short, probability is often counter-intuitive.

This is how casinos and other gambling places make money. It is also where game designers can screw up and mess up game balance. Sid Meier talks about it in a talk he gave at GDC 2010 called Everything You Know Is Wrong where he talks about how players view percentages and numbers that you show them.

This is a great crash course for someone who has never looked into probability and statistics before and would recommend reading it.

More Chapters to Go

I plan on finishing reading through this course and would recommend you do the same. I have already learned a bunch of useful stuff and will sum up what more I learn in a later post. Until then, keep making progress.

Token Based Authentication Versus Session: A Simple Explanation

Recently I was tasked with implementing a token based authentication structure for an API. When I initially looked it up, using tokens seemed almost identical to using sessions the way it was described in several articles. It took me quite a bit of reading before I finally understood what was going on, and I never did find a satisfactory explanation of how tokens differ from sessions. So today, I am going to attempt to clear up these murky waters a bit.

Sessions, Your Old Friend

If you have done web programming for at least a little while, you have probably come across sessions. Sessions are what the server holds on to, which allows the user to keep using the site without signing in every time their browser makes a request to the server.

Think of it as a business like a gym that has restricted access. If the gym used sessions, they might make you pay (sign in with password) when you show up each time and put your name on a access sheet. If you left and came back, they would ask for your name then look up and check (think database) whether you are allowed access or not.

The members (users) need to know their name (session id), the gym (server) needs to hold onto information about whether or not its members have access (session). For our purposes this represents the browser cookie with the session id and the session on the server.

Tokens, New Kid in Town

Although I had used tokens before, I had never implemented them into anything so I did not now exactly how they worked. (The particular kind of token that I am working with is a JSON Web Token but that is not actually important.) Like sessions, tokens also allow you to access the server without signing in every time. Unlike them, the server does not have them. Your user does.

Ok back to our gym example. Say that you want to give people 24 hour access to your gym and don’t want to have employees working the front desk at 4 AM to give people access. You could install a card reader at the door and then give out keycards that your gym members could swipe or hold up to it that allows them access. Once they pay (sign in with password), you give them a card (token) that they can come back with and you don’t have to look up on the sheet (database) whether or not they have access.

In this case the gym members (users) have all the information about whether or not they have access in the form of their cards (tokens), and the gym (server) simply validates the card when the member wants access. As a bonus, the local pool (a different website) has a card reader and a program that allows anybody who is a gym member to go swimming there. Members simply need to bring their cards (tokens). This is like OAuth/OAuth2 and signing in to websites using Google/Facebook/Twitter.

A Model For Understanding

Hopefully this gym membership model helped you understand the difference between token based authentication and session based authentication. If you want to learn more about specific implementation details, checkout some of the links below. And if you like what you read, sign up for my email list.

Getting to Know TED and Mojo

*Disclaimer: This tutorial is assuming that you have some basic knowledge of computers, programming and programming lingo. If you do, but something is still unclear, shoot me an email and I will be happy to help you out.

If you followed the instructions in the previous part of the tutorial you should have Monkey-X installed and be able to open up the default IDE that comes with it, TED. Which should look something like this.

TED IDE

Today, we are going to go through a few handy things to know about using TED and some of the basic structure of a Monkey-X game and the files associated with it.

Create a File

First thing we need to do is create a new file so we can start writing some code. We are going to create a file called main.monkey because it is going to hold our Main function. You can do create this file however you want, and to do it in TED you simply go to the “File” option on the menu and click “New”. You will want to put this file in a new folder by itself. We will use this as our project folder, I have called my folder “game_one”, and will use it in the following examples.

TED File Menu

Open Your Folder As a Project

One of the handy things that TED allows you to do is open a Project view of the folder. This allows you to easily navigate and open files and folders as your game gets larger. You can do this by selecting the “Build” option from the main menu bar and clicking “Open Project”, then select the folder that you put your main.monkey file in.

TED Open Browser Window

When your games get more complex and you add multiple files, this view becomes very handy.

TED Project View

Mojo

The first thing we are going to do is add Mojo to the game. Mojo is an application framework provided with Monkey-X that gives you several useful tools for making games. It is specifically targeted at 2D games. Go ahead and add this to the top of your main.monkey file.


Import mojo

This will import all of Mojo’s components (graphic, audio, and app).

The Game

Now that we have mojo, we can create a class that is a Mojo app and will be what the rest of our game is built on. Lets do that now.


Import mojo

Class Game Extends App

End

Using Extends allows us to say that our Game is an App and it now has access to a lot of special functions and methods that Mojo gives us.

Quick note about the Monkey-X language. The End keyword is used to close Classes, Functions, Loops, Conditionals, and other code blocks. No need for ‘{ }’ everywhere in your code. Also lines do not use anything on the end to say they are done, so no ‘;’ are needed on the end of lines. There are a few other quirks about the language that it gets from Basic (from which it was derived) that we will discuss later.

Special Mojo Methods

The first special method that we will need to override that Mojo gives us is OnCreate. This method is called one time whenever you create a new instance of the Game class in your code. This is where you want to do things like load images and audio as well as set certain game values like screen width and height.


Import mojo

Class Game Extends App

  Method OnCreate()

  End

End

After OnCreate we have OnUpdate. The OnUpdate method is called a certain number of times per second (which you set in your OnCreate method). This is where your main game loop goes. This is where you will check for input and handle movement and changing game values. OnUpdate will only be called if you have set the update rate with a special method called SetUpdateRate. We call this in OnCreate and give it a number to tell it how many times per second to update. We will use 60 for now.


Import mojo

Class Game Extends App

  Method OnCreate()
    SetUpdateRate(60)
  End

  Method OnUpdate()

  End

End

Next is OnRender. This is where all of your drawing code will go. If you want to display something to the player, it should happen in this method. Mojo tries to call it immediately after every OnUpdate so the update rate that you set also applies to how many times you draw to the screen.


Import mojo

Class Game Extends App

  Method OnCreate()
    SetUpdateRate(60)
  End

  Method OnUpdate()

  End

  Method OnRender()

  End

End

Other Special Methods

There are several other special methods in Mojo (OnLoading, OnSuspend, OnResume, OnClose, OnBack) that we will discuss in a later step of the tutorial. For now it is just good to now about them. If you are curious about them now, you can go read about what they do in the Monkey-X Documentation.

Final Step

In order to have something that actually builds and runs (even though it only displays a blank screen) you will need to add a Main function creates a new instance of your Game class.


Import mojo

Class Game Extends App

  Method OnCreate()
    SetUpdateRate(60)
  End

  Method OnUpdate()

  End

  Method OnRender()

  End

End

Function Main()
  New Game()
End

Now if you build and run by hitting the little rocket ship with flames coming out the back (or by hitting the F5 key) TED should open your default web browser with an instance of the game running. Right now since we are not drawing anything in our OnRender function, it is just a blank screen. But it will soon get more interesting.

Tutorial Part 1
Tutorial Part 3

August 2016 End of Month Goal Review

And It is September, home stretch of the year.

Goals

  1. Write 3 Blog Posts Per Week and Publish 2 – Got the same number of posts in August as I did in July, 5. The writing goal was 12 and the publishing goals was 8. Still not hitting my writing goals, but I am pivoting a bit on my writing format. Additional goal is to create a series of posts that end up being a solid tutorial (and maybe even a book) on making games with Monkey-X.
  2. 1 Game Designed, Created, and Released Per Quarter – I got some good ideas for the card game from creating some mock cards and writing out factions and races that will exist in the game. Drone Tournament (Game #2 of 2016) programming is still progressing steadily. The final parts are straight uphill. Definitely interesting challenges with the simultaneous turns.
  3. 1 Book Read Every 2 Months on Game Design – Completely finished reading Clean Code and it has already had an impact on the way I am organizing and writing my code, for the better. New book I am reading is a book on making games with Phaser JS. I will be doing a separate post about the new book.
  4. 1 Article Read Or 1 Video Watched About Game Design/Creation Per Week – In August, I over corrected just a bit. I read dozens of articles on game design and creation. A majority were on a blog I stumbled upon by Ralph Koster. A goldmine of good stuff. Additionally he wrote a book called “The Theory of Fun” which I will probably be checking out later on.
  5. Get 100 People Reading Evolving Developer Per Month – Progress = 0%. When I get a few articles into the tutorial I will be posting it into the forums on the Monkey-X website.

What Went Right

I definitely hit my goal of reading 1 article on game design per week. Found a lot of great information on game design and balance. Big bonus, Monkey-X Pro dropped its price down to $40 (from $99) so I purchased it which will eventually allow me to build to mobile and desktop. Final big bonus was I got a logo created for the site on Fiverr which turned out looking great and was a great deal. Small bonus is that I have several cards designed for game #3 of 2016.

What Is Not Perfect Yet

Writing volume is still low. I have not gotten a consistent schedule yet. Ran into some difficult programming bits while working on Drone Tournament and it is not finished yet. Had to travel for a week in August and did not do as much programming and writing during the trip as I needed to.

Corrective Measures

The only one I can think of is currently is to be more consistent with my morning routine. Get up at a more consistent time and make sure that I do the most important things first. Additionally, I will be attempting to capitalize on my free time a bit more to focus on finishing Drone Trounament.

Read All the Articles.