Complicated? Why yes, yes it is...

Well after tinkering with Java for a little while I have come to somewhat of a conclusion. (This might seem a little premature, but hey, I'm not getting any younger..)

Unless you have been tutored professionally, or have bucketloads of time to throw at it, Java is one hell of a mind-boggling beast! I've done a fair bit of reading and my usual amount of tinkering and messing about (I've never known such an unforgiving language!) but it seems that you have to jump through hoops just to get even the most basic of tasks accomplished.

This gives me even more respect for people who code fluently in this language.

I have managed to open a window, and render some rudimentary graphics but they really are basic. And I do mean basic. I started with this...

...and after some messing around, managed to persuade it to evolve to this...

...but it was far, far from straightforward. I also found that unless you dig really deeply, a lot of the language syntax can be confusing. For example a loop will execute the first line if you don't encase it in braces (and the compiler won't notify you that you have omitted said braces). So when you add a second line to the loop, the whole thing throws a wobbly and returns some totally unrelated error message - both in NetBeans and Eclipse. 

Believe it or not, here is a snippet of code I wrote to create that second image above. (Yes, I realise it's called "zombies", there is a story behind that which isn't worth going into here)...

...confused? So was I. And a single upper case letter where a lower case one should have been and, well, let's just say it didn't like it much.

When I first decided to have a look at this language, I had the idea of making a (really) simple game, maybe in an Applet that could run in a web browser. As soon as I started reading about graphics animation, I pretty  much changed my mind there and then. I might give this another look after I've had some sleep, but I think I'll be jumping back aboard HMS DBPro, where I feel more at home and it doesn't take 20 lines of code to draw a pattern in a window.

I think I'll leave Java to the professionals. And the young people :)

First steps...

I know it's only been a day or so, but I have taken some tentative first steps and I want to log them here :)

The first thing I had to decide on was which GUI (Graphical User Interface) Environment to use with my Java experiment. As I don't know the first thing about this language, I'm not really qualified to make an informed choice about this, so after a little sniffing around I found the two most popular front-end tools seem to be Eclipse and Netbeans.

This is Eclipse...

... and this is NetBeans...

I know they look very similar, and as far as I can tell they pretty much do the same thing, so for the moment I'm leaving them both installed, hoping that if I've made the "wrong" decision as to which platform to use, I can change my mind later. If it even works like that, who knows?

Anyway, having browsed around java.com for a while, it seems that NetBeans is the GUI of choice, so that's what I'll stick with for now. If you're interested, Eclipse can be grabbed from HERE and NetBeans from HERE .

I don't know if you noticed on those pictures (which you can click on to enlarge, by the way), but my first Java code is in there. A fully working program! I have got a handle on how the structure of the language works (sort of, it's early days) and it looks a bit daunting, but manageable. Anyway, here's the code...

... and here's the resulting output...

Awesome or what ?! Now it's time to do some research...

Long time, no post :(

With the arrival of Battlefield 3 and a number of social events, it turns out that I have been neglecting my blog somewhat. However, with the excitement of BF3 dying down a little, and the upcoming potential free time due to Christmas holidays, I'm starting to get the creative itch again.

The EasyMatrix project is a fully working and usable application, and I do intend to use it at some point when I try and learn more about AI (Artificial Intelligence) programming, but at the moment I feel the urge to learn something new. I'm one of those people who can't stick with something for any length of time before being attracted to something new and shiny, but then I usually end up returning to the "old faithful" environments I'm comfy with.

I pretty much know my way around the DarkBasic language now, and finding solutions to programming problems is more a matter of "what to code" rather than "how to code it". If you're a programmer then that will make some kind of sense to you, I hope :)

So during the holidays I'm going to try and learn yet another programming language, namely Java. I have a few friends who already know Java reasonably well, and another couple of friends who have been meaning to take a look at it, but never got round to it. So I think I'm going to dip my toes in the water, and see what it's like. The only thing I do know for sure is that everything I need to learn the language is available for free online, so that's a huge plus in my book!

I'm going to try and keep this blog updated with my progress again, if only for historical reference so I can look back one day (while smoking my pipe and admiring my slippers) and think to myself - "remember when I tried to learn Java...."

It might turn out that after a bit of sniffing around, I decide that the language isn't for me, but right now my intentions are clear. I'll let you know how I get on.

Video Demo

Just a really quick blog update this time. (Yes, I've said that before, but this time I mean it...)

I have made a short video demo of EasyMatrix at it's final Alpha stage. It's pretty much finished apart from a front-end which I am working on now.

Before you watch the video, I need to explain a couple of things. Firstly, I used some free software to grab this video, and the colour rendering isn't brilliant, so towards the end - at the bit where I flood-fill the matrix with "grass" - the colour looks really weird. The program renders it perfectly, it's the video grabber that is distorting it. Also, the mouse pointer is visible throughout the video. It isn't there when you are actually using the software.

So that's it. Enjoy the video and I'll see you soon. Next stop planet Beta!

Quickly approaching the beta stage...

EasyMatrix is getting to the point now where it's almost at beta. I have tons of ideas that I'd like to implement, but I am hesitant because (a) The whole point is to keep it simple to use and (b) originally I only wrote this as a tool to help myself create levels for my AI experiments, and it can already do that!

Since my last blog update, lots of cool stuff has happened...

• I have now written the texturing routine, which includes a "Texture Paint" function
• After a suggestion via the DarkBasic Forums, I have changed the node indicators from spheres to cubes
• I can now Export a matrix design, and Import it again, complete with textures
• I have implemented "AutoSave" which intelligently saves the design if any changes are made
• I have moved away from an imported 3D object for the selector rod, replacing it with an internally rendered model.
• The user can now toggle the "help panel" on or off
• A few internal routines have been completely rewritten for extra efficiency
• The code is now fully "Remmed Up", more concisely than I ever have in the past

There are a couple of things that I'm still looking at...

• A "Flood Fill" function which covers all the tiles with the selected texture
• A "Node/Tile Drag" function when you drag the selection up/down rather than click to raise/lower
• "Auto Texture by Height" which automatically textures a tile depending on its height (experimental)
• "Lamp Posts" which allows the user to place a number of light sources

So it's getting there. I can throw together a perfectly usable level in about 5 minutes which, if coded without using EasyMatrix would take me the best part of a day (including texturing). That's pretty efficient in my book.

Of course I still need to code for the user-selectable bits such as Matrix dimensions, number of tiles, minimum and maximum node heights etc.., but I have pseudo-routines already in place that just need a graphical front end writing.

One thing I will have to look at is the texture pack. The one I'm using is just cobbled up from stock PaintShop Pro textures and colours, and I really am hopeless at graphics. But the idea is that the end user can replace the standard texture pack with one of their own design anyway. Maybe in a later release there will be a couple to choose from. Now if I could only talk someone into throwing some packs together for me..

I just made this level to show the editor in action (it took about 3 minutes), imagine that with a higher resolution (more matrix tiles), better textures, some light sources dotted about etc.. and you get the idea of what I'm trying to ultimately achieve here.

The alpha version used while writing this post can be downloaded FROM HERE.

My biggest "problem" at the moment is that I've fallen in love with Call of Duty 4 all over again...

A near-usable tool!

I got some really productive coding sessions in over the last few nights. Yes, there were the usual bouts of frustration mixed with raw expletives and sprinkled with a topping of "wtf?", but on the whole, I got loads done.

First up, the viewpoint movement routine. I tried various methods of achieving this, but it turned out that the most effective was one of the simplest. Move the selector rod to a tile, hit "C", and the camera then centres on that tile. Simples. I had to code an assist routine, because when the camera makes the jump, if the tiles aren't yet textured (and they're not because I haven't wrote a texturing routine yet) it's easy to become disorientated and lose track of which tile you centred on. To aid here, I have made a translucent cube appear on the centred tile, and slowly sink down through the matrix. This instantly shows which tile the camera was focused on...

Next up, the Save and Load routines. Admittedly, these do need more work, but the basics are there and I can actually export matrix data, then re-import it. Sort of. What you have to remember is that there is no "Save Matrix" command available. (Or "Load Matrix" for that matter). Both of these routines have had to be built from scratch, and I've probably gone right around the houses to get them where they are, but it's a learning curve.

So on to the issues. Firstly, the Save isn't 100% reliable. That's not a great start. I'm still trying to nail the problem down, but when it does save - which is 9 times out of 10 - it actually saves data. It's just that now and then it completely refuses to export anything at all, and I'm not sure why yet. By the way, these Load/Save tools aren't like your standard Windows dialogue boxes or anything fancy like that, they are pretty much "Press S to save then type in a filename" or "Press L to load then type in a filename" affairs, but I'm a beginner at this so I have to start at the beginning. Or something.

Anyway, on to the Load routine. Yes, it loads the data I saved earlier. Unfortunately, it doesn't pick up on any texture data, and I can't work out why - yet. So I get the Matrix shape loaded, but it's completely wireframe. I know I haven't wrote a texturing routine yet, but all the tiles are textured by default, and it's not picking those values up for some reason. But I'll get there.

So the following pictures show what is currently happening when you export a matrix, then shut down the program, then open it again and import that saved matrix. As you can see, the correct shape is there but that's all. Having said that, getting this far was no walk in the park.

 

Finally, I've started work on the texturing routine. This is a standalone program at the moment because I want to figure it all out before I embed it into EasyMatrix. Basically, the program takes a bitmap which contains all the textures needed for the level, cuts it up into 48 small pictures, makes 48 sprites from these pictures and lets you manually select which one you want to work with. The "active sprite" as I call it, is shown at the top of the swatch as a full-size (128 x 128) texture tile, ready for application to the Matrix. But I haven't got that far yet.

As you can see, the mini-swatch rotates slightly, to give you a quick indication of where abouts in the texture pallet you are.

So that's about it so far, it's a near-usable tool but not quite there. I would say another couple of weeks if gaming doesn't get in the way. Which reminds me, I re-installed Call of Duty 4 and completed it again this last week. I forgot how much better than Modern Warfare 2 it is. Now I'm getting hooked on the Multiplayer again. So I managed to do that, and get a fair bit done on EasyMatrix. It's been a good week, coding-wise. 

Off on a tangent...again!

Anyone who has been following this blog will know that I tend to shoot off at random directions when it comes to coding stuff. I'm weak like that, too easily distracted.

Once again, while researching and writing test routines for my AI experiments, I got a bit fed up of working with a flat floor. My newly acquired model objects demanded some more interesting scenery to interact with. So I decided to bang together a quick program which created a randomly generated "matrix" of tiles. But the problem was that they literally were too random. Yes I could apply various restraints etc, but I wanted something that would reflect a realistic game level.

So again I "went off on one" and started a new project. This one is a level editor of sorts, based on a matrix system. This will actually be a useful tool I think, because not only can I use it to make test levels for the forthcoming AI routines, it can (or rather will) be used to make actual game levels once I learn how to code AI.

I was also partly inspired by the "MouseCam" routine mentioned in my previous post. This proved to be very handy in my "EasyMatrix" program, essential in fact. Also, you might remember at the end of my last post, I talked about working out a routine that would convert the mouse input for use in a 3D environment. Well, I nailed that one too! (An achievement I am pretty happy with, if I'm honest.)

So now I can control the camera in 3D space and I can use the mouse to point to any object or area within that space. I just know these routines are going to be useful to me one day, and they are already deeply embedded in my EasyMatrix project.

That picture shows the concept of EasyMatrix - a tile based editor, with 4 editable node points per tile, and a 3D viewing angle. This image was kindly rendered by my friend (and 3D/game design artist) Tom Joyce.

The development of EasyMatrix has flown along so quickly over the last week that I haven't really taken many screenshots. I must throw a shout out to another friend (and mathematical genius) Ragnar Karlsson, who helped me out with a particularly tricky algorithm. I never was any good at trigonometry.

Anyway, this is what EasyMatrix looks like right now...

 

That bottom picture shows the same viewing angle, but the left one is in "edit" mode while the right one is in "real world" mode. It will look a lot better when I implement the textures. It is still possible to edit the matrix in "real world" mode, but you have to be pretty accurate with the pointer, because the helper objects (red dots) are turned off.

So next I need to implement a way to move the point of view (at the moment you can pan around but the camera always points to the dead centre of the matrix), and I need to look into texturing the tiles, and I also better figure out a way to actually save or export the matrix otherwise this whole thing will be pretty pointless.

If you want to have a play with an early version of this, you can download the file by CLICKING HERE. It's a .rar file so you will need to unrar (unpack it) prior to use.

There are only a couple of requirements...

• You must have at least DirectX 9.0c installed. But you already will if you're a gamer, right? (Get DX9 here)
• Your mouse must have a clickable wheel. The camera pan only works when you hold the wheel button down.

That's pretty much it really. It will still work if you don't have a clickable mousewheel, but your view will be very VERY restricted. 

Now, I should make a start on that viewpoint movement routine. I think there is some Magners in the fridge...

New ideas..

Well Tank has only been on ice a few days and I'm already itching to learn new stuff. One of the major issues I faced when writing Tank was the choice between single player and multiplayer. As it happens, in that instance multiplayer won out.

Now I feel an overwhelming urge to learn about Artificial Intelligence (AI) and how it can be used in a single player game scenario. After researching for only an hour, I am coming to realise that this is a huge, complex subject, and even the simplest AI routines are going to take some serious thinking about.

Before I can even start playing with AI, I need to create a platform upon which to graphically display the results of the routines. Looking at a list of numbers never excited me like watching something moving around on screen. So I wrote a small program that displays a flat floor and a 3D object, and lets the user move the camera around by using the mouse. The camera remains pointing at the 3D object, and stays a set distance from it, but this distance can be altered by using the mouse scroll wheel, a kind of zoom in/out setup. It's pretty rudimentary, but eventually it will have variables that define mouse sensitivity, zoom speed, etc... It already has minimum and maximum zoom levels, and ceiling and floor limits.

A while back, I was talking to a friend about AI routines and single player game design in general, and it turns out that he studied game design as part of his university degree. Not so much the coding side, but the overall game design itself. So I brought the subject up again last night, and managed to blag some of his basic 3D models to play around with. I find that having "characters" to play with rather than just basic cubes gives a little more incentive and inspiration when working.

So I'm working with Tom "Cypher" Joyce at the moment on this project, with him providing models and ideas while I'm trying to implement that into code. Tom is using Maya to build the models then exporting them to Google Sketchup then sending me the file. I am then resizing and reorientating them to suit the game world and exporting from Sketchup into a DirectX format that can be imported directly into DBPro. Right now there is a "soldier" on the map who can't move, turn, die, can't do anything really. But I can use the mouse to move the camera around him.

He looks a bit dull and uninteresting sat there, but there is no lighting applied yet, and that makes all the difference. I have some ideas about the AI routines, but I am already approaching a massive challenge, and that is how to work out the position of the mouse pointer with relation to the world floor. That sounds ridiculous really but let me explain; if the world was going to be completely flat then there wouldn't be an issue at all. A simple call to "mousex" and "mousey" would return the position of the mouse pointer. But I don't intend to keep the floor flat for long, this isn't Tank. When the floor really is 3D and has raised and lowered areas then it is going to be a LOT harder to work out where the mouse is pointing, all because of that extra dimension. To put it another way, look at your mouse now. You can move it left and right (x axis) you can move it forwards and backwards (y axis), you can move it diagonally (combination of x and y axes) but imagine if you could lift the mouse up off the desk. I need to work out the position of it there (albeit virtually) and do it in real time.

So before I even start to think about AI routines, the next wall is already in front of me - how to use a 2D input device to provide accurate input to a 3D application?

The next few days could be interesting...

Project on ice...

Well I knew this point would come, but I didn't think it would be so soon. Tank has evolved from a solid block simulation to a playable multiplayer game within a matter of months. It's my first pet project, and it will still be semi-active, but for now, I am putting Tank on ice.

I've decided to take a break from development of this particular game. I am itching to try new stuff. I want to learn about AI, bitmap-based text, new effects. There are so many elements involved in the creation process that I am starting to feel a little bogged down. The whole idea of me doing this was to get away from the feeling of stagnation, and up to this point I believe I've achieved that. From the joyous realisation of working out a routine, to the hair-pulling frustration of near punching the monitor, I've been through some extremes with this game. I think it's been a great project to get me back into coding, and I've learned a lot. Skills, I hope, which I can use in other, more original projects. I have plenty of ideas swimming around in my head.

I know it's bad practice to leave a thing like this unfinished, and I really do intend to come back to this at some point (unless someone wants to adopt it and continue development), but for now I have a real need to move on. Useful lessons have been learnt over the last couple of months, but so many corners remain unturned. I feel that now is the time to venture out and look around those corners.

I'll be blogging about it here again when I get something going, but for now I'll sign off with a few screenshots of Tank (Click the images for larger versions). The game made it to version 0.9a, nearly v1.0, but not quite. Fully playable, but in need of some bolt ons. I did what I set out to do. I created a game.

Hunting for enemies...

A near miss...

Shockwave...

Game Over!!

Multiplayer home-made server..

To be continued....

Who said explosions have to be Red and Yellow ?

Just a quick update this time, and I promise to keep it short.

I have been working on the shockwave/explosion routine of Tank in order to get rid of the side-effects presented when using Sprites for my explosions. I'm getting somewhere near now, so I thought I'd upload a short video of how it's currently looking. I do intend to make the shockwave a little less opaque, but it's still an early version of the routine.

The video shows a stationary enemy tank which already has depleted health - no one shot kills here. I fire at the tank but intentionally aim low, just to show the effect of the shockwave on that tank. If you look carefully, you will see my projectile falls far short of the enemy, yet the wave still takes him out. The shockwave is actually expanding while it exists, but due to the low frame rate of the video capturing software it's not that easy to notice.

As you can see, I decided to go for a "non-standard" colour for the explosion particles. I did this primarily for two reasons; Firstly, it stands out more when there is a distant battle occurring, and Secondly, I can do whatever the hell I like in the world of Tank :)

So that's it for now, other than a quick thank you to Nick Baumer for helping me see the light when coding the shockwave routine. I'm still not decided on an enemy locator function yet...

Network improvement! (mini-update)

Just a small update this time.

After testing the multiplayer feature over the internet, I am happy to report that it was a massive improvement over the previous version. I want to offer my thanks to Nick, Ragnar and Jonny for the testing session, which actually turned into a game (sort of).

That can only be good right?

So it turns out that there is a silver lining to last week's cloud of despair. Having wrestled long and hard against the pathetic TCP protocol, I found myself having to confront a completely different beast: the pathetic UDP protocol. Yes, both of these network communication methods are rubbish, complex and not very efficient, but it turns out that UDP is at least allowing my game to work. So the silver lining is that I have been "forced" to learn two methods of network communication. It could come in handy one day I guess.

So while testing the online gameplay, I noticed a number of other problems. Apart from the ridiculous amount of accuracy needed to hit an enemy (as described in the last blog post), it became blatantly obvious that using sprites for explosions isn't going to work. The main problem right now is that explosions always appear - even if they occur behind a building. I'll try to explain what I mean...

The "art" of aiming and firing a weapon involves many senses, and a person sub-consciously makes decisions about the trajectory and point of impact, based on multiple factors. One of these factors might be the results of a previously taken shot. The same applies to videogames. And there is a big flaw in Tank while using sprites for the explosions. If I was to shoot at an oncoming enemy player, and my projectile was to go straight over his head and hit the ground behind him, then the explosion would obviously occur at that point. But as sprites are rendered on a 2D plane (namely "in front" of the 3D plane) then the explosion would appear to be in front of the enemy tank. This would make my brain conclude that I need to aim higher (in order to shoot further), whereas in reality, I am already shooting too far.

So once again, I'm having to make a pretty major change to the game code, in order to rid the program of it's current explosion routines. Which, I might add, took me ages to get working. So I am working on a prototype routine which involves a primary shockwave at the point of impact, and then....well, I don't know what yet, it's still a prototype. But I am hoping to integrate the "splash damage" collision detection into this new routine. Also, it's going to be 3D based, so it's possible that shockwaves and explosions could be partially hidden by nearby buildings.

Here is a video of the very first attempt at this. Bear in mind that the sprite-based explosions are still present here, but you should notice that the shockwave on the further building appears "behind" the closer building. Note, when I make the first shot, the shockwave routine is disabled. I turn it on for the remaining shots.

The video is only running at 30fps, but it's just to demonstrate what I'm attempting to achieve.

So this is what I'm working on right now. Once I have it working properly in single player, I will create a multiplayer version. This is my primary task at the moment. 

I'm still thinking about solutions for the "where the hell is everybody?" problem, and thanks to suggestions from friends, they range from overhead icons, through a minimap to a full-on proximity warning system a la Aliens!

This was meant to be a mini-blog, but as usual I've found myself banging on and on. Let me sign off by saying the multiplayer system is totally useable now (even though I have an idea of how to optimise it further if needed), and I can press on with other important things, like blowing sh*t up!

Splash Damage!

If you read my last blog entry, you'll know that I'd hit a brick wall with the Tank project. My TCP-based network code simply wasn't cutting it for multiplayer data transfer over the internet. If I'd have done more research before putting pen to paper (well, fingers to keyboard...) then I'd have known this before I started.

Lesson learned.

So after wrestling with the intricacies of UDP over the last week, I've finally made some headway and managed to rewrite the network communication routines based on this new protocol. I don't want to rave too much about it at this point, because the new build is currently untested over the internet, although it does work well over my home network. Then again, so did the TCP version. A note; if you are considering converting something from TCP to UDP, don't look at some TCP code and think "hmm, how would I make the UDP version of that?" because if you do, you are asking for trouble. The two methods of data transfer are completely and utterly different to each other and the conversion involves so much more than simply replacing TCP commands with UDP ones. Trust me on this. Anyway, I'm not going to write any more about it until I've tested it with the guys from DaGodz, other than to say that I'm glad I took a few steps away from the project for a while. You don't know how close it was to ending up in the trashcan.

So, new developments...

At last, tanks can shoot at each other! A bit of a plus for a multiplayer Tank game I think. To actually show enemy projectiles, I had two realistic choices.

Either

• Send the positional data of the active projectile to all players except the one who fired it (because they already know). The other clients could then render the projectile based on this data.

  - Plus points: Ridiculously accurate positioning of the projectile, relatively small routine to handle it.

  - Minus points : Massive increase of network data flow, dropped/bad data packets would cause mayhem.

Or

• Send a signal to say a player has fired, use the client to render the projectile and calculate its path and velocity based on known turret position and angle values.

 - Plus points : Nearly zero additional data to be transferred for each shot fired, client already knows where the projectile will land (even before it is fired!), dropped data packets wouldn't be an issue.

 - Minus point : Not quite so accurate, but damned close (2 or 3 pixels maybe), quite a complex routine to handle the ballistic path.

In addition to this, players who are seeing a projectile being shot (but haven't fired it themselves) would need to generate the explosion at the point of impact, as well as all associated sounds. Bearing in mind these sounds need to be positional, otherwise an explosion at 500 metres would have the same volume as one hitting at 5 metres etc... (Same goes for size of explosion). So much to think about.

So I decided it's best to go for option 2. The "firing" player tells the server it has fired. The server tells all the other players this has happened. All the other players render a projectile and handle its trajectory, point of impact, collision damage and everything else. Here is a picture of my base routine for doing this. (Note this is an early version, and some comments probably won't make any sense. They don't to me, so why should they to you?! My comments are in Green by the way, in case you're a muggle.)

You can click on the image for a larger version if you're interested.

Whilst writing this routine, I noticed a few other areas that could do with tweaking, so I tweaked them. Bad mistake. When the program crashes with some error or other, I don't know whether it's my new routine, or the tweaks I did to the existing ones.

Lesson learned.

One huge problem I have found, which I never expected to be an issue at all, is that enemy tanks are seriously hard to hit! If they are moving, it's nigh on impossible. I'm imagining this will be somewhat of a problem. The grid doesn't look that big when you are driving around in a tank, but when you see how small an enemy tank appears, you get a completely different sense of scale. You only truly see how big the map is once you are dead, and you are presented with an overhead view of the "action". The active tanks are simply minute. To give you an idea of scale, each tank is designed to be 6x4x2 units in size. The game grid is 1000x1000 units.

To counter this unexpected problem, I am planning to introduce two "features". The first one is to have an icon floating over each player, which alerts enemy players to their position. This icon will be highly visible even from a distance (though not through buildings to begin with). I had originally intended to use this as one of the "perks" that a player could achieve during game play, but I think it needs it as standard, otherwise it's possible to drive around for ages without seeing anyone else.

Secondly, and I have no idea at all about how I'm going to implement this, is that the projectiles will have a "Splash Damage" effect on impact. This means that an area around the impact point will also generate damage. Less damage than a direct hit, but still damage. This way it will be possible to cause damage to an enemy tank even if you don't score a direct hit. I could even make this splash damage radius variable depending on power-ups.... (Getting ahead of myself yet again.See? I do that all the time...)

So still plenty to do with the project. I really hope the UDP netcode has sorted out the lag issues, because frankly if it hasn't, this will probably be a LAN-only game. I'm itching to get on to something more original now I have cut my teeth with Tank, and I really don't fancy spending any more time messing with data packets and crap like that.

First few items of the ToDo list...

• Work out some sort of "Splash Damage" function
• Make some sort of "enemy is right here" indicator
• Handle the event if a player disconnects mid-game
• Improve the view a player gets if he/she is dead and are waiting for the others
• Start thinking about a front end for all this...

One step forward, and two steps back...

Well after the highs of yesterday comes the dawning realisation that things with the Tank project are not quite as rosy as they seem.

After more extensive testing of the networking model with Lisa, Chris and Nick, it has become apparent that the TCP networking protocol used by Tank for multiplayer data transfer simply isn't going to cut it. I haven't even implemented projectile tracking, ammo & health crates, or vehicle-vehicle collision yet, and already the latency is more than noticeable. It looks like I'm going to have to start over with the netcode, but base it on the UDP protocol this time. That's a lot of recoding. Right now I'm wishing I had gone down the single player/AI route.

It feels like I've learnt to speak Japanese and I should have been learning Chinese all along.

This is a major setback for me and I could easily hit the "Erase Project" button right now. But I'm not going to be too hasty, I'll take a break from it for a few days and let my emotions settle down.

I have to end this blog post on a positive note, and it's not all bad news. I did manage to achieve a few goals. 

• The players now have dedicated spawn points. Previously they were randomly generated positions, which meant there was a chance that a player could spawn inside a tower. This would mean the player's health would steadily drop to zero causing death, without having been shot or anything. Pretty frustrating I'd imagine. The spawn points are in the corners of the game grid. The towers, while still being pseudo-randomly placed, are coded to stay away from these areas. I have also updated the floor graphics to reflect the new spawn areas.

• There is now an audible alarm that sounds when the player health remains below 20%. This is a bit annoying at the moment (as there is currently no way to replenish health), but it's supposed to be annoying right? It's a warning! Once there are ambient sounds and vehicle movement noises added, the sound will fit in with the game a little better. I think.

• There are now routines in place for when the Tank drives off the gaming grid. The Tank object disappears and is replaced with an explosion (still loads of work needed on this), then after a delay of a few seconds, the player is switched to an overhead view of the grid, so he/she can watch the battle continue between any remaining players. Again, this still needs a lot of work, but the basic functionality is there.

• There is a routine in place for when the Tank collides with a tower and dies because of it. It works in a similar way to the "Tank off grid" routine.

• My proudest achievement of this version is the way the towers are now generated based on a known seed. All players get the exact same map, based on a single integer passed to the client from the server. From this variable, I can instruct the client to generate any number of towers, with their x and z co-ordinates, their width, depth, height and texture all matching perfectly across the connected players, and all from a single transferred number. If it wasn't for this single achievement I think I would have given up on this by now.

So to sum up (because I'm banging on a bit now), the project at this moment is hanging in the balance between "Something I'm working on" and "Something I worked on". On one hand I'm wondering why I put myself through this, and on the other I'm considering it a learning experience, complete with its ups and downs.

One thing's for sure, you don't realise how much work goes into creating a videogame until you try to do it yourself.

A place I thought I might never be...

Some great news this time!

Tank is now at the point where multiple players can connect to a game server and interact with each other! If I'm honest with myself, this is a place I thought I might never be. It's not over yet, not by a long chalk, but I feel good that I've managed to get this far. Of course I couldn't have done it without the guys from DaGodz. Suggestions, encouragement, but mainly help with testing the multiplayer code all add up to what I am considering to be a team project.

So I have decided, as this is my first multiplayer project (and I want to keep it real about what I am able to achieve) that Tank is initially going to be a 4 player game. The netcode over a LAN can handle 16 players in theory, and we've tested it to a point over the net with 10. But there is a lot more data I need to throw around, and for it to be viable over the internet using the TCP protocol, 4 players is a realistic starting point.

There are 101 things left to do. For example, currently the players can just drive around the grid, ramming each other! There is no code in place to allow them to shoot. If you drive off the grid, the game closes. If your Tank health reaches zero, the game closes. There is no facility to replenish health or ammo (other than using the "God mode" magical "A" button, which will obviously be removed for the v1.0 release. Also, I had removed the towers for the multiplayer test. The reason for this is because they are currently randomly generated in position and size. This means that each player would have a different layout of towers which is obviously wrong.

So here is a picture of a multiplayer game test. It shows the server running on the right, and each player in a small window. OK, it's not very exciting to look at I know, but it's an achievement. In this test, each player is on a seperate PC on my home network, but the test I did last night with Ragnar and Nick proved that it works just as well over the internet.

My next goals are to have dedicated spawn points for the players (they currently spawn at random locations), set up some kind of tower scheme where all players see the towers in the same places, and I need to lock the server when 4 players have joined, to stop people joining mid-game.

Of course the whole thing needs a front end, death sequences, ammo and health crates, slightly better collision detection on the tanks, more sound effects and of course, the ability to actually fire projectiles at each other...

Alcohol could be the answer?

It's official - being drunk puts your mind on a clear path to programming enlightenment.

I wouldn't have believed it if I hadn't experienced it myself this very Easter weekend. Based on that statement, I can only assume that being completely sh*tfaced leads to some sort of coding Nirvana, but that's an experiment for another day.

I feel a little back-story is required. Every Easter (and August) Bank Holiday I meet up with a collection of like-minded friends in a London suburb and we generally have a laugh, play videogames, get drunk, have a dodgy barbecue, stay up ridiculously late then crash out into a tent that doubles as a greenhouse etc..., I'm sure you get the picture. Anyway, Easter just gone was no exception. Now I wouldn't usually dream of coding at a LAN party, but there were a few chill-out moments between games and this multiplayer issue was getting me down, so I thought "sod it, I'll take the flak" and opened up my development software. As it happens, no one gave a toss. (That's what it's like at these events - anything goes and no one judges you for it - we're all equals there, regardless of profession, race, gender, age, weight, height, Android/Apple allegiance...)

Anyway, after trying different things with the code, I was again getting frustrated with myself for constantly failing with the multiplayer data transfer problems I was having. Of course I was offered drunken solutions to the issue, friends hosted testing servers for me etc, but it simply wasn't happening. So I resorted to more Cider. Magners to be precise. After a while I had a strange sensation of just "knowing". Now I know that sounds like complete crap but I swear, it's as if being a bit drunk opened my mind to new ideas, it aligned my thoughts and made things clearer!

So after a few more drinks, and a few more mods to the code, and few tweaks here and there (nipples included) - I fired it up and lo' and behold I had a connection between the host and the client! I mean a connection I could send data packets across, quickly and reliably. Now I know that isn't a big thing, but to me it's a massive achievement, one that has been eluding me since...er....I can't remember, you'll have to read earlier blog posts.

So even though there is a long way to go, I am one step closer now. And it kinda made the weekend a tiny bit more enjoyable for me. Strange how different things affect different people eh?

Here is a picture of the client sending some data to the server, just for historical reference as much as anything. The data transfer is quick and reliable, and now hopefully I can progress a bit.

This might be laughable to many people, but to me it's a monumental achievement!

So now all I need to do is go through the code line by line, working out exactly how I can use the transferred data in an efficient way. I also need to build a proper datagram; the one I used here was just to see if I could actually get the data across reliably. It's still really early days, but everyone has to start somewhere, right?

I've had many experiences this weekend, some of which have already transformed into treasured memories, and I've learned one crucial thing regarding the development of Tank - if I'm ever stuck on something and there doesn't seem to be a light at the end of the tunnel... 

Have fun,chill out, get drunk and the answer might just reveal itself!

The failcakes are baking...

OK, this blog entry is a little depressing for me to write.

I am really, really struggling with the multiplayer thing. At the moment it feels like I've hit a brick wall and I can't see a way over. This is the first time during the life of this project that I have felt deflated, and came close to giving up on more than one occasion.

On a more positive note, I have learned quite a few things about how multiplayer games work. Although that is bittersweet because it also shows me how far off the mark I am. To break it down and really simplify it, the basic premise of client/server multiplayer is like this..

• Hosting server constantly listens for new connections
• Client connects and is assigned an ID
• Client is sent data regarding other player position, orientation, state etc..
• Client processes all this data and updates the game state as necessary
• Client then builds a "datagram" of its own playerstate and sends to the server
• Server receives and acknowledges that information, processes everything, then passes it on to the relevant player(s)
• Back to step 3..

Now that sounds easy, right? Well in theory it is. OK, I've not even mentioned projectile positions and paths, collisions, explosions, sounds etc, but I've learned two pretty major things lately...

Firstly, if you're going to write a multiplayer game, you need to code for it from the start. You can't just "bolt it on" at the end which I am pretty much trying to do. The multiplayer code is so embedded, so integral to the core of the program, that nothing short of a rewrite would make it happen properly. That's not going to happen here.

Secondly, the data packets that are transferred between the client and the host need to be unbelievably efficient. They need to contain all the necessary data, and yet be tiny, and at the same time need to be sent only when absolutely needed, and in a set order. Adding to this, data packets don't always arrive at the server in the same order they were sent, sometimes they don't arrive at all. So this raises the need for prediction and correction algorithms. And all this is happening 60 times each second.

So far, the multiplayer code alone contains more lines than the actual Tank game, and I've only just got it to connect reliably to the host. I'm not giving up on it yet, but I am so close!

All of this has made me realise (and respect) the amount of work that goes into modern day games that we all take for granted. Now I understand why games like CoD have seperate executables for single player and multiplayer, or those games which have a single exe, are usually huge in terms of redundant code.

So right now, I have written a hosting server. Clients can connect to this server and stay reliably connected. The server also knows (and handles the event) when a player leaves for whatever reason. All this works on a local host (127.0.0.1) or over a LAN connection, but that's it. One client doesn't know if another has joined, left, died, fired or anything. I'm still working on it but I'm starting to wish I'd gone down the AI/singleplayer route.

The failcakes are slowly baking but they're not quite ready to eat. Yet.

Server? What server?!

Well the game has now reached version 0.7a - it's "playable" in that you can drive around the map, firing projectiles at things (mostly towers, the floor etc..) and it detects collision damage a lot more accurately than the last version did. There are no enemies to shoot at yet - see later in this blog post as to why.

So now the floor has a texture - actually there are two floors - one is placed slightly lower than the other, but the upper one is transparent (a bit) so you can see the one beneath. This gives the effect of parallax scrolling while moving, without actually having to write any scrolling code :)

The "Towers" as they are now known, also have textures and the projectile knows if it's hit one, or the floor, or gone off the "gaming grid". An appropriate explosion or sound effect is generated depending on what has occurred.

I have tweaked the Tank attributes a little too. It now drives a bit faster, but I still need to look at the turning circle. The damage meter is more accurate now, and if too much damage is taken then the game ends. At the moment it just ends with a message as to why you died, but the plan is to put some sort of routine in there. It is also possible to die if you go out of bounds now (or "off grid" as I call it).

Various sounds have been added as well as the explosions. There is an effect for when the Tank has no ammo and thus is unable to fire, and there is an effect for when a projectile is fired "off grid" or falls down the (intentional) gap between the edge of the grid and the surrounding "walls".

Earlier I mentioned enemies - as in, there are non yet. Now I have to make a huge (in coding terms) decision here, and that is whether to go down the multiplayer route, or turn this into a single player game. Both have advantages and disadvantages. I know how to code neither :(

Single player obviously won't require me to learn how to create netcode - and trust me, I don't know where to start.

Multiplayer won't require me to learn how to create AI code (Artificial Intelligence) - and trust me, I don't know where to start.

The other thing about Multiplayer - I will need to write a hosting server. WRITE ONE. There is no download available for this. As you know, the game is completely original and written from the ground up. If I want a hosting server, I'm going to have to code one. From scratch. But multiplayer can be amazing fun and well worth the effort, and it will give me some coding knowledge I can (hopefully) use in future projects.

Not that AI programming isn't just as important. Even multiplayer games have NPC's (non player characters) that rely on AI routines to give them life.

So I'm at a crossroads right now. I think I'm going to attempt to write the MP server code and see how I get on. If it is above my ability - and I fully expect it to be - then I might have a crack at AI. Though that is probably above me too.

One thing is certain though, without either Multiplayer/Server or AI, there will be nothing to shoot at. (Apart from Towers....)

Projectiles Ahoy!!

Did some more work on "Tank" today. After discussion with my IRC friends (yes, they are friends in real life too!), the game seems to have chosen that name for itself.

After some highly technical (and frankly, baffling) talks with a highly intelligent colleague, I've decided it might not be a great idea to use PhysX for the in-game projectile movement. This makes LOADS more work for me because now I need to code some sort of physics engine in software to allow for gravity and the ballistic properties of the projectile, but the reasoning is sound - if this game is to be played multiplayer - which is the eventual aim - and some players have nVidia cards (with a PhysX GPU) and others have ATi cards (software only PhysX) then there might be some discrepancy with the projectile placement co-ordinates, thus giving nVidia users an unfair advantage. Presuming the hardware GPU is more accurate than a software one, which one would expect.

Aaaanyway... Tank now has a turret. It is movable by design only along the x-axis (it can only be raised and lowered, not swivelled left to right). I did this for two main reasons, (1) to control a turret independently of the main Tank body would mean having an extra set of controls. While this wouldn't be too hard to code, I want this to be an arcade game not a Tank simulator. And (2) after playing around with the game model, it's too easy to turn the turret to 90°, pop out from behind a building, fire off a shell, then reverse back behind the building. At least if the turret is fixed (along the z-axis) then the player will be forced to drive out, physically align his Tank with the target, then fire off the shell. This will hopefully force the gameplay along and not turn it into a pop-out-and-shoot-then-hide turn based game of chance.

Talking of the projectile, the Tank can actually fire one now! OK, at the moment it's just a White sphere, but just pretend it's a Quazar Pulse*. Or something. I have incorporated a reload cycle to stop spam-shelling, and an ammo counter which depletes with each shot. The plan is to eventually have ammo crates dotted about at strategic positions. Of course during development I can re-arm the Tank without an ammo crate.

The projectile also incorporates collision detection. I'm still working on this subroutine at the moment because it's not entirely accurate (or it can be very accurate but slows the game down too much for my liking). My next job is to optimise this collision detection routine. Also, I need to write something that signifies the shell has hit a building or something.

The Tank also has a very primitive health system which I am still tweaking, more of that in my next post.

UPDATE: Here is a small youtube video showing the engine in action. As you can see, I have written an explosion routine, but the projectile doesn't disappear just yet.

Onwards and upwards...

(*The term "Quazar Pulse" is copyright ©petethesparky 2011).

Making some progress

I had a good day today. While the end isn't even in sight yet, I feel compelled to do more and more, the ideas are flooding in with each addition I make to the program. I need to keep it real though and not be tempted to add things to the plan that I have no ability to realistically implement.

I now have a floor upon which "Tank" sits. It is flat, and textured randomly with a selection of Four tiles which change each time I run the program. This is only a temporary solution, once I somehow get a graphic artist on board, I should be able to get a futuristic tile set created which  will make it look so much better. I am so pathetic at graphics that I've just labelled them Tile 1 - 4 for now. But at least the code works. If the tiles are to have any form of intentional placement, then I'm going to have to code some sort of level designer. That in itself is a large undertaking given my limited knowledge of coding. But this is why I started the project right, to challenge myself?

So at the moment, the entire tile set looks like that. Impressive huh?

I also added some "buildings" instead of the block which I was using to judge speed and distance. These are currently just randomly placed blocks of varying height. Again, to create a meaningful level, I'm going to have to invent some sort of level editor. But at least I get the feeling of driving as I manoeuvre Tank along the paths and inbetween the "buildings". And I implemented collision detection now! At the moment it just stops Tank dead but it's a start.

My ToDo list is growing by the hour, and I don't know where to begin. But I've only been at this for a few days, and already I'm starting to feel like I've accomplished something.

   

First Steps

I actually started coding today. It is the most basic of stuff, but it is code - and it does something!

The package itself has some great help files, and the community forum is really good, it didn't take long to get the hang of some basic commands. Some of them I remembered (miraculously) from my coding attempts of the distant past, but the ones I've used so far are very self-explanatory, such is the way with BASIC, it's the main reason I chose to use it.

Anyway, so far I've managed to accomplish the following:

• Set up a display port, and limit the framerate to 60fps using the vertical sync.
• Hide the mouse pointer
• Set up some variables (Integer and Floating Point)
• Create and position a 3D Block (which I am calling "Tank" for the moment)
• Create and position another 3D Block, set it to be semi-transparent, and make it rotate at the rate of 0.25 Degrees for every cycle of the main program loop (This is a temporary marker which I can use as a reference point to judge distance and speed of "Tank")

and here is the cool part... (well I think so)...

• Use the cursor keys to move "Tank" forwards and backwards, and turn left and right - at rates defined by the variables I defined earlier
• "Tank" is also affected by a friction variable, meaning he doesn't stop instantly if you stop pressing the "up" key, he gently slows to a stop. I intend to use the friction variable to accommodate different driving conditions/surfaces. Maybe.

That's pretty much it for now, here is a screencap of where I am right now...

Starting point

Not really a blog update as such, but a screenshot of what I'm looking at right now.

This is where I start, I guess...

Development platform

So I did some reading on the various development platforms available. They range from a "point and click" game creation studio, right down to barebones C++ coding.

I needed something that was reasonably powerful, yet easy(ish) to learn and use. Something that wouldn't take me weeks and weeks just to be able to open a viewport. This pretty much ruled out C++ and Java. Yes, they are both great dev platforms but the basics alone are pretty overwhelming. I want to create something, not get bogged down in the how's and why's of what makes a machine tick.

I did consider Microsoft VB (Visual Basic) but it seemed very restrictive graphically, and most of my ideas rotate around a non-text based game scenario. There are a couple of very impressive (and not too expensive) high level languages out there, which can be compiled down to low level code and give quite impressive results. I was torn between Blitz Basic and DarkBASIC Professional.

I have used DarkBASIC Classic in the past, so I was already edging towards DBPro as my choice, but having read a little more, I noticed that DBPro is very different to DBC. So I did a bit more reading. Both platforms are based on BASIC (Beginners All-purpose Symbolic Instructional Code) but to be honest, the word "Beginners" is a little bit of a misnomer because it can get pretty complicated in there!

In the end, DBPro won out. There is nothing wrong with Blitz Basic, but the sheer amount of support, resources, plugins and add-ons for DBPro won me over. Not to mention the support for Sprites, Shaders, PhysX and DirectX generally. It helped that there was a great offer on DBPro over at the official site (good timing or what?), so a quick blast with the credit card and a download later I am left with a fully installed and set up GUI with which to start work.

A blank canvas.

And so it begins...

Creativity.

It's there in all of us in one form or another. The need to express ourselves through art, it's what sets us apart from the animals (that, and opposable thumbs). Whether it be painting, literature, music, performance, photography, anything. Creating something for the sake of creation. It's a natural human desire.

You might be thinking "what the hell is this?" right about now. Well I'll tell you. I am no "spring chicken" as they say. I'm not getting any younger. I'm on the wrong side of Forty. You get the idea. The thing is, I need to keep my brain active. A healthly mind supports a healthy body, or something.

I sit in IRC each night, socialising with friends, sometimes playing multiplayer games. It's great that I can do that, but I feel that my mind is becoming "stale". I feel the urge to create something, to start a project into which I can pour my creative juices. Something I can get my teeth into, to keep my brain working, with the only reward for my toils being the knowledge that I am making something, creating something from nothing. So I have decided to embark on a journey, a journey through something that will hopefully broaden my mind and make me think about things.

I have decided to create a videogame.

No, it won't be a huge blockbuster with super-fancy graphics and a massive budget, it will be a small but playable game with dodgy graphics and iffy sound effects, bedroom coded as opposed to being created by a team of Fifty people in a dedicated building. It will, most likely, be not very good at all. But it will be a creation. Something I (possibly with the help of some friends) have created, brought into this world from the confines of my mind.

I have big ideas but I'm also realistic in what I am able to achieve. The last thing I coded was in 1994 which was a fair while back, so I'm pretty much going to have to re-learn everything I once knew. So now to look at the pro's and con's of what's available to me as a development platform...