Friday, 24 December 2010

Sickness No, Coding Go!

Ok, so the past 5 weeks have been manic, and coding ground to a halt.

Although I've been on holiday for the last week, I've had a massive cold which has prevented me from doing anything but play Epic Mafia and Starcraft 2 (both of which I still suck at).

Anyway, I'm feeling a bit better, so going to resume work on my game. Hopefully an update in a couple of days!

Thursday, 18 November 2010

v1.0.9 is coming...



The next build is on its way, and I'm pretty excited about it. The features I'm working on are:

Combat
Done: 
+Lions move broadly toward the player (extremely simple motion planning for now)
+Lions will "attack" player when beside him (this currently just means spamming the message box with a fake attack notice)
+Lions and Deer are no longer passable. They will block each other and the player.
To Do (as part of this build):
+Implement Status screen for player
+Implement HP and maybe some other basic stats
+Allow player to attack lions, causing time to pass
+Add a toggle for time, between continuous and rogue-like

Mountains
Done:
+Mountains now spawn
+Mountains can be dug to create awesome lairs!
To Do:
+Add better mountain graphics, e.g. outside wall visible, with inside dark (Toady One hopefully won't sue)
+Add hidden caves which only appear when dug into/near
+Think about how I'm going to stop player interacting with objects when there's no line of sight (I can pick up lions through a wall at the moment)

HUD/Menus
Done:
+Merged Nearby Objects and Current Square lists into one
+Tidied the general code which will make creating the Status menu easier
To Do:
+Decide what I'm going to do with the extra space generated from merging the lists
+Knock together a new HUD background in Paint
+Make the list ordering work better. First should be the top object on the square the player is next to and facing. Next, any monsters near enough for player to attack. Next, other objects on the current square. Lastly, other objects further away the player can interact with. This might get changed, but at the moment it's sorting them into a horrible order, and this sounds like a better way to go.

Hopefully I'll have time for all this at the weekend, stay tuned...

Tuesday, 9 November 2010

Start Screen, Map Builder, Flowers!

I really feel like the game is starting to progress now, and there's lots of new screens today.


First up: New start screen. As you can see, the menu item backgrounds are supposed to be little islands, as is the game name. I knocked this together using Game Maker's room editor. It's only a first draft, and I'm wondering if one day in the future I might find the time to have it randomly generate the start screen islands that are dotted around. I could even get some animals moving around on them or whatever.


Next, the map builder! It's got a long long way to go but I'm pretty happy with the general gist of how this works. Generate New Map builds a map using the current settings (listed below). Customise settings lets you edit those settings. Default/Random settings work as you would expect. Generate Random Map ignores the current settings and builds a map at random. Later, I intend for this feature not to show which settings have been used, so it's a mystery map, except for the preview. I'd also like options from the start menu which let you play a map with default settings or random settings, but without previewing, so exploring will be more fun.

The poor island generation algorithm is all too obvious when viewing the full map, but there's new code on the way for that. I don't want the preview to ultimately show all the creatures etc on the map, I may restrict it to only the island shapes, or perhaps some basic terrain such as trees and rocks. Lots of work to do here.


Finally, I've added flowers, and a little selection box. The flowers don't have any use yet but can be picked up. They add a bit of colour to the world, but at the moment the single sprite for them looks a bit repetitive, I might knock up a couple of other flower arrangements. The selection box, seen here to the left of the player, shows which object you are intending to interact with. I found while scrolling the list of nearby objects, it wasn't clear which you were selecting, so now it shows you on the map.

Next job: prioritising the objects on the list. I want to make dangerous monsters (i.e. lions) appear at the top, and then the rest should appear in some order based on your direction. At the moment it builds it using a double for loop, which means the top left object always appears at the top, but I'd like it to sort them more sensibly (e.g. near squares first).

Monday, 1 November 2010

Menus are in business!


Menus are just about done, at long, long last. There are a few tweaks need making, and plenty of code that can be optimised and shuffled, but I'm finally happy with both the overall structure and functionality . Let's just hope when I implement something new I don't realise any more massive oversights. Urgh.

Anyway, let's summarise what I've put in. Where to begin!

At risk of incurring the wrath of 800x600ers, the screen has been extended to 898x450. The idea was I wanted to keep the map at full size, while displaying all the sort of info you'd normally have to go onto a pause screen to view. Hopefully this will make for faster gameplay than the standard JRPG format, while keeping lots of tasty statistics and menus in the mix.

The first box shows the items the player is stood on, as before. 
The next box is for objects near to the player. Different objects have to be closer than others before they appear here. Mushrooms, for example, can only be interacted with when stood on. Trees (which can no longer be walked over) can be interacted with when adjacent. The idea is that you'll be able to talk to NPCs or fight monsters without having to be physically on their square.
The third box is the inventory, fairly self-evident.
At the bottom is a message box, which doesn't have much interesting being passed to it yet, but eventually will be used for things like "monster hits player for X damage" and so forth.

The player can now toggle between moving on the map, and using the menus. If you press on one of the objects, a sub-menu pops up with options. At the moment the options allow you to get info displayed in the message box, and you can pick up and drop items, which appear in the pop-up box as relevant. You might notice the lion in the screenshot can be picked up - that was just for fun (I gathered up all the lions on the map and then released them to watch them scatter).

There'll be other menu/HUD elements coming such as skills, spells, stats, etc. I'm still thinking on how to fit them all on the screen, as it's kind of cluttered already.

As you can see, I also added lions in, with colour coding to show them as dangerous (the deer now show as a pale green). Lions were very quick to add, and reminded me how fun and easy adding new content is. However I'm trying to resist stuffing the game full of cool new stuff for now, because the more content I add, the more work it is to change things, which is why it's being kept to a minimum at the moment. I am getting bored of the same limited maps now though, so I might work on something a bit more fun next.

Saturday, 30 October 2010

v1.0.5

I am still alive, but I'm having trouble getting the new build out. I keep having issues with the menus, and every time I think I have the solution and get the functionality back to where it was, I realise new problems have cropped up, which mean a new design and overhaul of huge chunks of code AGAIN. This is a causing me some frustration, as menus aren't the most exciting game element to put in, but I'm going to keep hammering away at it until I'm happy. In the meantime, here's a screenshot of the new game layout so far, which now runs in a 900x450 window:

Monday, 4 October 2010

Menus

Terrastrom v1.0.4 is well on its way, and with it comes prototype menus. This is proving particularly difficult to implement in a generic way, but it's coming along. I have created a Menu class, which hopefully will eventually deal with everything navigation.

I started working on this when I realised I will need pop-up menus for basically every interaction the game will ever do, so it made sense to get this done before continuing with the inventory. Hopefully soon we will begin to see several options when selecting a map object (e.g. talk, attack, pick up, info, etc), and similar when choosing a bag object (drop, eat...).

Because it works with delegates, a menu item can do essentially anything I can think of. This includes creating submenus, which I've just got working. When a new submenu is created, the focus swaps to it without removing the old menu, and the constructor automatically passes a reference to the parent menu, so it can deal with "Back" without having to store any info of how we got to where we are at in the menu.

It's not much to look at, but this was one of the cleverest pieces of code I've written so far so I'm pretty proud. It will feature fairly ubiquitously in the control scheme going forward. It's customisable so the menu panel images, spacing, text position and so on can all be unique to each menu, and it even has support for an optional sprite to go with the text (not shown here).

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.