Player Manager progress report & Frame Rate Locking

Progress has been slow these last 3 weeks, due to work (the start of the academic year is always a strain…). However a few things have happened.

One thing is that we ditched Allegro and switched to SDL, as Allegro was becoming a pain. I wanted a 3D Ball instead of a sprite ball, it just got messy. It turned out that David was pretty familiar with SDL, so he ported the OS X development version of the game to it.

So now there’s a 3D ball. I want to work on the ball physics next, for which I will be using a proper ball simulation with rigid body mechanics to make sure the ball spins and rolls correctly. I am hoping we can make the player sprites and the 3D ball work together; sorting may be an issue, but it’s not that hard to deal with (I had to deal with it in the original games too, it was just a cheesy Y axis position comparison between the player dribbling with the ball and the ball: sorting was not done in other cases: did anyone ever notice?  No.  That’s an example of only doing what you actually need to do.  You don’t always have to solve all the problems to make a game work!).

Aftertouch (the feature of being able to bend the ball by changing the direction of the input controller immediately after the kick) is one of my trademarks (I came up with it for Kick Off 2) so I have to include it in the game.  Of course, the question is the controls.  That is going to be difficult to figure out, we don’t have 8 way joysticks anymore.  But  I have some (top secret) ideas, and figuring out input control systems is a speciality of mine.  After all, I figured out how to squeeze passing, trapping, shooting, heading, scissor kicking, tacking, chipping and bending the ball on an 8 way joystick with 1 button.  It’s got to be possible to figure something out with a multi touch screen.  No, it won’t be the same, but I have faith that I can make it work and be fun.  It’s a non-negotiable constraint .

Now for the programmers out there, frame rate lock down is a common problem, and often I end up needed a cheap and cheerful solution at least temporarily while developing gameplay.  It is very important for my method of game development that the game code runs at a fixed rate, independent of the rendering.  I never try to use frame rate compensation using a delta time as this makes the behavior of the game dependent on frame rate, which is not a good idea for a few reasons (and many are those who learn this the hard way).  An unstable frame rate will make the game impossible to tune, and very unpleasant to work with.

So here is the cheap and cheerful solution.  The idea is that the AI is in an inner loop  which is called after every render.  The rendering is allowed to update as fast as it can.  Using a timer, it is then possible to keep track of how far ahead or behind the AI is, and either skip it if the rendering is going faster, or execute the AI multiple times to catch up if necessary.  However, each AI execution is always with the same fixed time step so the game remains deterministic.
Disclaimer: This code is as it comes. It has not been dressed up or santized and has a bit of code duplication that annoys me.  But I have more important things to worry about so I’m leaving it as it is.

int elapsedTicks=0;
int prevTicks=SDL_GetTicks();
int aiFrames=0;
do {
// input
processEvents();
int ticks=SDL_GetTicks();
elapsedTicks += (ticks - prevTicks);
prevTicks=ticks;
while(aiFrames*20<elapsedTicks) {
// the threading system
proc::Thread::execAll();
aiFrames++;
int ticks=SDL_GetTicks();
elapsedTicks += (ticks - prevTicks);
prevTicks=ticks;
}
graphics->drawAll2D();
graphics->drawAll3D();
graphics->flip();
} while (!pressed);

Discovering fixed point

I told a story today in class about my own personal learning experience with regards to figuring out how do to fractional mathematics with integers (also known as fixed point math).

While I was relating this story about my personal exploration of programming at the age of 15 or so, a student asked “Why didn’t you just use fixed point”. I had to point out that I had to work out fixed point for myself, because I had to teach myself, there was no one who could teach me.

It just occurred to me that the student may not have fully appreciated the situation. Sure it’s obvious *now*, but imagine what it was like for me about in around 1980 or so. When I said it took me years to figure out (it was about 2 years) I can now imagine students running around saying “It took Mr. Dini 2 years to understand fixed point!”. Talk about a teacher digging a hole for themselves *sigh*. An explanation is in order.

The truth is that I invented fixed point… for myself in my own little world. Sure other people also invented fixed point. But to be clear, since I worked it out on my own, I did invent it. For me. Stick with me, it’s not as strange as you might think…

First of all, I was programming on an 8 bit microprocessor (a 6502) in assembler on the BBC Micro, which had a 2 Mhz processor. I wanted to write an asteroids clone. The 6502 did not have a floating point processor. Floating point math routines were possible to code in assembler, but they were very slow: too slow for a 50 FPS game, where the graphics also had to be blitted in software.

It took me about 2 years to figure out the correct solution to the problem of how to emulate real numbers with only integers. The idea is of course very simple: You just scale everything up. One way of thinking about this is to imagine working on a much higher resolution than the screen. I can’t remember the BBC Micro resolution I used, but it was something like 320×240 (I had to use a black and white display to keep the resolution that high). Well, instead of having the program work internally on a pixel resolution, I can make it work on an internal resolution of 32000×24000 for instance. If I do this I can have the sub pixel accuracy that allows me to move in more than 8 directions… essential for an asteroids clone. Then when drawing, you simply divide the internal coordinates down to screen coordinates.

Obvious? Perhaps, as I said, it is now. How should people learn about this stuff? Oh I guess you can ask on a forum, or search google, or look on wikipedia. Perhaps that student today was thinking “eh? It would take be no time to find that out! Who does this guy think he is blah blah”. Well I don’t know if you have spotted the flaw in that potential argument yet… anyway carrying on…

One day, as I was experimenting, it hit me. I could see the idea of internally having a much higher resolution. And… a way of implementing the scaling down in assembler so that it would be very fast.

If my play field is 256×256 pixels, then a coordinate axis (X or Y) can be held in a single byte. But if I use two bytes (and of course write the code to chain adds together using “add with carry” instructions: 8 bit processor, remember?), I can then work internally at a resolution of 65536×65536 ‘pixels’. And the real beauty of this is that I can simply read the most significant byte, and thus not even have to divide it back down by using shift instructions!

And this is how I invented fixed point… for me. No, I did not read about it. I did not have someone who told me. I was on my own, closed off from the rest of the world of computers, in my bedroom writing games and figuring it all out for myself.

So I hope you spotted the flaw I mentioned: not only was there no one to teach me, but there was no Google, there were no forums, there were no books on game programming, there were no mentors, teachers, twitter, YouTube, Wikipedia, mobile phones…

All there was was a 15 year old geeky kid with a 2Mhz 6502, 32K of ram, the BBC Micro programming manual and a cassette tape recorder to record my programs on and a strong desire to write an asteroids clone (which was later actually published).

So, I simply had to invent fixed point.

Trying to show someone something they cannot see

As a teacher I often face the challenge of trying to show students things they cannot see.  It’s hard. Sometimes they think they understand something when in fact they do not.  Sometimes they confuse the ability to copy something with the ability to understand it.  Sometimes they dismiss things because they do not think them relevant, when understanding these things are actually essential.  I know they are essential, because I see the whole picture. Yet, to see the whole picture you must have an appreciation of the details.

So, it comes down to this: in my opinion a teacher’s job is to show a student something that they cannot see and help them gain the ability to see it.

It is the most wonderful thing when they click, when they suddenly see.

Wide screen, narrow thinking

I don’t know about you, but I am pretty fed up with wide screen displays now. If you think about it, the fashion for wide screen is just an excuse for giving us less pixels:  A wide screen monitor is basically the same as a 4:3 monitor, except with the top and bottom cut away. So that’s less, not more.

Another thing is that since HDTV came along, it seems that the preferred resolution of a monitor is 1920 x 1080. 1080 pixels high?  Wow. I remember when, 15 years ago, I was enjoying 1600 x 1200 resolution. Progress?

Sure if you are watching a movie, or play a 3D game, wide screen is fine. Oh except that before you could put subtitles below the movie instead of on top of it. Anyway, basically OK on that one. But just about every other use really needs vertical resolution. Noticed recently how even just web browsing requires much scrolling up and down?  Web designers have increasingly been forced to spread their pages out horizontally, but some are still obsessed with the idea that the web should look like print. Great, so now I have gone from 1600×1200 pixels 15 years ago, to effectively  810 x 1080 displays. (That 3:4 aspect ratio fitting in the 1080 vertical resolution).

I have recently converted to Mac for most of my computer work, and I noticed it has a screen rotate option. I also have a clamp monitor stand, which is great, but it would only rotate a few degrees, so I dismantled it and removed a pointless metal lug with a pair of pliers, resulting in an ability to spin my screen through 360 degrees. So now, I have my 40 cm wide screen monitor vertical, and it’s brilliant. It’s a little bit tall perhaps, so I might buy a smaller screen at some point with the same resolution so that I nod a little less while using it. But I love the fact that right now I can see all of this post, and the entire WordPress page around it. Marvellous.

Now just to make things even better, I have a wonderful innovation in mind. See what you think…

My screen is now a bit narrow; It would be great if I had a little more side by side screen space for multiple applications.  I don’t need much… let’s see my screen resolution is currently 1080 x 1920, how about if I could increase that to say 1440 wide. Yes, just a few extra centimeters would do the trick. I could market this as “Full Width Vertical Display” or something. I could capture the public imagination…

Wait. 1920 x 1440 ? Isn’t that a 4:3 aspect ratio again? Damn, I guess a patent is out of the question after all.

It is the saddest thing of all…

… is when the deluded, in anger and desperation, spread more delusion in an effort to to shape the world to fit their minds, without regard to the suffering it will eventually cause.

When we see this happening, it is the duty of all of us with some grip of reality left to say “Enough!” and demand the delusion cease.

Abstration: Adding stuff that does nothing?

This post is inspired by a tweet this morning suggesting that abstraction is simply a way of making code that does nothing but call code that does. Of course I disagree. Abstraction in computer programming creates code that does something very important… it abstracts. Following my philosophy of “right tool for the job”, then abstraction is the tool you use when you want to be able to hide details from higher level functionality. There is more to writing code than thinking about the steps the processor takes to execute it.

The world of programming can be split into roughly two; those programmers who understand the tool of abstraction and those who do not. In my experience, programmers who properly understand the tool of abstraction and its uses are a minority, even though all programmers use abstraction in some shape or form.

To demonstrate what abstraction is I like to use a real world example: good old fashioned post. When you write a letter to someone, you execute a delivery transaction by placing the letter in an envelope. Upon the envelope you write instructions for its delivery. The postal service is then able to deliver the letter without concern about the contents of it. The machines and personnel that execute delivery really do not care about what the mail contains, only the instructions for where the package of information should go.

The above scenario is very similar to software abstraction. The letter has an implementation (the contents) which is encapsulated (in an envelope). The encapsulation has an interface (the writing upon it) that implements a protocol (the address).

Can you imagine a world where letters were delivered according to contents? Where to decide what to do with a letter is was necessary to read it? Think about all the reasons why this would not be a good plan, and you will have your explanation of why we place letters in addressed envelopes. Although one could say “Envelopes are a way of adding more paper and information to a letter that is not needed by either the person who writes it or the person who reads it”, it would hardly be a fair statement, would it?

Of course, abstraction is not without its pitfalls. Let’s take a look at some of the issues.

First of all there is the problem that we have duplication of information (which translates to more memory usage in computer programs, something that usually want to avoid in low level coding). The identity of the recipient is probably both on the letter itself and also on the envelope. This duplication is a common cost of abstraction, although sometimes you can create clever solutions (a plastic window on the envelope that shows you the address on the letter – the equivalent of providing a constant reference to a part of the implementation).

Additionally, the abstraction increases the weight of the letter (which may be considered a loss in performance).

Further there is an interesting cost that you may not have considered: The envelope actually adds some complexity, and thus creates opportunities for things to go wrong that could not otherwise. The address may be incorrect for the contents, as an example, resulting in the letter being delivered to the wrong recipient. The letter may shift in the envelope hiding part of the address in the plastic window (if one is used). The delivery address may be mistaken for the return address and so on.

Do these disadvantages mean that we should not use the addressed envelope tool? Of course not. They are far outweighed by the worse things that would happen if we did not use addressed envelopes. Such things as:

• Privacy (it is not desirable for everyone to be able to read the contents)
• Integrity (if the letter is not protected in an envelope it may become damaged by elemental factors and handling)
• Speed of processing (although the protocol adds complexity and use of resources, it speeds up the process of delivery through use of a standard protocol that is independent of the contents of the letter)
• Simplicity (the life of the postal worker is made much easier by removing information they do not require in order to execute their jobs)

Of course, you may say that programming is different. Well it turns out on analysis (at least it turned out after my own analysis, why not do your own analysis to see if I am right) that even though every programming problem is different, there are issues that arise commonly in all circumstances. By studying the example of letter delivery (if one can get over any prejudice such as “Why on earth is a computer programmer going on about the postal service”) you will learn about abstraction and then be able to apply this to software abstractions. Which brings me to a final advantage of abstraction: fitting multiple complex scenarios into a single unified abstraction is a great way to become versatile. Why? Because you develop a general purpose pattern that can be applied to situations you have never encountered before.

Abstraction is an orgnisational tool that can help you maintain flexibility as complexity increases. If you follow my posts, you may recognize this from a previous post called “Beware the Bemusing Triangle”. In it I described the robust FLEXIBILITY – COMPLEXITY – ORGANISATION triangle. To maintain flexibility in an increasingly complex world, one must get organised and abstraction is the most powerful tool for doing so.

Of course you can go too far. Memos in an office of 4 people do not require addressed envelopes, for example. But this is simply a case of using the right tools for the task. Generally, the more complexity, the greater the need for abstraction.

In video game programming, the most popular programming activity appears to be graphics programming. The irony is that this is probably the least complex part of a video game, compared to asset management, behavior management (also known, inaccurately as AI) and user interfaces. All stuff that many programmers find boring or at the very least “not sexy”, but all stuff that is absolutely essential to shipping a game.

Well, if you are a graphics programmer, layers of abstraction are likely to get in your way, but it is misguided to think that means abstraction is bad. It is not a question of whether or not to abstract, but where to abstract.

One programmer I worked with a many years ago kept moaning at me because I was using virtual methods in a console game. “You can’t do that, it will run like a dog! It will break the cache! blah blah blah blah”. Of course, I know this. I know it because I am a rather experienced programmer (30 years) who has worked on all kinds of platforms, configurations and processors. But I also know that virtual functions are a great way to keep his hacky, messy code away from my code. And I also know that it is far easier to take working, but slow, code and speed it up by adding hacks, than it is to hack from the start and get it to work. So created an abstraction layer using pure virtual classes. I developed the gameplay on a PC. Most of the PC code shipped in the console without modification. The threatened disaster of virtual function cache breaking did not appear. I did not even need to optimise everything.

How did I do that? How did commit the cardinal sin of using virtual functions on a processor that hates virtual functions and get away with it? Simple. I chose where to abstract carefully.

Sure in the depths of the rendering pipeline, virtual functions would be a bad idea. But at the object level, where there may be only 10 or 20 objects being manipulated (or even hundreds), the performance cost of a thin abstraction layer that provides code organisational advantages can hardly be measured. The abstraction I am talking about is at the level of “Place this game object at this location”.

“Hey, Fred”, (real name concealed to protect them), “You know those horrible virtual functions I am using? They are only called a total of about 1000 times per second. That’s a few cycles cost once every millisecond. So this performance impact you keep talking about can hardly be measured. Meanwhile the code works. So please get off my back”.

So next time you have a lead programmer, a colleague or even a teacher speak about the wonders of abstraction, do yourself a favor and try to put any prejudices you have about software engineering away. Remember the letter. Remember that the great programmers find a balance, and that you will never find that balance if you dismiss half of the equation out of hand. You can never choose the right tool if you are unaware of the tool that solves your problem. And you can never learn to be a better programmer if you are prejudiced against the paths that will help you.

Twitress

Some of you might know that I enjoy inventing words. I just made up Twitress which means “A series of tweets over a period of time showing the progress on a project under development”.

OK, so if you want to see the video twitress for Player Manager, follow me on Twitter

Here is a recap of the first two tweets:

Early wip for new football game http://yfrog.us/bg9lez after a few weeks part time. Basic architectural framework complete.

A tiny step further http://yfrog.us/mvgv9z

The return of Player Manager?

Yes, I am working on a new game. This is the sequel to my 1990 game Player Manager that I have been waiting 20 years to do.

Why so long? That’s a topic for another day. What I want to post here is a progress report.

Why now? Because someone whom I gave an introduction to game programming (in an attempt a long time ago to train an apprentice) recently declared that he would be extremely willing to help me work on a new game. He’s David Athay, who now lives and works in the US.

Yes that’s all it took. Someone to say “I’ll help” who could and would actually help… with actual programming. It’s a psychological thing really. Sure I could code it all myself, but… I don’t want to. It’s a lonely road… and I am sick and tired of wrestling with APIs… I want to make games.

Games that I can sell. For actual money. In a world where most of the audience want everything for free, and would be quick to point out “there’s more to life than money”. Money is life. Without it I die of starvation and exposure. I would be quite happy if I could earn enough to live on. iPhone may provide some glimmer of hope there. Maybe.

Of course, both of us are doing this in our spare time. There is no funding, or salaries. The project at this stage is only a few weeks old.

David is working on iPhone primarily, since the current idea is an iPhone product, and like I said I want to actually spend my time working on a game, not learning Objective-C.

I am, however, building the game on OS X, because it is a lot easier to develop on a computer platform rather than messing about with the iPhone development kit. In order to achieve this, I am using the Allegro library which serves my purposes well. I have a representation of the game running natively on OS X.

David maintains the iPhone version, and does the appropriate integration to make sure that everything I do on OS X ports to the iPhone.

This is not as difficult as it sounds, because I have developed an architecture that hides the game code from the platform. So in theory, a simple recompile for iPhone is all that is required to keep the games in sync.

What have I done so far? Well I dug out the old graphics for the Megadrive game Dino Dini’s Soccer (a.k.a GOAL! on Amiga and ST). I recreated a pitch map out of the tile set. I gave these to David who quickly implemented them on iPhone.

I have set up my own custom IDE around the Emacs editor and ported my CoreLib library (with vector classes, debugging functions and string classes and so on) from MSVC to GCC.

I have ported and extended my Property Tree system (more on that in a future post) so that I can make appropriate parts of the game data driven.

I have ported my PROC system (this is a software threading/hierarchical finite state machine/event driven system for managing complex behaviors… it actually allows one to write scripts directly in C++… again maybe more on that at a later date).

I have created various classes to abstract away platform specific details.

Right now, I have a scrolling pitch with some sprites… and am about to add the sprite animation system.

The game is going to be 2D for a few reasons. First of all, 3D is simply not as good as 2D for this kind of game. Secondly, I am using existing 2D graphics so that I don’t have to find an artist (at least for a while). Finally, I want to focus on gameplay as quickly as possible. This is going to be an iPhone game after all, I am not trying to compete with FIFA or PES in terms of graphics. I want to get going with creating the gameplay and tuning it, because that is what I love to do when I make a game: I focus on the gameplay above all else. It has worked for me in the past too: The graphics on KICK OFF were appalling. Yet it beat off all other games in the UK to win the Industry Dinner award for “Best 16 bit product” in 1989. Yes, it even beat Populous. Perhaps there is a lesson there.

Back then, the computer systems were heavily constrained: 8Mhz 68000 processors and 128K of ram. I wrote everything in assembler out of necessity, and hand optimised critical areas of code in order to keep the game running at 50 FPS.

Things are very different now, not only in terms of computer hardware, but also in terms of my skills. For the past 10 years I have worked on getting the best out of the C++ programming language, and I feel I have reached the point where I have figured out how to get the most out of it: it actually turns out to be a fairly limited set of patterns and design heuristics that enable me to do 90% of everything I need. So, especially since computer hardware is so much faster now, I am using a proper architecture which will hopefully allow me to develop the game quickly, while of course making it easy to port to other platforms. Flexibility is a key part of my strategy.

I am also, for the first time since 1995, working in a completely Microsoft free development environment. Just saying that makes me feel good. Kickoff, Kickoff2 and Player Manager were developed on the ST (cross assembled for Amiga). GOAL! and Dino Dini’s Soccer were developed on a 486 Dell Unix box. This was Unix before Linux came along. I loved that Unix environment: so powerful, so robust. This is back in 1991: it had a 1024×768 display, 300MB hard disk and… I think 8MB of RAM. You don’t want to know how much it cost. But it was worth it; it paid for itself easily.

However, since about 1996 I have lived with the hell known as Microsoft. Although I always had a unix box handy, they have always been used as servers. Problems with hardware compatibility, the necessity of PC development and so on meant that I was stuck with Mr. Gate’s efforts. These past 14 years of servitude to Mr. Gate’s empire have not been fun. And I have had enough.

But a great thing happened: Apple adopted Unix in OSX. Unfortunately I did not pay much attention until (spurred on by the idea of iPhone development) I got my first Mac last year. Sick and tired of how my PCs would keep going wrong and seem to slow to a crawl and take 10 minutes to reboot … I tried to use the Mac, more to get out of the rut than anything. Now… I consider it my primary machine. Yes, it is what I always wanted: an all round usable versatile computer with lots of commercial software and hardware which runs UNIX. I ain’t going back now… except of course when I have to (for example when teaching).

No doubt this will have many of my students (and some colleagues) shaking their heads. Hey, but that is normal. I’m used to it. At least there’s a context to it now, perhaps. I love UNIX. So I love my Mac.

Anyway, I digress.

I am making a public statement that I am developing a new game, in part to make sure I actually do it. But I have no idea how long it will take at this time. It’s early days. About 21 or so in fact. Stay tuned for more…

Welcome back to the days of… typing…

There was a man who decided once that what people really wanted on computers was not to have to type.

This obsession with not typing went to extremes, but let’s be honest: people who use the computer a lot learn to type, so I am not so sure that this avoidance of typing is actually sensible.

Yes, goodbye to nice easy to edit files, hello to screens and screens of dialog boxes where you have to click precisely at the right spot and then move your hands from the mouse to the keyboard and back again… and again… and again…

Computers have turned from machines that you “speak” to in words, to machines that you communicate with by pointing. “Over there!” you suggest as you swing your arm to move the mouse as it falls off the table.

I believe the mouse was both a blessing and a curse; but when you look at Microsoft’s treatment of it, you have to wonder whether the blessings are worth it. The obsession with not using text files for configuration of your computer for example. Just try configuring your network adapter IP address. No… you can’t just type in 192.168.1.1. You have to put 192 in the first box, then 168 in the second box, and…. and then if you need to copy the IP address, you can’t. You can’t paste it either.

Pointing is all well and good for some tasks, such as moving windows around, resizing them, selecting them and so on… but using them to execute commands, I am not so sure about. Take the start menu for example. I don’t know about you, but I don’t want to have to search for an application, I want the computer to search for me. Macs have a nice search feature: type in a box and it will try to find the thing you are looking for quickly and easily. Microsoft have followed suit. Well done, computer industry! You are moving us back to the command line, only dressed up.

I have recently gone back to using emacs instead of more “modern” editors. It is a wonderful feeling. Because everything is language based, it is really easy to configure and extend functionality and so on. Because everything can be done from the keyboard, I don’t have to keep moving my hands around. Because there are no gigantic dialog boxes, I don’t have to wait for ages for them to appear.

Oh and there’s no more of that visual studio curse, the property dialog box. I dread to think how much of my life I have wasted waiting for that thing to appear. Or wasted trying to reconfigure a complex project, one tab page at a time. That dialog is so complicated that it ruins the disk cache and slows down recompiles. And there is no way to easily copy settings.

OMG, I have this brilliant idea! Why don’t they replace that dialog fiasco with a text based configuration file, where you can see everything at a glance and copy and paste whole configuration sections? Oh right, sorry it exists already… silly me. It’s the ‘make’ utility that existed since forever.

I am experimenting with ditching that whole “GUI based IDE” thing completely. So far, it is going well for me. Now that I don’t have to point, and search and switch between dialog boxes, and wait for them to open, and wait for them to close… now that I can just pull up a configuration file in an editor and search and replace, cut and paste and save backup versions… now that the computer resources are not eaten up by complicated bloated dialogs… now that I can work faster and actually reap the benefits of faster hardware not dragged down through more bloat… ah… heaven.

Grow up or Blow up

Comedian Imran Yusuf (twitter) tweeted recently about a woman from the audience who loved is show, but said that her father “Hates Muslims”. He suggested she buy him his DVD for Christmas.

Got me thinking. The situation of the world and every human being within it can be summarised in the following choice:

Grow Up or Blow up

Yes it really as simple as that. Anyone who hates Mulsims should Grow Up before they Blow Up. If they do not, their anger will feed anger until one day something will blow up, and the suffering that results will be in part upon their heads.

But of course, this does not just apply to hatred of Muslims. It applies to hatred of any generalised group of people. Christians (whether Catholics or Protestants), Jews, Policemen, Video Game Developers, Gays, believers in God or believers in no God, Women, Men and any of thousands of poor groupings of people that get a whole load of hate vibe flying in their direction every second of every single day.

Any of you out there that holds such hatred in their hearts needs to Grow Up before they Blow Up. It’s a choice.

Growing up is a choice.

So, for pity’s sake, let’s all grow up shall we?