I'm a programmer, and I've been programming professionally for 12 years, 8 of those using Java. But even I find it hard and confusing to download Java! So how's a layman supposed to do it, if all they want to do is play a game that requires Java?
I'm trying to download it to a PC now. Here's the steps I take (bear in mind I'm impersonating a layman here):-
* First I type in "Java" into Google. Oh good, the first result is a link to java.com.
* At java.com, there's a nice big link saying "Free Java Download". I click on it.
* Oh, this page says it's for Firefox/Mozilla. I don't want any kind of browser plugin, I want to be able to run programs on the desktop!
* Oh, there doesn't seem to be any other download link, apart from a small one at the top of the page, and that only takes me to the same "browser plugin" page.
* Let's try java.sun.com. There's a link to Java SE in the "Popular Downloads" list.
* What's with all the JDK's? I just want the runtime? (Though, being a layman, I have no idea what JDK, JRE, or "runtime" mean anyway).
* Aha, I've found a link to "Java Runtime Environment (JRE) 6 Update 2". Update? I haven't even got Java to be able to update it? Does it contain Java and the update? If so, do I still need "Update 1"? Who knows. I'll download it anyway. What hell, I've spent too long already.
* The download page has two links for Windows; one "online" and one "offline". I'll choose the "online" download, as it's only ~400Kb. There seems to be a tickbox to the left of it. Do I tick this? No, I'll just click on the link.
* Oh, I need to accept the licence agreement. Okay, done. Now I click on the link again.
You get the idea. By now of course, the user would have just gone onto something else that doesn't involve Java.
Friday, August 24, 2007
Wednesday, August 15, 2007
Overcoming Lack of Talent
Writing games while having no graphical talent, as I do, is a constant struggle of imagination vs reality. In my head I have ideas for great arcade adventures with whizz-bang graphics. Then I come back down to earth and remmeber that I can't draw a matchstick man without it looking like it has a limp. And it's always been the same even when I used to write stuff on the Spectrum (though in those days people's expectations were lower as the competition wasn't up to much either). Nowadays, when I see some of the amazing free (and amazingly-free) games, my heart sinks as I realise that I'll never be able to produce something just as good.
But with every problem comes and opportunity, and I've thought of a way I can get round my pseudo-disability, and that's to concentrate on the one advantage I do have - not sucking at programming (I think).
To cut a long story short, I'm going to design and animate 3D models using programming, in ways that would (I think) prove hard to do using a 3D modelling package.
And this is my very first attempt after about an hour of prog'ing away:-
Okay, so they look like Space Invaders that have learnt to walk, but it's my first attempt, and should go someway to showing what I want to achieve.
But with every problem comes and opportunity, and I've thought of a way I can get round my pseudo-disability, and that's to concentrate on the one advantage I do have - not sucking at programming (I think).
To cut a long story short, I'm going to design and animate 3D models using programming, in ways that would (I think) prove hard to do using a 3D modelling package.
And this is my very first attempt after about an hour of prog'ing away:-
Okay, so they look like Space Invaders that have learnt to walk, but it's my first attempt, and should go someway to showing what I want to achieve.
Tuesday, August 14, 2007
Monday, August 13, 2007
Gameplay Vids
I finally got round to creating some gameplay vids. Having these is an excellent idea (and I'm probably the last person to latch onto this) as it gives people an idea of how the game works. My first candidate for this is Nuclear Graveyard, as I think it's complexity puts a lot of people off playing it.
Here's a [very small] video from The Assassins mission, just as da boyz are about to burst into the house. It's only 30 secs.
On a slightly less happy note, development was stalled today because I made the mistake of installing Oracle's client software, which in turn installed no less than 3 (count'em!) seperate Java Runtime Environments (?), all of which were version 1.4 or less, and all meaning that most of my Java software suddenly didn't work. It only wasted about an hour of my time in working out the problem and solving it. So thanks a lot, Oracle - not! I spend a lot of my time disliking Microsoft, but it seems to me that most software companies are just as evil, but on a smaller scale.
Here's a [very small] video from The Assassins mission, just as da boyz are about to burst into the house. It's only 30 secs.
On a slightly less happy note, development was stalled today because I made the mistake of installing Oracle's client software, which in turn installed no less than 3 (count'em!) seperate Java Runtime Environments (?), all of which were version 1.4 or less, and all meaning that most of my Java software suddenly didn't work. It only wasted about an hour of my time in working out the problem and solving it. So thanks a lot, Oracle - not! I spend a lot of my time disliking Microsoft, but it seems to me that most software companies are just as evil, but on a smaller scale.
Thursday, August 09, 2007
Note To Self: Playtest!
I have a very short interest span in games, and especially short for my own games. This is my excuse for poor/zero playtesting.I just move onto a project I started a while back called DangerMan ( a platformer with weapons) since I've got bored of my latest project (though I will return to it eventually). And what a pile of bugs I found after only playing for only a few minutes!
Here are a few highlights:-
* If you shoot a rocket, you die straight away as it explodes immediately.
* Even when I got the rocket working, it destroys the scenery, but still draws it, because everything was being drawn twice in two different ways.
* The menu system gets confused with itself and you have to restart the program after a couple of goes.
* There was no mechanism for actually finishing a level (that I could tell).
I pity anyone who downloaded this game! It was completely unplayable, though it was at version 0.13 or something. I have now corrected these bugs and released a new version.
This leads me to my next thought - what's the point of releasing a game until it's finished? I suppose the source code is there for other people to examine/use, but if it's unfinished, why would they want to?
Tuesday, August 07, 2007
Threads - Don't Do It!
Here's a warning to anyone who's thinking of using threads - don't bother. Even if you've used them before, I think it serves well to be reminded (me included) that they should be avoided at all costs. Why? Because they make things exponentially more complicated!
Programming is complicated enough, trying to write a block of code that has zero bugs and defects. But what about if the variables you are using could change in mid-line? Or objects that you thought existed because you checked in the previous line now don't exist in the next line?
My multi-player games use at least two running threads; one is the main game loop, and another is the thread that waits for connections from players. This can cause problems in itself - the main game loop obviously loops through the players collection to send them data (and other stuff), but a player can join the game regardless of what stage the main game loop is at. So problems exist in that the main game loop could send all the players the current (say) ammo levels, but if a player had only just joined, they hadn't even been told that a particular unit exists in order to have a gun to contain the ammo!
Unfortunately, the keyboard input is also a seperate thread (as is the norm with Java), and until I corrected it, I was performing IO operations inside the KeyPressed() method. So the client software code could be halfway through sending the unit's location, when the player decide to press space to shoot, and suddenly a stream of bytes representing the "Shoot" command comes steaming through, completely confusing the server. The synchronised keyword fixed this problem of course.
This is just a few minor examples of threading problems. The irony is, that on the face of it threads seem like a great idea - like lots of little programs all doing their own thing. Unfortunately, it's when they have to interact with each other, which they always have to at some time, that problems start.
Programming is complicated enough, trying to write a block of code that has zero bugs and defects. But what about if the variables you are using could change in mid-line? Or objects that you thought existed because you checked in the previous line now don't exist in the next line?
My multi-player games use at least two running threads; one is the main game loop, and another is the thread that waits for connections from players. This can cause problems in itself - the main game loop obviously loops through the players collection to send them data (and other stuff), but a player can join the game regardless of what stage the main game loop is at. So problems exist in that the main game loop could send all the players the current (say) ammo levels, but if a player had only just joined, they hadn't even been told that a particular unit exists in order to have a gun to contain the ammo!
Unfortunately, the keyboard input is also a seperate thread (as is the norm with Java), and until I corrected it, I was performing IO operations inside the KeyPressed() method. So the client software code could be halfway through sending the unit's location, when the player decide to press space to shoot, and suddenly a stream of bytes representing the "Shoot" command comes steaming through, completely confusing the server. The synchronised keyword fixed this problem of course.
This is just a few minor examples of threading problems. The irony is, that on the face of it threads seem like a great idea - like lots of little programs all doing their own thing. Unfortunately, it's when they have to interact with each other, which they always have to at some time, that problems start.
Thursday, August 02, 2007
Interesting Enemies
I was watching Gamer TV the other day, killing 5 minutes and keeping up with the latest development in non-Free games department, and I saw a video of the new game BioShock. And I wasn't that impressed. It was only a quick video, and I was only glancing it at, but it gave me an insight into what a lot of games (including my own) lack, and that's "anything new". It's probably been said a million times before, but a lot of the games are just Doom with better graphics. I suddenly realised how boring an FPS can be if you're just wandering around shooting the odd enemy that appears. It's stating the obvious, but they need something new to keep the player wanting to play it.
It's with this in mind that I've though of something new! At least, I hope it is, and in the interests of open source and sharing ideas, it's going to a some kind of "fungus" that grows towards the player. It won't be easy to kill (probably impossible in fact) but the player will be able to shoot bits of it away.
Here's my first version of it. It's rudimentary (just using spheres), and I've still yet to perfect my fungus "ai", but it certainly makes an interesting and different enemy.
It's with this in mind that I've though of something new! At least, I hope it is, and in the interests of open source and sharing ideas, it's going to a some kind of "fungus" that grows towards the player. It won't be easy to kill (probably impossible in fact) but the player will be able to shoot bits of it away.
Here's my first version of it. It's rudimentary (just using spheres), and I've still yet to perfect my fungus "ai", but it certainly makes an interesting and different enemy.
Subscribe to:
Posts (Atom)