Tuesday, January 28, 2020

How to be Terrible at Overwatch

This is something I wrote about a year ago.  It's unfinished (or "work-in-progress") but I thought I'd out it here for now.

After all, what's the point of playing as part of a team and winning the game when, even though you probably killed more players than anyone else, the game result will only mention that you were on the objective for 3 minutes, which impresses no-one.  It doesn't matter if your team loses as long as you're on that leaderboard with the most medals!


Work Solo

After you've been killed (along with probably several of your team), don't bother waiting for others to re-spawn and attack en-masse: just charge straight back into the match and get those kills in while you can.

Know where the battle really is

Okay, it's a payload mission.  But (if you're attacking) leave the boring task of moving the payload to other weaker members.  If you can keep a single enemy busy by fighting them in a far flung corner of the map, nowhere near the payload, that's got to be a good thing. And if you're defending, then the further back you can push the enemy the better.  It's not like any of them will be able to sneak past you without you noticing.

Team make-up

Stick rigidly to your favourite character, regardless of the makeup of your opposition; that way you get lots of practise at using them.



Make sure that you use his ultimate as soon as you have it.  Even if you've found a great spot to mow down the enemy, use your ultimate and charge right into the middle of the battle with your cannon firing.


This ultimate is ideal for getting revenge on a single enemy who's really annoyed you.  Just walk up to them a press the Suicide Ultimate button.  You will die yourself of course, but it's a small price to pay for revenge.


If you haven't tried this trick before: here's something that the other people on your team will find hilarious: when attacking, just a second before the spawn point opens, build an ice wall right in front of exit.  Brilliant!


One thing that impresses every player, and gets you a few more kills (maybe), is when you play as Mercy, rather than heal, show your skill by shooting enemies with your pistol instead.

If you do feel the need to heal, just concentrate on one single player, ideally a tank who has lots of health anyway.  Also, don't bother resurrecting anyone, as it will probably get you killed.

Another good tactic with Mercy is to select her at the start of the game, but then change just after everyone has left the spawn point.  It will take players a few minutes to realise they don't have a healer on the team.

Thursday, January 02, 2020

Reading PS4 controllers on a Raspberry Pi in Java

I recently had a go at trying to get a LibGDX to run on a Raspberry Pi.  Any project.  Unfortunately I failed.  (If you've succeeded, please let me know, but from what I could glean from googling, no-one has succeeded yet.).

So instead I tried to get some Java code working that could read PS4 controllers/gamepads on a Raspberry Pi.  My aim is to use the Pi as a mini-gaming-console, so I can keep it near our big TV and create some simple co-op games that I could play with my kids, rather than drag them over to a small laptop with its small screen.

And I succeeded!  By standing in the shoulders of giants (in this case, the JInput authors) and finding the native JInput modules compiled for AMD, it seems to work.

The repo is here: https://github.com/SteveSmith16384/jinputtest .  Currently only tested with PS4 gamepads.  Let me know if it works for you.

Wednesday, October 23, 2019

Recreating Speccy Games in 3D

I've decided to have a go at recreating some classic Spectrum games in 3D, with the eventual aim of stringing them all together into one big epic adventure.

Here's the first one:-

Tuesday, August 13, 2019

Open Source Software Statuses

Looking for open source software is a bit like getting a (free) car.  It might look good (or not) and in order to find out whether it is any good, you need to spend the time investigating it and using it.  It might be a supercar, but look like an old banger.  It might not even be built yet, or it might look amazing but the engine doesn't work.  Unfortunately, it always takes time, often to find out that it was a waste of time.

In order to alleviate this situation, I propose a set of statuses to help determine whether an open-source project is what you want:-

* Non-existent - No code has actually been written yet.  There seems to be lots of repo's in this state
* Not yet playable - Typically started, but won't run (or won't even compile)
* Runnable - it will compile & run, but who knows what will happen
* Basic but Playable - There is something to do, but by no means a complete game
* Fully playable - It's pretty much a game ready for players.

One thing to remember with open source is that they are never finished, only (eventually) abandoned, but that's not necessarily a bad thing.  If a project is fully playable, it doesn't matter if it's been abandoned if other people can use it.

These statuses do oversimplify the state a game could be in.  A game could be fully playable, but have massive bugs that cause it to crash.  Unfortunately, there's no way to easily categorise these.  But the above statuses will at least save people some time when searching.

Monday, August 12, 2019

Simple Platformer, with Source Code

I've written this simple platformer game using LibGDX.  It's a multiplayer game where the aim is to collect more coins than your opponents before you run out of lives.  The screen constantly scrolls upwards, and you have to avoid being left behind at the bottom.  I've tested it with PS4 controllers, I assume (probably incorrectly) that X-Box controllers should work as well.

Full source code is available here.

Wednesday, June 26, 2019

A New Roguelike Project

Roguelikes really suit my programming style: they can be ASCII based, which makes creating the graphics very easy, and they are usually grid based, so positioning entities and checking for collisions is simple.  This means that I can spend more time actually creating a game rather than writing all that boilerplate collision and graphics code.

I wrote my first roguelike (Astro Commander) several years ago; it was based on what I thought FTL was like, having never actually played that game.  I've now decided to write another roguelike, after deciding that 3D graphics are too much hard work.  Also, I wanted to have another go at creating an even-better ECS system.  And of course, the theme of the game will be a classic Spectrum game: Alien (Mind Games).

In this game, you will control the crew of Nostromo.

Do you know, I always feel I should write about the games I create in order to "get them out there".  However, when I'm excited about a new project, I prefer to spend my time creating it (rather than writing about it and taking screenshots).  Once this excitement has passed and I've completed all the interesting challenges, I'm then too disinterested in the project to bother writing about it, since I'll probably start another project and won't look at this again.
If you want to look at the source code, it's here.  It contains a good ECS system, and units can walk around.  But now I've decide the writing a co-op game is my next project, maybe in Unity.

Friday, June 21, 2019

What is an Entity Component System?

Let's assume you've written a game.  Imagine you've split your game logic into several well-defined classes, e.g. a movement class, a collision class, a drawing class.  Let's call them "systems".  Each has a specific and obvious role.  Also imagine that your game has a bunch of "things" that make up the game, such as the player's avatar, power-ups, bullets etc...  Let's call them "entities".

Each entity is basically a collection of data, and depending on what data it has, it can be handled by one or more systems.  For example, if it has "bounding box" data, it can be handled by the Collision System.  If it has image data, it can be handled by the drawing system.

Your game then works by cycling through specific systems that are required to run each game loop, e.g. Player Input System, then the Movement System, then the Drawing System.  Each system then "processes" all the entities that apply to it, e.g. draw all the entities which have image data.  Systems may well call upon other systems as-and-when required.  For example, your Collision System may call upon the Score System if a player's bullet hits a perp.

And that's it!

The advantage of this is that it's very easy to pinpoint which bit of code is doing something.  If there's a problem with the animation, it will probably be in the Animation System.  If there's a bug with collisions, it will probably be in Collision System.  If you need to implement explosions, create an Explosion System.

Designing a game now becomes a task of defining your systems based on what your game is.  Once you have clearly defined and scoped systems, the rest is easy.

I've created a simple ECS system which I use in my games, over at GitHub:  https://github.com/SteveSmith16384/BasicECS