This pit is filled with about 60 people’s shared failures and abusive language.

I’m pretty pleased about it.

Click here to play “Mountain”

Woohoo. Ludum Dare 22 was a happy fun time for everyone. 48 hours to singlehandedly make a game from scratch around a theme that is not announced until the beginning of the competition. This Ludum Dare was themed ‘Alone’, which I understand was pretty unpopular with a good deal of LDers, but then there always seems to be a group angry with whatever theme our glorius leader PoV the people choose.

This Ludum Dare I decided to make an effort to use Unity, mostly to finally see how it actually works and also to make the game more accessible to the ‘I don’t like to download games’ crowd, even though I will have lost my beloved Linux LD comrades votes.

Given that I’m quite unfamiliar with Unity I decided to keep the game fairly simple, and decided to make use of a number of canned scripts and functionality, such as the bog-standard first-person-camera with collision detection and predefined keyboard+mouse controls.

So I decided to make a dangerous mountain to climb alone. An initial test showed that climbing a large low poly mountain was both easy and boring, so I spent some time thinking about how to better meet the theme, make the game more challenging and try and add something a little unusual or interesting to what might otherwise be an extremely mediocre offering.

I’d heard about some kind of message system in Demon Souls, a game I haven’t played, where players can leave messages warning other players of traps and dangers in the vicinity, and often lie in these messages to mislead other players. Sounds like a great idea to me. I also wanted to make the game a lot more difficult to encourage some kind of communication between players beyond obscenities and gibberish, so I wrapped the mountain in almost total darkness and made the messages players leave illuminate their surrounding area, allowing for players to create a trail of lights up the mountain, showing where the dangers are hidden. The player can only leave a message at the spot they die, so even if they decide to write nonsense or query my parentage, their message will help illuminate whatever obstacle was responsible for their demise and so help other players better navigate the mountain. So I whipped up a database back-end and spent some quality time with the Unity documentation for dealing with web streams.

In terms of gameplay, I managed to achieve my goal. The Mountain isn’t particularly difficult to navigate, but does have some pretty mean, unfair areas. The graphics do their job, but aren’t particularly exciting, and the white text on the sometimes white background can become impossible to read. Audio was left until the last minute and really suffers as a result, the music was written in less time than it takes the track to play, and I didn’t have time to record or create any ambient or event noises that probably could have added a good deal of atmosphere to the game.

As it is, Mountain is a slow stroll to the top of the hill through a swarm of sometimes offensive messages, but for me it’s an enjoyable stroll, and seeing evidence of other players passing through the environment makes me happy.

So for LD22 I’m going to have a go at using unity3d, which will give me the option of generating a web version. Honestly though I expect I’ll still end up creating a downloadable game because at the end of the day I just don’t really like games embedded in webpages, which I find difficult to experience any sense of immersion with. Unity will at least make it fairly easy for me to churn out an untested Mac version though, which might win me a few plays from the undernourished Mac gaming crowd.

But. Unity doesn’t produce Linux executables. Although it is not completely impossible to run a unity game in Linux, it probably is not going to be worth the substantial effort to coax wine into running a 48 hour game. So this will be the my first LD where I have not targeted Linux, but given that almost no-one actually plays my entries anyway, it probably is not a great loss to the penguin loving world, but it does make me a little sad.

This is the first game I’ve written that I was genuinely excited to play. The whole time I was writing this some part of my inner-child-brain was already planning all the awesome asteroid dodges and grav-well slingshot manoeuvres I was going to make the first time I played it.

The Plan

If there is one thing the world needs, it’s another space game. A space game with lots of rocks. I just have a thing for rocks floating in space. Rather than spending a good deal of time trying to come up with a game concept, the idea of having to escape a gravity well whilst navigating a dense asteroid field sprang fully formed into my mind. I realise that the premise isn’t entirely original or likely to win any narrative awards, but not crashing into things is a time honoured computer game tradition which has made for plenty of great games.

So once I’d settled on a struggle against gravity and floating space debris, I decided it was time to finally come out of the closet and admit my love of pandas. Panda3D is a 3D all-in-one-even-makes-tea game engine I’ve dabbled with in the past, but never finished a game with. I like Panda because of its excellent Python bindings, and Python is, for me at least, a really excellent rapid development language, which given the 48 hour time limit of Ludum Dare makes a whole lot of sense. 3D engines (usually) need 3D models, and I decided that my familiarity with Blender was sufficient to put together some space rocks and a ship, coupled with my GIMP mastery for texturing. Audio would be made by either blowing into a microphone or created in any of the 100+ audio programs I have installed but have only opened once.

Decisions

Right from the start I knew I wanted to make this game first person 3D. I could have gone third person and made the game a 2D Thrust style game, but I really wanted to try and have the player (who in all likelihood is only going to play this competition entry once or twice) care about not colliding with any of the in-game obstacles. I personally feel a lot more invested in the outcome of a game when it’s presented in first person view, rather than the extra level of abstraction that comes from identifying with a player character visible on-screen. But I didn’t want to go with the static cockpit view that a lot of first-person vehicle games do. The player is not the ship, the player is the pilot sat in the near-useless ship careening down a gravity well, so I decided to try and create a feeling of separation between the player character and ship by having the mouse control the direction of view and requiring that the player look around the cockpit in order to successfully navigate to a victorious escape from the well. This required having some important reason to look anywhere other than directly forward, and so I decided on display screens around the cockpit that would show the player essential information, but would require them to turn away from the main window to view, and so outside the players forward field of view I added an overhead map of the system and a screen showing the distance required for the player to ‘escape’ the gravity well.

‘Realistic’ Newtonian physics were chosen because besides being the easiest for me to model, I really wanted to be able to slingshot around the gravity-well, and space-sims without Newtonian physics just feel like arcadey flight-sims without a floor to land on. I also didn’t want the ship to be particularly responsive, forcing the player to think about how they manoeuvre to avoid incoming rocks, and also to try and create situations where a player slowly realises that their escape attempt has failed and are dragged back down into the gravity-well. I also hoped that this would add some degree of a learning curve for any players that played the game a few times.

Audio was kept simple. I hoped to create a close tense atmosphere through limiting audio to the sounds you might realistically expect to hear aboard a space faring vessel and forego the star-wars ‘sounds in space’ phenomena. Given the limited fuel supply, this would result in a totally silent ship once all fuel was spent and the player is committed to their vector as a helpless passenger. I did decide that I’d include an ‘ominous hum’ that would increase in volume with proximity to the anomaly, but this was my only ‘cheat’ against sound in a vacuum.

Also, black-holes are hard to represent convincingly, so I decided to make a weird purple planetoid as the source of the gravity-well.

Building The Assets

So with a reasonably detailed plan in hand I jumped into creating my media assets. I wanted to reverse the order of my previous Ludum Dare entries and get straight into making some art assets that I was reasonably happy with to see how things looked together, rather than writing a game and throwing some graphics in at the end if there is any time left. First up was the ship cockpit (complete with comfy space chair). This iteration saw the chair upholsterer get flushed out the airlock.

First version of cockpit with chair

It's a low poly rock. Not a lot else to say

The source of all your gravity related woes

Writing The Game

Besides a few learning issues with displaying content on the in-cockpit monitors, writing the game went very smoothly. Having the art assets available at this point made dealing with issues of scale and position a breeze. The physics came together nicely and [relatively] soon I had a playable version of the game. Inexplicably I decided at this point that the game really needed music. I blame the hours I’d spent by now testing the game and staring at the art assets, but I hacked together a vaguely Indian sounding drum-loop that unless you’ve been working on a game for almost two days (and probably even if you have) gets annoying before it has even looped once.

Anomalous Balance

Who knew balancing such a simple game could be so hard? I only had the following factors to deal with:

• Starting distance of ship from anomaly
• Starting velocity of ship
• Manoeuvrability of ship and quantity of fuel
• Gravitational pull of anomaly
• Number and distribution of asteroids
• Speed of asteroids

But I just didn’t have enough time left to get it right. I seriously underestimated the amount of time it would take to tweak these values in order to solve the equation for fun. Increase the power of the ship, game too easy. Increase gravitational pull to compensate, game too hard, etc. Long story short, I failed this part completely. I just wasn’t able to come up with a solution where the game was not ludicrously easy or impossibly brutal. The once time I did chance upon a good combination, it was unworkable for most computers given the huge number of asteroids I’d included. Scaling back the rock count made the game far too easy again, but at least allowed the game to run at a decent frame rate on my netbook, which was the target base hardware platform to ensure I don’t repeat the mistake I made in my last LD entry of assuming everyone is running the game on a fat desktop computer.

Pointless Cockpit

One of the first comments I received from a game judge was that the cockpit was pointless. They didn’t need to look around at all, and had won the game (I assume) without so much as glancing at the map or distance view. Obviously the pace of moving through the asteroid areas was wrong if it could be easily navigated without the map. Another commenter described the rest of the cockpit as ‘a distraction’, again demonstrating that the information available on the monitors was not valuable to the player.

Mindlessly Easy

With the released competition version, it’s a simple matter to orient your ship at a slight angle to the Anomaly, burn your entire fuel reserve, and then safely coast around the gravity-well and out to a safe distance, winning the game. Nine times out of ten, you will miss the sparse asteroids through chance alone and win the game. I should have erred on the side of ‘extreme difficulty’ rather than ‘mindlessly easy’ gameplay for the competition, as this might have helped encourage players to replay the game a few times and notice some of the more subtle aspects of the game.

Subtle Aspects Of The Game

Alright, these were not particularly subtle, but in my intended high tension heat of the moment vision of the game that should have been, they were. I spent quite some time implementing effects intended to induce fear of the Anomaly. As the player descends into the gravity well, the volume of the ominous hum slowly increases from ‘barely audible’ to ‘Really Rather Loud’. A distortion of the field of view also occurs as gravity increases, most noticeable immediately before impact with the Anomaly. I also experimented with a variable focus depth of field shader, but this made my target hardware cry as it tried to emulate the shader in software.

The single ship window in the competition version was intended to contribute to a sense of claustrophobia amongst the asteroids, but instead failed quite severely, and probably contributed instead to forcing players to look forwards at all times. Post competition versions have extra windows, which help look out for incoming rocks as well as allow a player to glance at the monitors without losing their situational awareness.

Installerphobia

You know, every Ludum Dare I’ve been in I always notice that people prefer the games they can play in their web browser. That’s fine. I understand. But outright refusing to play a game just because you have to download it or run an installer is just laziness, especially when I take the time to cross compile to other platforms. I served my time with Flash. It’s just too limited for writing a 3D game in 48 hours. Unity3D would have been an option if it had a Linux client, but it doesn’t and probably never will, which rules it out for me. Of course Joe Judge comes along to rate my LD entry and sees that he can’t play it in five seconds time on the web, so writes an obnoxious comment and doesn’t play the game. One judge that rated my game admitted to me later that he didn’t even play it, but down-voted me because I packaged the game in an installer. So I didn’t get many plays for my game . Of course I’m sure that some people just didn’t like the look of it, but that’s a whole different issue.

Outcome

I’m pretty happy with INFALL. Played the right way, the game has the atmosphere I was hoping to create. Unfortunately it’s just too easy to play it the ‘wrong’ way, and there isn’t enough guidance for players that didn’t write the game. At some point I’ll hopefully find a nice balance for the game and release an updated version (probably sans music).

Gameplay

INFALL development timelapse

At this point, things were still reasonably sensible

It started off innocently enough. A nice simple map for a nice simple Ludum Dare entry, using my half written caveflyer engine. A map barely 1000 pixels wide, a mere 800 pixels tall. At some point I decided to grow the map a little, then a little more, and just a little more, until it reached 13312 x 20992 pixels, for a total of 279445504 bleeding pixels. And that’s just the background layer. There’s an additional foreground layer of the same size, though around half the pixels are completely transparent. I realised this was a little large and scaled the entire map to a quarter size, and then expanded it 4x in-game to try and compensate a little, but I wasn’t fooling anyone. My game was obese.

Graphic documentating the ridiculous overambition of my map

For some reason I decided that I didn’t need dynamic loading. I lived in some kind of denial, believing it would be no problem for anyone to run the game. I concentrated on trying to progress with the game rather than worry about trivial technical details. The game was running fine here after all. Then I compiled it for Windows.

If this game came on a disc, it'd have to be as big as a person (or robot at least)

At this point I realised I had a real problem. The game loaded in about 5 seconds in Ubuntu, but took closer to 30 seconds in Windows. I copied it over onto a similar machine and the game just didn’t load at all. I tried ten times, and the game loaded on the tenth attempt, and was using 2GB of RAM. Great. Works fine. Lah.

The jagged crystal hell of forgetting to include dynamic loading

I won’t pretend to profess that I know much about how Windows allocates it’s memory, but it seems that repeated launch attempts eventually allowed enough of the map to be buffered that the game was able to launch without erroring out before reaching the main loop. I could have tried to explain this to the people who were about to try and play and vote on my game, but I didn’t expect much in the way of sympathy. So at this point I decided to try and fix the issue. Hours and hours after I’d first identified the existence of the problem. So rather than writing new code in my now very limited remaining time, I tried to rework the existing loader to dynamically load on demand. This worked to an extent, but completely broke the map wide physics of the game, which relies on the map being loaded into memory to calculate what’s happening off screen. This approach is fine for the engine’s intended purpose of simulating a tightly claustrophobic subterranean combat arena, but fails somewhat at serving up seamless large worlds, which really don’t need much in the way of distant physics simulation anyway.

Robo1 contemplating his misfortune to be trapped in one of the worse Ludum Dare entries

But enough whining! What worked? Well, I managed to finish around 60% of the game. Considering how insane an undertaking it was, I don’t feel too bad about not finishing. There are a couple of cool things implemented. If Robo1 progresses far enough to locate the Obliterator, all kinds of fun can ensue:

Tunnel FUN

Probably the one feature of my caveflyer engine that was actually suited to this game was the destructible terrain. The protagonist does not start with the ability to destroy terrain, but obtains the ability through discovery. The original plan was to have the player collect the items which allowed them to fully explore the environment, eventually discovering the Obliterator, which would be used to bust open a sealed hangar door. Once this was open, the player could hop into a ship (already implemented in the caveflyer engine) and fly out into the outside area (left hand and bottom sides of the map image). From here the player would engage in a couple of dogfights before landing and discovering The Final Item, which I won’t talk about in case I actually get around to repairing and finishing this game.

Vigorous hangar door removal in progress

If you’re feeling sadistic, you can go download the game from the Ludum Dare entry page, but I can’t recommend it. I also recorded a timelapse which for me at least, is a bit more interesting than the game proper, bad music included.

I will be using a self written pre-existing code base so that I can spend some time actually making a game instead of spending most of the time making an engine. I’ve also preinstalled a collection of fine free FOSS audio editing and creation software, booked the time window (I’m in Australia and the hours are a little inconvenient, but WhatCanYouDo) and even made a half hearted attempt at trying to get some other potential candidates interested in entering LD19 themselves.

Now i just have to wait and hope that Double Zombie Rainbow is not the chosen theme

Crossposted from http://www.ludumdare.com/compo/2010/12/01/ld19-prep.

• Bison
• Flex
• Build-essential
• Python2.6-dev
• fftw-dev
• libgl1-mesa-dev
• libosmesa6-dev
• libxrandr-dev
• libtiff4-dev
• libxf86dga-dev
• libgtk2.0-dev
• libGLU1-mesa-dev

For the lazy:

sudo apt-get install bison flex build-essential python2.6-dev fftw-dev libgl1-mesa-dev libosmesa6-dev libxrandr-dev libtiff4-dev libxf86dga-dev libgtk2.0-dev libGLU1-mesa-dev

For the terminally lazy:

download my x64 .deb ~27MB (no guarantees etc, use an official release if you can)

Update: official release now available

I had a lot of fun writing an entire game in 48 hours. I chose to start from scratch (rather than take the option of working with an established self-created codebase or ‘game maker’ program), because I wanted to make the process as challenging as possible, and challenging it was.

I spent a good fifteen minutes designing the game, and the rest of my work time creating the media assets and writing the game. Fifteen minutes seemed like plenty of time, I had a reasonably good idea and figured I could work out the rest of the details as I wrote. This is perhaps best exemplified by me ‘finishing’ the game at around 9:30PM Sunday night, and then realising I hadn’t created any levels to actually play. So the game had no levels and had not been playtested. I threw a couple of maps together in bed, and then a few more on my morning commute, and submitted the game from work.

The levels are uninteresting. This is half lack of careful level design, half lack of assets to actually include in the levels. Some decorative tiles or animation would have compensated a little, but the limited gameplay mechanic really limited what I could do with the levels. Ultimately you’re either trying to time a dash past an enemy, or trying to have one enemy shoot another, which doesn’t create a great range of level design possibilities. Different enemy types (with different rotation speeds or patterns, or perhaps even movement or multiple hit-points) would have added a lot of gameplay options.

The game is slow. I didn’t really appreciate this until I saw someone else play the game and look away from the screen to talk to someone, without taking their hand off of the movement controls. The game is so slow that the player could have a conversation without having to worry about getting shot or reaching their destination. I could try and blame this on Pygame, (the development library used for Sporg), but it’s really an artifact of rushed development without adequate planning. It also didn’t help that I developed the game on my i7 920, and most people seem to still be running single core netbooks or something equally underpowered. I did actually do some of the work on an eee901 netbook, but obviously didn’t playtest the game enough to really notice.

Dodgy collision detection! Getting stuck on the walls, getting hit by shots that you might argue should have missed, having the enemy blast you through supposedly solid corners.. I was aware of these issues through development but postponed dealing with them. To be fair, I feel I made the right choice in prioritising the other issues which did get fixed, such as the horrible flickering issue and stuttering sound which were absent from the released version.

Next Ludum Dare, which I hope to participate in, will be different:

• DESIGN – I will give over a much greater portion of time to designing the game and it’s gameplay. I think I need to dedicate at least two hours, though perhaps not in a single chunk, in order to produce something that I actually want to play after I’ve written it.
• TESTING – Must test frequently! It’s better to produce a game with only 50% of your intended features working 100% than to implement 100% of features but have them work only 50% of the time, no?
• LEVELS – Or maps or whatever is appropriate. The game engine needs to be completed with plenty of time left to develop an interesting gameplay experience to play through.
• SCOPE – All of the above points are going to require time, which has to come from somewhere. I think perhaps the most important aspect for anyone developing a Ludum Dare game is to keep the scope as tight as possible. Focus on a small set of mechanics, features etc and do them well in a way that allows the player to experience what it is you dreamed up in that design period, rather than be distracted by incompleteness and bugs.

More details later, but for now, a download link:

Ludum Dare entry page: Sporg

sporg_ld48_release.zip (4407KB).

Rather than focusing on traditional game skills such as reflex and dexterity, Reverse Pong is instead a bluffing game of mental misdirection and brinksmanship which attempts to pit the personalities, rather than the skills, of the two players into conflict.

import random
import pygame

#revpong
#pong clone
#players score points by allowing the pong ball into their own goal
#every paddle deflection doubles the current ball value

pygame.init()
pygame.display.set_caption("Revpong")
screen = pygame.display.set_mode((800, 480), pygame.FULLSCREEN)
pygame.mouse.set_visible(False)
#screen = pygame.display.set_mode((800, 480))
windowsize = screen.get_size()

gameContinue = True

game_colour = (255, 255, 255)
clock = pygame.time.Clock()

font = pygame.font.SysFont(pygame.font.get_default_font(), 36)

paddle_dimensions = (24, 96)
paddle = pygame.surface.Surface(paddle_dimensions)
paddle.fill(game_colour)

ball = pygame.surface.Surface((24, 24))
ball.fill(game_colour)

ball_position = (windowsize[0]/2, windowsize[1]/2)
ball_velocity = (-4, 4)

#x positions of paddles
paddle_x_1 = paddle_dimensions[0] * 3
paddle_x_2 = windowsize[0] - paddle_dimensions[0] * 4

#y positions of paddles
paddle_y_1 = windowsize[1] / 2 - paddle_dimensions[1] / 2
paddle_y_2 = windowsize[1] / 2 - paddle_dimensions[1] / 2

#deltas of paddles
paddle_d_1 = 0
paddle_d_2 = 0

#scores
score_ball = 1
score_1 = 0
score_2 = 0

def reset_ball(ball_position, ball_velocity):
	random_y = int(random.random() * 5) - int(random.random() * 5)
	random_x = 2 + int(random.random() * 2)
	ball_position = windowsize[0]/2, windowsize[1]/2
	if score_1 > score_2:
		ball_velocity = random_x, random_y
	elif score_2 > score_1:
		ball_velocity = -random_x, random_y
	else:
		if random.random() > 0.5:
			ball_velocity = random_x, random_y
		else:
			ball_velocity = -random_x, random_y
	return ball_position, ball_velocity

ball_position, ball_velocity = reset_ball(ball_position, ball_velocity)

while gameContinue:
	clock.tick(50)
	for event in pygame.event.get():
		if event.type == pygame.QUIT:
			gameContinue = False

	#input
	keys = pygame.key.get_pressed()

	paddle_d_1 = 0
	paddle_d_2 = 0

	if keys[pygame.K_ESCAPE]:
		gameContinue = False

	if keys[pygame.K_w]:
		paddle_y_1 -= 4
		paddle_d_1 -= 1
	if keys[pygame.K_s]:
		paddle_y_1 += 4
		paddle_d_1 += 1
	if keys[pygame.K_o]:
		paddle_y_2 -= 4
		paddle_d_2 -= 1
	if keys[pygame.K_l]:
		paddle_y_2 += 4
		paddle_d_1 += 1

	ball_old_position = ball_position
	ball_position = ball_position[0] + ball_velocity[0], ball_position[1] + ball_velocity[1]

	#check new ball_position for collision with top and bottom edges
	if ball_position[1] < 12 or ball_position[1] > windowsize[1] - 12:
		#bounce off top or bottom edge
		ball_position = ball_old_position
		ball_velocity = (ball_velocity[0], -ball_velocity[1])

	#check new ball_position for collision with score zones
	if ball_position[0] < paddle_dimensions[0]:
		#player 1 scores
		ball_position, ball_velocity = reset_ball(ball_position, ball_velocity)
		score_1 += score_ball
		score_ball = 1
	if ball_position[0] > windowsize[0] - paddle_dimensions[0]:
		#player 2 scores
		score_2 += score_ball
		score_ball = 1
		ball_position, ball_velocity = reset_ball(ball_position, ball_velocity)

	ball_rect = pygame.Rect((ball_position[0] - 12, ball_position[1] - 12), (24, 24))
	#check new ball_position for collision with paddle_1
	paddle_rect = pygame.Rect((paddle_x_1, paddle_y_1), paddle_dimensions)
	if ball_rect.colliderect(paddle_rect):
		#if the ball has passed the paddle x middle
		if ball_position[0] < paddle_x_1 + paddle_dimensions[0]/2:
			#test if ball is up or down
			if ball_position[1] < paddle_y_1 + paddle_dimensions[1]:
				#ball is up
				ball_velocity = ball_velocity[0], ball_velocity[1] - 4
			else:
				#ball is down
				ball_velocity = ball_velocity[0], ball_velocity[1] + 4
		else:
			ball_velocity = ball_velocity[0] * -1 + 0.1, ball_velocity[1] + paddle_d_1
			ball_position = paddle_x_1 + paddle_dimensions[0] + 12 + ball_velocity[0], ball_position[1] + ball_velocity[1]
			score_ball = score_ball * 2
			score_1 = int(score_1 * 0.90)
			score_2 = int(score_2 * 0.90)

	paddle_rect = pygame.Rect((paddle_x_2, paddle_y_2), paddle_dimensions)
	if ball_rect.colliderect(paddle_rect):
		#if the ball has passed the paddle x middle
		if ball_position[0] > paddle_x_2 + paddle_dimensions[0]:
			#test if ball is up or down
			if ball_position[1] < paddle_y_2 + paddle_dimensions[1] / 2:
				#ball is up
				ball_velocity = ball_velocity[0], ball_velocity[1] - 4
			else:
				#ball is down
				ball_velocity = ball_velocity[0], ball_velocity[1] + 4
		else:
			ball_velocity = ball_velocity[0] * -1 - 0.1, ball_velocity[1] + paddle_d_2
			ball_position = paddle_x_2 - 12 + ball_velocity[0], ball_position[1] + ball_velocity[1]

			score_ball = score_ball * 2
			score_1 = int(score_1 * 0.90)
			score_2 = int(score_2 * 0.90)

	#draw
	screen.fill((0,0,0))

	screen.blit(paddle, (paddle_x_1, paddle_y_1))
	screen.blit(paddle, (paddle_x_2, paddle_y_2))
	screen.blit(ball, (ball_position[0] - 12, ball_position[1] - 12))

	screen.blit(font.render(str(score_1), False, game_colour), (0,0))
	offset = font.size(str(score_2))
	screen.blit(font.render(str(score_2), False, game_colour), (windowsize[0]-offset[0],0))
	offset = font.size(str(score_ball))
	screen.blit(font.render(str(score_ball), False, game_colour), (windowsize[0]/2 - offset[0]/2, windowsize[1]-offset[1]))
	pygame.display.flip()