Monday 27 September 2010

Terrastrom v1.0.3_2

Sorry Notch, I've brazenly stolen your version numbering system. (Release.Major.Minor_Revision)

This is more of an improvement to the last release, so no screenshot or new minor version number today.

I've now altered the code so that the player himself doesn't appear on the object list. This took a bit of faffing, and I ended up writing functions which retrieve the player's index from the list he's in, and another which returns the index of an object pretending the player isn't there. 

The player is usually at the end of the list, as the most recent to enter the square, but when a deer moves on top of you the deer becomes the last item, so no quick fudge was possible.

I also had to make sure that when the square contains only the player nothing funky happens, which I dealt with using a List.Count if statement, so the black arrow now doesn't appear at all when there are no objects to point at.


The code probably needs tidying, but weekends are the time to cleanse.

Saturday 25 September 2010

Silverlight still on hold... Terrastrom v1.0.3

I had another go at Silverlight this weekend. I managed to make some headway with it, following a tutorial which taught me to draw some bmps to the screen. I'm basically in a situation where I have the tools to translate now.

However... I'm having major trouble working out how to distribute my Silverlight application. I've had some advice on the forums, but no luck so far. I just can't get the app to display on this blog. I will continue in XNA for now, and keep chipping away at Silverlight when I have time.

This weekend I started creating the basics of an inventory system. Each object is now assigned a boolean variable "CanBePickedUp", and those that have it set to true can be grabbed.

Now when the game is paused, a little arrow appears next to the list of objects, which can be scrolled using up and down, and objects can be picked up using Enter. At the moment the only items that can be picked up are mushrooms. Originally everything could be picked up, including deer, which was kind of fun (though they were hard to catch), and looked rather silly in the inventory. There's no way to drop or use anything in the bag yet, but it will fill up, and not accept new items when full. Each item takes up one square. I can set the bag to any size I choose, which for the moment is 10x5.

It's all very functionality-focused at the moment, and consequently looks dreadful, but here's a screenshot of the game when paused with a bag half-full of mushrooms (if you look closely there's also a tree in there, but I've switched them off now).


I also performed a major overhall of some of the code structure, completely changing how the sprites get stored and drawn. I realised it was focussed on drawing things on the map, and of course once the mushrooms get picked up they are no longer on the map. The sprites were basically storing information that should have been with the objects such as the map the object is placed on and the (x,y) position.

The Sprite class is basically trimmed down a lot, and I now have an intermediate Object class, which MapObject inherits from. The Map class stores all the objects on it in a big array of lists, and the Player class stores a bag as an Inventory class, which is essentially an array of objects with some functions (IsFull, GetNextEmptySquare, DrawAt). Each object has an associated sprite. When an item gets picked up it simply deletes itself from the relevant list on the map, and adds itself into the player's bag array in the first available slot. When drawing the map, there's a rectangle defining which area is currently being drawn, and a for loop goes through each object with "Drawn" set as true in each list in that rectangle, and draws the corresponding sprites. The bag's draw function is very simple, and just draws a slot at each point, and if there is an object in that slot, the object on top.

Next up ought to be dropping items from the bag, which should be fairly easy based on what I've done already. However I really want to think about the controls a bit more, as it's fairly Dwarf Fortress style so far, and while I don't want to require the mouse, I want the controls to be more intuitive. Not that DF isn't awesome, with or without impossible control scheme.

Thursday 23 September 2010

Terrastrom v1.0.2


I've successfully added my first non-drawn object: Mushrooms. 10,000 of them! They come in shades of blue, green, yellow, white, black and red. I decided to get them to display a mini picture of themselves on the right hand side when stood on. When I implement the inventory it would be nice for everything to have an image, and this way I can have lots of stuff on each square without the map looking cluttered. They are all instances of the same class (Mushroom), but there's some nifty code that allows the world generator to simply enter a colour and x,y co-ords when creating a mushroom, and the constructor does the rest. I tried switching "Drawn" to true in the mushroom class, just for a laugh. This was the result:



I think having non-drawn objects was a good idea.

I also implemented the ability to pause the game. It doesn't sound like much, but it made me build code for control schemes. Now, when the game is running, the control scheme is "player movement controls". When you press Space, it swaps to "paused controls", and the game doesn't run the logic loop until Space is pressed again.

I realised I need to sit down and decide how the game is actually going to play. I want two things. One, to be able to have time flow and watch the game progress around you, as it does now (although I don't know that deer randomly running around in circles is the "progression" I have in mind ultimately). Second, I want rogue-like control over how battles will be fought, and characters are interacted with (i.e. turn based). I am contemplating a game-style which allows both, perhaps a toggle. Maybe like in Dwarf Fortress, when you're attacked it will automatically enter the turn-based mode. When in "rogue-like" mode, the game will pause when the player can move or perform an action. When the player does something, the game will resume, and a timer will run. While the timer is running, the game will play as normal, with animals moving and enemies attacking. When the timer expires, it's the player's turn to move again and the rest of the game pauses. It will appear to work like a rogue-like in that this timer will be very quick, so the game will appear to be running in steps. But it will allow the game to work just like it does when in "continuous" mode, where the game runs even when the player can move. I think I need a few more walks to work to make up my mind about whether this is a good idea or not.

Also - I removed the link for download temporarily. I need to come up with a better way of distributing the game; zipping and uploading the game every day is faffy.  I got my flat mate to download the .zip and it wouldn't run on his machine. I guess the XNA framework isn't built into Windows, making this a horribly unattractive way to provide my game.

Maybe I should bite the bullet and give Silverlight another go, as most of my code will move across once I've figured out graphics.

Monday 20 September 2010

Terrastrom v1.0.1!



I am ready to begin sharing my project with the world. Bear in mind that I'm pretty new at programming (with real languages anyway), so much of my progress is personal learning and code improvement.

However, I'm happy to let people see where I'm up to, and you can download the first distributed version of the game [removed]. You might need to install the XNA framework in order for it to run, please see this thread for help. It's coded in XNA 4. I will work on packing the .rar with everything needed later on, and eventually provide an installer package. But for now let's keep things simple, and the focus on the game itself.

It's not doing a great deal yet, but I'll explain what it does and some of my plans.

Graphics

First of all, I need to point out the graphics are not mine. They are nabbed from an entry to the Assemblee Project, here. My graphical skills are appalling, so for now I'm using these stock graphics until I either find an artist or figure out how to draw pixel art.

The World Map

The world map is one of the most important aspects of the game and something I intend to spend a great deal of time perfecting. At the moment it's 100x100, and generates islands by simply gluing a load of circles together. The edges of those circles form sand, and the centres are grass. The rest is sea. I have in fact got a much more exotic algorithm built with rivers and mountains, but I decided to wait until I have more gameplay elements in place before I upgrade. I want the level generation to be modelled around the gameplay, not the other way around.

Trees

500 trees are dotted around at random on the islands. They don't have any functionality yet.

Player

The player spawns at a random location on an island (sometimes he can get trapped on a small one). He can move around, only on land. Arrow keys to move.

Screen

The screen took the most time so far, but I think it's pretty solid now. It starts centred on the player. I've implemented a border so that the screen will scroll when the player moves into that border, but stay fixed while moving in the centre. It's all done with global constants so I can tweak everything later. I have also implemented the ability to zoom. PGUP and PGDN zoom in and out. It looks dreadful at max zoom. I think I'll take out the ability to manually zoom eventually. Zooming may be used instead for previewing the map ahead of playing the game.

Deer

Today I added my first active object: deer. 50 get spawned, which move around at random. They continue to move whenever they are in an area near the player. At the moment the area is about twice the size of the area on-screen. That means when you zoom in less deer will move around.

Next up

The above gives a little taster of what I've got in-game so far. I would like to post more about the code and how things work, but will discuss that as I change and improve the current objects.

The next thing I want to add are objects which are not drawn. At the moment every object has a sprite, and when on the screen, gets drawn in its square. However I want to pack lots of detailed information into the game (think Dwarf Fortress). Perhaps small things like flowers, herbs, critters may be shown in text when you're stood on the square and be interactable, but have no visuals (at least until picked up). This would allow lots of potential actions when on a single square, and more content. The game already displays a list of items on the current square, but I want additional things to appear in that list which are not displayed on the map.

And yes, I'm aware of the giant blue border. That's where the interface is going.

Sunday 19 September 2010

Farewell Flixel, hello XNA!

The New Plan

So, Flixel didn't work out. The main problem is that Adam Atomic is frequently making changes, and a lot of the functions keep getting rewritten. This means the tutorials break every time there's an update, and most are still written for Flixel 1, which makes learning very tedious. I may return to Flixel once it has settled down, but for the moment it's not for me.

I considered my options, and while I would ideally rather use a browser-embeddable medium such as Java, Flash or Silverlight, I find all the HTML stuff confusing, so for now I'm going for a traditional .exe compiler (sorry non-Windows folks). I've been working through a book on C# in Visual Studio, and have installed the XNA plugin for graphics, sound and input.

If I ever manage to make a game worth widely sharing, I'll consider learning a more distributable language and translate.

The New Game

The above decisions actually happened some time ago, and I have already begun work on my first game. It's going well (although not exactly a game yet per se), and so I decided to start sharing my plans and progress, with updates and versions.

The game will be called Terrastrom. The name comes from terra meaning earth, and strom (as in maelstrom), which means stream. It focuses on an important aspect of the game, which is the world layout and random terrain generation. Quasi-coincidentally, strom is also a common suffix for Scandinavian surnames, which is where my blog name comes from.

Terrastrom is inspired by my favourite open world games, including Dwarf Fortress, Minecraft and Morrowind, and will be an amalgamation of these game styles. It's a top-down 2D adventure game, where the world, events, characters, villages and communities will all be randomised. There will be no specific aim or objectives besides those you set yourself, but I will try and make as much to do as I can think of. The specifics are completely up in the air, and I will let the game evolve organically as I add features. I will be happy as long as the game becomes fun, intellectual challenging, and a varying experience with each play.

In the next post I will provide a link to a download of the current version of Terrastrom, with an explanation of its current (limited) functionality. I aim to provide updates going forward to show how it evolves.