Township is a Castle Defence style game with an RTS twist. Starting out life with one villager lost in the wild, you must help him build a village to defend himself from the monsters which stalk the land. As the monsters become more powerful and more common, your small township will need to both have a good income of resources and enough soldiers ready to die for it that it doesn't fall the moment it is discovered. How long can you hold out?
The current version is 0.2, and is available here (http://sotk.co.uk/township.html), along with install instructions and info about how to use it (interaction such as building is all keyboard based in 0.2).
Admin edit 2024: the code for township is now available at https://sotk.co.uk/things/township/ (https://sotk.co.uk/things/township/)
That looks fun - I'd love a look when it's useable!
(http://i124.photobucket.com/albums/p9/Son_Of_The_King/th_Screenshot.png) (http://i124.photobucket.com/albums/p9/Son_Of_The_King/Screenshot.png)
Look and see my coursework/soon to not be coursework! Moar tomorrow.
Ooooh, I can haz playtest? :D
Once it is actually playable properly as a game (not just a basic shell which is what it is at the moment) for example enemies actually spawning, then of course :) .
(http://i124.photobucket.com/albums/p9/Son_Of_The_King/th_Screenshot-1.png) (http://i124.photobucket.com/albums/p9/Son_Of_The_King/Screenshot-1.png)
As you can see the 'tutorial' is currently just an empty window. Also construction of buildings and training units is keyboard controlled, rather than with a UI window. Enemies do currently spawn, but only 10, and only at the start. Also resources are only semi-implemented (and not displayed anywhere). This is a shortened version of what I want to have changed before I sleep today (except the tutorial, that is less urgent). the bit about it actually being playable as a game wants to be addressed as soon as possible, what with the deadline for the coursework in the next week. However, given that the task was simply to create and application that exhibits dynamic graphics, it currently fits the bill (albeit with about a minute of playability, and the same outcome from every game...), so its not like I will fail if its not playable by then.
I had an amusing moment on Wednesday, when talking to someone on my course about what they were planning on making for the coursework and they replied with exactly the same description I had used to describe mine to my younger brother, minus the setting. That is a cross between an RTS and a Tower Defense game, mainly because I started working 2 and a half weeks before the deadline and didn't even want to think about trying to code a working RTS AI in that time, so settled for building up a base and defending against waves of enemies.
(http://i124.photobucket.com/albums/p9/Son_Of_The_King/th_Screenshot-3.png) (http://i124.photobucket.com/albums/p9/Son_Of_The_King/Screenshot-3.png)
Fixing a really strange bug that appeared last night, where the game wasn't adding resources correctly, so nothing could be done after the initial resources were used up. I changed gathering speed to test it and made a point of proving it was working today with plenty of villagers.
The deadline for it to be demonstrated is tomorrow in the morning sometime. Hopefully that goes well with no massive bugs deciding to appear for no apparent reason. Its not as balanced as I would like yet (creeps smash through walls too quickly) but its not too bad for about a week's work. Time for a few last proper playtests before bed to ensure there are no massive errors that I have missed...
Massive bug update:
The nice memory leak which I noticed last night still exists... And I have no clue how to fix it. It seems that when a sprite is 'killed', it is remaining in memory somewhere, since each wave makes the game get slower. A nice Google search suggests that this problem isn't exactly rare...
Other than that it seems to work well!
By the way Jubal, if all goes well (that is if I have time) I'll upload it somewhere tomorrow for you to test if you like?
Yeah, sure! :)
A long time too late, but here it is. Still needs actual ui implementing for building, and pathfinding can be laggy and buggy over longer paths. There is something of an installation guide on the webpage below, along with a download link. Also creep movement leaves a lot to be desired since I changed it, it seems they aren't choosing target tiles correctly.
http://sotk.co.uk/township.html (http://sotk.co.uk/township.html) (best viewed in Chrome)
Also,
FOR BUILDINGS:
To build, select a villager then press
f = campfire (used for recruiting villagers)
w = wall (defensive structure)
p = farm plot (used to gather food)
h = house (used to provide space for 5 soldiers)
a = armoury (right click with a villager selected to arm/disarm)
To gather resources, left click a villager(s) and right click a farm plot, tree or stone outcrop to gather.
Armed villagers are stronger than unarmed villagers. Unarmed villagers will be slaughtered by creeps.
I'll update the .zip when I have fixed some of the pretty big problems, for example the creep movement.
Each house you build allows you to have 5 extra soldiers/armed villagers.
You begin with a limit of 5 armed villagers.
Ignore score. It has a mind of its own right now.
Oh and shift+left click to select multiple units.
Good luck getting it to work. The creep movement is really dodgy, as the pathfinding of your units can be sometimes. Villagers currently start scattered around the map. If they are under the ui, you can select them through it, or drag the ui out of the way like you would drag a program window.
If anyone fancies drawing a better house I would not complain ;) .
Imma thinking this should be moved into games since it is one.
Just updating my Python installation and getting pygame, then I'll take a look.
Ok, I can't work out how to train new villagers...
The building and resource gathering all works great, so that's good. Are you going to keep the enemies as red creeps, or are you going to make them something more obvious?
Apart from that, once the pathfinding's a bit better it'll be awesome.
OK, worked out how to train villagers; now I'm doing well enough to outnumber the creeps two to one, :P
How do I start the game ?
It's dgp.py. :)
Thanks for the feedback :) . I will probably change the creeps into something more obvious at some point (my eventual aim is to make a fully RTS game). There are also some green creeps that spawn which are a bad design choice due to them being almost invisible.
As for the pathfinding, that was me experimenting yesterday trying to reduce its lagginess that made it become buggy. I don't even know why... It was working fine before that, just took a time to calculate.
Today's jobs are to try and fix pathfinding somewhat, and if I get it working a little less laggy and buggy then I will try and change it from Dijkstra's algorithm to A* (A* is a better/faster algorithm).
Sorry about forgetting to mention how to train villagers. For future reference, press t with a fire selected.
You were using djikstra's? Owch... that would be why it's taking so long, since you must be working out how to get to every single point on the map...
Indeed I was, since it is pretty simple and I had never done anything like that before. It was slightly streamlined in that it only took the centre of each 50x50 tile and stopped if it inspected the target tile, which is why trying to move from one corner to the other causes a pause before movement starts, since that is when pretty much every tile is examined.
Quote from: "Jubal"OK, worked out how to train villagers; now I'm doing well enough to outnumber the creeps two to one, :P
What Jubal said. Also make sure that you have the latest python build, and that you have pygame installed.
I added a save function and will soon have a load function. I also seem to have improved the pathfinding somewhat (in that it tends to take a fairly sensible path now) and know the main thing causing collisions the unit to have collisions with the environment along its path. The problem is that I hadn't taken into account that the last tile does not connect to the tile with id immediately next to it, which was a massive oversight (I even thought of it before I wrote the algorithm, but then forgot). Creeps also actually move now. Sometimes.
I'll update the .zip file once I've written the load function, most likely early tomorrow.
Saving/'Loading:To save a map, press Ctrl + S .
To load your saved map, press Ctrl + L after clicking start new game.
It will become more user friendly and sensible once I get round to user interface improvement, which will likely be after I have the creeps actually moving, and before I work on expendable resources, a bigger map and also look at making the map be procedurally generated rather than a random scattering of stuff, allowing water and forests and 'cliffs' and cool stuff like that.
Looking forward to actually having some creeps attack me. :P
Excerpt from tile save file
1|grass|a|(25, 25)
2|stone|a|(75, 25)
3|grass|a|(125, 25)
4|grass|a|(175, 25)
5|grass|b|(225, 25)
6|grass|a|(275, 25)
7|grass|a|(325, 25)
8|grass|a|(375, 25)
9|grass|a|(425, 25)
10|grass|b|(475, 25)
11|grass|b|(525, 25)
12|grass|a|(575, 25)
13|wood|a|(625, 25)
14|grass|a|(675, 25)
15|grass|a|(725, 25)
16|grass|b|(775, 25)
17|grass|a|(825, 25)
18|wood|b|(875, 25)
19|wood|a|(925, 25)
20|grass|a|(975, 25)
21|grass|b|(1025, 25)
22|wood|a|(1075, 25)
23|grass|a|(1125, 25)
24|grass|a|(1175, 25)
25|grass|a|(1225, 25)
26|grass|a|(1275, 25)
The tiles are stored in this format for now, so if you ever want to change the type of a certain tile (you big cheater) then just edit the wood/grass/stone entry in the save file (/township-pre-alpha/saves/1/tiles.twn). Never change the tuple of numbers though, or you will run the risk of messing your map up.
The code for saving this is really simple...
# Save tiles
tileFile = open('./saves/' + str(mapnumber) + '/tiles.twn', 'w')
for tile in tiles:
tosave = str(tile.id) + '|' + str(tile.type) + '|' + str(tile.variation) + '|' + str(tile.center) + '\n'
tileFile.write(tosave)
Other things like buildings, creeps and villagers are stored in a similar format.
Sorry for not yet updating the .zip, its exam time atm so I was revising instead of having free time.
Also, the creeps only work slightly better, in that they tend to move rather than jitter now, but they still aren't reliable. I'm going to totally recode them sometime. Probably after saving/loading is working and I update the zip.
Aaaand double post. I've updated the .zip file at long last. Creeps are still not working as intended (they stop 50px into the screen from each edge, and can only move about in the same region. I'll try to sort it out later.
Scratch that, I've just realised what the problem is. Since I changed the way map tiles work to allow pathfinding to be easier for me to code, the list of tiles the creeps are using to check for collisions with trees etc. includes every tile on the map. You now actually have time to build a decent base before the first creeps arrive (since iirc they tear buildings down quite quickly). Soldiers are the best way to defend yourself for now by the way, walls were useless last I remember since creeps could jump over them due to my inaccurate coding.
Saving/loading doesn't work yet (well it does but loading doesn't do anything, and saving is not complete).
Pathfinding should be better now. It might still be slow though. If you run Windows and its incredibly slow, then I blame your operating system. When I tried the old version on Windows the other day the pathfinding was slower than I ever remember it being on my Linux virtual machine (which has 1/4 of the memory and shares the same processor (obviously)). It should be faster than before though, since I streamlined the algorithm somewhat.
Enjoy your angry creeps guys.
http://www.sotk.co.uk/township.html (http://www.sotk.co.uk/township.html)
When you talk about the latest python, are you referring to Python 2 or 3?
Python 3 and pygame 1.9.1 for python 3.
I'll try and take another look at this soon: this will be a fairly busy week though as I have to get ahead of myself before going away next weekend.
Thanks :) . If anyone has looked at my code yet, then you'll have seen it's all kinds of untidy... I am mainly tidying it up at the moment. Putting off writing the load routine...
YAY DOUBLEPOST
Sorry for lack of anything recently, I'm in the first mass coursework giving of this semester. Someone here seems to like the idea of every module handing coursework at the same time, leading to masses of work half the time, and far less the rest of the time...
There's upsides and downsides to that.
Hope to see a new version someday anyhow. :)
That is indeed true.
And there will be another version sometime. I will probably update once I have implemented saving/loading and when there is actually a user interface for building.
Edit: Since I got bored of coding a basic system to handle user accounts with a dvd shop for my latest coursework, I decided to take a look at township. I still couldn't bring myself to make the load function, and instead looked at ways to improve the map generator. I began to create a python version of the old map generator I mentioned in thee first post of this topic. At the moment all it does is generate an expanse of grass dotted with dirt patches, but I will eventually expand it so that forests and water can be generated.
Once it makes a nice map, I will use this to generate the maps in Township, meaning maps bigger than the screen, maps which aren't just trees and stone randomly placed, and more gameplay features (water will be an obstacle for both creeps and your villagers for example, maybe boats).
Now tomorrow (as well as solving many ODEs) I will finally make the load function, then I can forget about that for a time.
Version pre-alpha-0.3 (probably released before the end of the week) will include:
- Ability to save your game.
- Ability to load a previously saved game.
- A less buggy in-game message system. Currently some messages only flash briefly onto the screen, in 0.3 it will work properly.
- Easy-to-use interface for building and recruiting (hotkeys will remain the same as they previously were).
- A slightly less bizarre scoring system.
- Perhaps expendable resources, although I am unsure about this until bigger maps are included.
- Perhaps faster pathfinding, although that may have to wait for a later release.
- Installer and executable for Windows users, so that python and pygame don't need to be installed for the game to run (if I can get py2exe to work properly, which apparently could be a problem...).
And then further in the future there will be:
- Multiple save games, and a nice interface for loading them.
- Larger maps that are procedurally generated, rather than being totally random.
- Buildings that allow the training of your soldiers to increase their stats.
- Experience implemented for all unit types (i.e. soldiers and villagers), rather than just gatherers.
Along with other stuff that I won't list here.
Also, if anyone has any suggestions on how to improve the game or any new features I could potentially add, don't hesitate to tell me.
Interesting stuff :D. I read in one of your earlier posts that they jump over walls, but I think that it may be solved by having the creep/monster thing check the up-down-left-right tiles for a "Wall"? I haven't played the game yet, so I don't have an idea beyond the posts, and don't know how easy/hard the check would be for Python.
Also, to make pathfinding easier, have them only move in the 4 cardinal directions (If they don't already), Up, Down, Left and Right, because this is supposed to be easier then having them move in 8 different directions (Diagonal).
Again, I haven't played this yet, so if these are implemented, then just ignore this post :P.
Working on a .exe for the current version (pre-0.2). That is if I can get rid of some stupid .dll error I keep getting. Hate Windows at times like this :D .
I had to motivate him to get the py2exe, read the tutorial, finish it, etc. But it'll all be worth it :D. We're on MSN right now, actually. Uber-Awesome!
There is a 64-bit version that works now! 32-bit was giving me a different stupid .dll error... I'll try some more tomorrow.
Done at last!
Note to self, never ever ever use py2exe again.
Installers:
x64 for 64 bit (http://sotk.co.uk/township-pre-alpha-0.2-x64.msi), x86 for 32 bit (http://sotk.co.uk/township-pre-alpha-0.2-x86.msi). There is no difference except 64 bit won't work on 32 bit Windows. I just happened to have 64 bit Python installed when I first made the installer :3 .
EDIT: These are still for the version with laggy pathfinding for more than about 3 villagers at once, no saving, as well as dodgy creeps and any other bugs I may have fixed in the (broken) version I have.
I think I love you <3 not really though. I appreciate you. But not really. I appreciate your games :D. Not sure if that's an insult though... Not meant to be :D
"He says he loves me, but really he only wants me for my Python skills" :P
How does it run for you Ryan?
Also,
Quote from: Son of the King on March 02, 2011, 03:08:44 AM
Version pre-alpha-0.3 (probably released before the end of the week) will include:
- Ability to save your game.
- Ability to load a previously saved game.
- A less buggy in-game message system. Currently some messages only flash briefly onto the screen, in 0.3 it will work properly.
- Easy-to-use interface for building and recruiting (hotkeys will remain the same as they previously were).
- A slightly less bizarre scoring system.
- Perhaps expendable resources, although I am unsure about this until bigger maps are included.
- Perhaps faster pathfinding, although that may have to wait for a later release.
- Installer and executable for Windows users, so that python and pygame don't need to be installed for the game to run (if I can get py2exe to work properly, which apparently could be a problem...).
And then further in the future there will be:- Multiple save games, and a nice interface for loading them.
- Larger maps that are procedurally generated, rather than being totally random.
- Buildings that allow the training of your soldiers to increase their stats.
- Experience implemented for all unit types (i.e. soldiers and villagers), rather than just gatherers.
Along with other stuff that I won't list here.
Also, if anyone has any suggestions on how to improve the game or any new features I could potentially add, don't hesitate to tell me.
Lies. Many lies.
What I have currently from this list:
- Fully working messages
- Ability to save the game!
- Marginally less random scoring system
I also had halfway implemented most of the other stuff, for example loading was/is almost done and I was working on the pathfinding. My problem is that I fixed the message system in a computer lab at uni, and never transferred the changes to my laptop :D . Also that I managed to utterly break the units' movement by making pathfinding faster SOMEHOW. It worked soon after the quoted post, and now doesn't...
Anyway, I'm currently working on making my code neater and taking a more object oriented approach (rather than the messy blob approach I previously used even if that means recoding lots). First up, fixing up how the map works to give me the ability to easily add BIG maps, and also changing how resource tiles work to allow for finite resources.
Making my code neater == Rewriting most of the program. Main menu code doesn't make me cry anymore. Also, I intend to use a fully object oriented approach this time, rather than the mess I made at first. For example, now there is a class MainMenu() which handles the whole of the main menu via methods, rather than the horrible method I was using before of trying to attach a main menu to the game I had made. Also you can use a text file to change button texts :D .
It is also now easy for me to add new buildings, creeps, etc. since they are also stored in text files whereas before they were hardcoded (creeps will still be pretty much hardcoded since I have plans for more complex behaviours than just wandering).
Speaking of buildings, here is some outline for how I plan to implement them:
Spoiler
## Name:<Building name>
## Type:<Building type>
## <Type specific fields>
## CostFood:<Food cost of building>
## CostWood:<Wood cost of building>
## CostStone:<Stone cost of building>
## <Other resource costs (for future)>
## Vars:<possible variations of the building image, eg abcde>
## BaseImage:<Path of the sprite, without variation suffix>
## ImageType:<Image format of the sprite, eg .png, .jpg>
## Icon:<Path of building icon>
## Descr:<Short description of the building's use>
I'll write some stuff (copy/paste from the buildings file since I've written lots this time so my brain knows how I want to implement things) about how types and stuff will work if anyone is marginally interested. I intend for this release to take a while before I actually release it, but have a far better game for it. One of the things I want to add is a greater variety of buildings, which is another thing I always intended.
Additionally, I intend to add more types of 'creeps' such as a Builder Creep of some kind that builds lairs for its friends. This in turn could lead to less of a focus on waves and move in a more RTS-y direction with the need to destroy said lairs or fight off many many creeps. I will also try and make the old herding creep work better, as it was a fun idea that I broke when moving from creeps on a white screen to an actual game (when I couldn't think of what to do for coursework).
A lot of this writing is just me braindumping though rather than definite future features, seeing as how I am developing a tendency to walk home from uni thinking of ideas, then forget all about them until I'm next walking home from uni...
As an idea, I currently have a fully functional main menu which looks nice and elegant in code, and is about as customisable without changing code as I can make it. Next up is writing the Map class (and by necessity the Tile class I guess) which will generate a map to a set size, rather than just to the screen size as before.
Yes my cleanup has turned into a rewrite. But its worth it!
Stopped working for ages due to
a) lack of a clear idea of how to properly implement a large map
b) deciding I should probably spend time doing uni work
Its Christmas for me now and so when I'm not revising I shall be trying to work on Township now that I have figured out how to make the map. Speaking of the map generator, there are now lakes! By default the map is 100x100 tiles (2500x2500px with 25x25 tiles), but the generator should work for as big a map as you like (although I will probably have to change some stuff about how the map is displayed if it gets really big.
Huzzah for perseverance!
:D .
I thought "adding beaches will make the lakes look nice". The next day I'm still sat here smoothing out the beaches.
You gotta love the whole 'mapping' thing right? ;)
Definitely. It finally is pretty much finished at last it seems there are around 50 possible shoreline tiles that can occur... Tomorrow is the delights of making it possible to move the map. Then finally I think I'll start on the UI :D
Awesome to see this taking shape. Will there be a standalone release at any point, do you think?
Yep, as soon as I get the version I'm working on at the moment into a useable game I'll compile it and release a standalone application as well as the source code. As for an estimate of time, I have pretty much no idea. Right now the map generator is complete (for the time being) and I've started work on the ingame user interface. Still have to implement villagers, building and creeps before I think of releasing anything though.
(http://i124.photobucket.com/albums/p9/Son_Of_The_King/th_township.png) (http://i124.photobucket.com/albums/p9/Son_Of_The_King/township.png)
Villagers tomorrow :D
Awesome! ;D
Nice work, Saw. :)
Wild screenshots appeared!
(http://i124.photobucket.com/albums/p9/Son_Of_The_King/Township/th_001.jpg) (http://i124.photobucket.com/albums/p9/Son_Of_The_King/Township/001.jpg)(http://i124.photobucket.com/albums/p9/Son_Of_The_King/Township/th_002.jpg) (http://i124.photobucket.com/albums/p9/Son_Of_The_King/Township/002.jpg)(http://i124.photobucket.com/albums/p9/Son_Of_The_King/Township/th_003.jpg) (http://i124.photobucket.com/albums/p9/Son_Of_The_King/Township/003.jpg)
Jubal attempts to use playtest! :P
Jubal foresaw a playtest (its like Future Sight, you have to wait 2 turns)!
\pokemonnerd
There's not much game there right now, gather resources and build buildings is as exciting as it gets. Once buildings are done I can put it up for you to have a look if you like, but there still won't be any enemies :P .
Working on adding a game setup screen where settings like difficulty, starting res/villagers and map generator parameters like resource scarcity and amount of water can be changed. You have uni to blame for this, a lecture about GUI toolkits suddenly inspired me to pretty much make toolkitception within pygame to do this.
After this I'll add small details like enemies and fully working buildings. Then get save/loading working and then it should be ready to release! And the good news is its almost the Easter break :D .
Triplepost woo!
Here is a screenshot of the New Game UI as it is right now, so you have an idea of how I want it to be :) .
(http://i124.photobucket.com/albums/p9/Son_Of_The_King/th_004.jpg) (http://i124.photobucket.com/albums/p9/Son_Of_The_King/004.jpg)
When complete the left hand panel will have sliders to change the map size, in addition to other settings such as sliders for water levels and tree/rock numbers. The right hand panel will have everything to do with game settings in it, mainly checkboxes for things like tutorial, difficulty etc and also sliders for stuff like number of starting villagers. The textbox there currently is the map name.
Nice idea, SotK :D! I especially like the "Scatter Trees" or "Forests" idea. Would definitely bring a little bit more into it, don't you think?
Yeah, I'm planning to do the same thing with rocks as well, with a cluster of rocks simulating a large outcrop or something like that.
In other news, the textbox is now fully functional. So proud of it xD .
Township news, of the worst possible kind. My hard disk has failed and I've most likely lost everything since the version that's on my website...
Completely and utterly failed? :(
Pretty much... To make matters worse I was using a virtual machine running linux to code Township and so accessing it is doubly hard...
So, I can seemingly access my hard disk sort of ok now I'm booting from an Ubuntu liveCD I had lying around. Time to try to rescue some stuff!
It's not yet fully failed thankfully, it's in the process of doing so though.
*Plays trumpet fanfare for the rescue mission*
This would be far easier if I hadn't been doing all my programming on a virtual machine...
So, I managed to access the VM's hard drive, but couldn't access the files :(. Doesn't look good :'( .
Can you not dump the entire hard-drive onto something safer like an external HD, then try and extract the files later?
I tried, but my external hd is formatted in FAT32, which only supports file sizes up to 4GB an the VM's hard drive file is 8.8GB... Toying with the idea of getting hold of a 16GB pen drive atm.
These drive sizes are all small.
My drive is 500GB, just the formatting which is stupid. Also pretty much the only thing on the VM is Township and some Uni stuff. Also apparently just copy/pasting a VM breaks it :/ .
I've used this program before and found it handy: http://www.acronis.com/
They provide some trial runs of their various tools. Maybe they be useful?
I'm such a genius, that in trying to get Township off the HD when it broke, I have potentially ruined what turned out to be a ridiculously simple thing to do D: .
Scratch that, fixed the permissions and nothing is lost! TOWNSHIP LIVES!
Awesome!
Huzzah! ;D
Making buildings placeable! They snap to the tile grid, to make pathfinding around/to them work properly. Sadly, this means no more free rotation of buildings. Walls will be built tile by tile now, rather than with preset lengths of wall, allowing for greater customisation of layout.
Spoiler
(http://www.sotk.co.uk/township/buildings8-7-12.png)
Next is the battle of making all the buildings do what they're supposed to based on a few lines in a text file ;D . Then some basic enemies to make it a game, along with smoothing out the menus somewhat and adding in the load/save screens. Followed by a release. The map settings screen I showed will wait until further down the line to be released, since linking in all the options I want to have would result in me never getting anything released at this rate :P . My aim at the moment is to make everything as customisable as possible, hopefully eventually (read once the game is enjoyable) allowing the player to 'design' their own soldiers by equipping them with different loadouts, and being able to save these as unit types that are trainable.
Will the buildings still be 90 degree increment rotatable?
Indeed. They look weird all facing the same way.
Is this still being worked on? It looks like it'd be really fun.
I concur that it would be nice to see a shiny new Township version.
I've downloaded it, now just to test it out.
It keeps on crashing a few seconds of playing. :(
Yeah this old version will do... It's crazy buggy :P .
Yes, which is why we're badgering you about a new one. ;)
#include <string>
#include "Game.h"
#include "SotKTasks.h"
using namespace std;
int main( int argc, const char* argv[] )
{ // main function
vector<string> todo;
Game township = new Game("RTS/castle defence hybrid", *todo);
// loop through todo vector, implementing each item
for(int i = 0; i < todo.size(); i++) implement(todo[i]);
// upload township-pre-alpha-0.3.0
upload(township);
// print out success message
cout << "Township Pre-Alpha 0.3.0 uploaded successfully." << endl;
}
Sadly however, todo.size() is a very big number, so that loop may take a while to finish. Also I'm drowning in coursework.
tl;dr: I'm still working on Township, stuff is getting done again now I'm settled back into uni and am drowning in coursework less severely than the last 3 or 4 weeks.
Yaaaaay :)
I started this 2 years ago almost... I am bad at motivation.
Double that number, apply to site as a whole => my reaction. :P
Even thinking about programming in Python makes me sad now that I am fluent in c++ and have seen its great power. Looking at the code for this makes me sadder. This is partly because I started doing my final graphics coursework, and I accidentally a Township.
Township II? :P
Spoiler
(http://sphotos-h.ak.fbcdn.net/hphotos-ak-snc7/336300_10152360357590078_2034862983_o.jpg)
You could say that xD .
So is what you're building actually going to be a game, or is it really a graphical engine type thing?
Alsothatlooksfreakingawesome.
At the moment its a graphics engine, and for the sake of finishing before the deadline/Christmas for the duration of the coursework it will probably stay a graphics engine. I'll add a game in at some point though, I really can't face python after seeing what c++ can do... The current python version can't handle maps larger than 200x200 tiles, this engine can handle 500x500 with no trouble at all (without any kind of optimisations).
I should learn c++ at some stage.
And yeah, I guess in any case for the game to work it needs the engine done so there's not really a time saving in starting to add the game in too early.
You should :P . I might write a tutorial sometime.
Yeah, my main priority is adding in enough things to get marks for my coursework (currently what I have is probably worth between 25% and 50%), and then I can go crazy and make the game part all awesome :D .
Creating trees using L systems makes me want to die. Because for efficiency all the branches need to be in place in the model, rather than transformed into position at runtime. This means that very horrible maths has occurred.
Horrible maths has beautiful results.
Spoiler
(http://sphotos-d.ak.fbcdn.net/hphotos-ak-ash4/466766_10152363518820078_142078849_o.jpg)
Even more beautiful is the result of another maths-y day :D
Spoiler
(http://sphotos-d.ak.fbcdn.net/hphotos-ak-snc7/327260_10152365776055078_1348934554_o.jpg)
WOW!! O.o Epicly awesomely amazing!
Not done anything particularly visually impressive the last few days, mostly just optimising my rendering code to stop the trees from killing the framerate.
Frustum culling implemented, framerate += infinity. Also cubehouse.
Spoiler
(http://sphotos-f.ak.fbcdn.net/hphotos-ak-ash4/333477_10152369814285078_1626635045_o.jpg)
...Is that.... is that a building I see?
Sure is :D
Spoiler
(http://sphotos-h.ak.fbcdn.net/hphotos-ak-ash4/291631_10152370471530078_126756997_o.jpg)
*Gasp* Floating grass... *Double Gasp* I hope I fill be able to fish in that lake. ;D
Let there be light!
Spoiler
(http://sphotos-c.ak.fbcdn.net/hphotos-ak-snc7/471404_10152373693560078_135834269_o.jpg)
Should it be, "Let there be night!"
Township news? Township news.
I finally set up an environment on my computer to (almost) let me compile and run my coursework code! Meaning stuff might actually happen with this at some point!
Woo yay! Go for it! :)
ALMOST let you compile?? Stuff MIGHT actually happen with this at some point??
Looking forward to it. :)
Would you like a subforum for ye olde Township? Not like you wouldn't be able to give yourself one, just thought I'd ask. :)
Yeah, it uses a good deal of old legacy OpenGL calls since it was made to compile in the uni computer lab (that uses like OpenGL 1.2 or something). I have managed to sort out all that stuff now, and it compiles but doesn't work on my computer. It works fine for Teejackbo though so it could be the fact that old OpenGL methodology is better supported by Nvidia drivers than it is by AMD.
Indeed that would be good, but there is probably not much point until after the summer is over and my resits are out of the way.
Managed to poke it into working! Now to make it run nicely!
Haha! Good luck. :) It's looking good.
Woo go Township! :)
(http://cdn.meme.li/i/obh3f.jpg)
Exilian profanity filters are global. :P
Never going to finish this if I keep doing what I'm doing xD .
I decided that the best thing to do would be to change the way terrain works once again. In all previous iterations of the program I have used simple random numbers to place tiles in a grid of pre-determined size. The second python version that I never released (with water and good pathfinding etc) worked by filling the grid with water tiles and scattering some land randomly, then passing over the grid repeatedly growing the land with a random check to see if it grew on each pass.
The first 3D version filled a larger grid with land tiles, then randomly seeded a heightmap with maxima and minima to create hills and valleys. These valleys were changed to sand tiles and were effectively underwater.
However, I wanted to reduce the cost of rendering the map. The way to do this is to split it up into sections, and only bother with the stuff within a certain range of the camera. If I make it work in this manner, the reason behind not having very large maps is gone, and therefore the maps can be of potentially enormous size. However none of the approaches I had previously taken are particularly conducive to very large maps, since the entire map must be generated before it can be used (due to the random scattering of land or hills/valleys being totally random, and therefore a lot of processing needs to be done on what is created to give smooth and coherent terrain).
I am now in the process of writing a map generator that initially generates a large map, only parts of which will be rendered at any point in time, but which in the future will be able to generate more terrain on the fly. This has the potential for worlds of vast size.
Initially a grid of hexagons is created, and filled with a colour decided by a Perlin noise algorithm. This colour represents the type of the tile - land or water. This hexagonal grid is then 'rasterised' to get an even larger grid of square tiles (the actual terrain) with height based upon the distance of the tile from sea level, with random perturbation. These tiles are stored in groups of 16x16 tiles called regions. The rendering engine will test if the centre of a region is in the viewing distance, and if it is then that region will be rendered. The regions will store all things that are scattered across the world, such as trees etc. This will allow the render cost for each of these things to be reduced by only trying to render a fraction of the full amount.
All in all - better terrain and also better fps is being implemented :D .
When there are screenies, do show. :)
Haha! I'm quite curious as well.
Not very impressive at the moment, but here are some screens of the hex grid that is used as the 'continent map'. The next step is to turn this into a square grid at a much higher resolution, which will eventually become the actual terrain. Maybe preliminary screens of that tomorrow or the next day. Then once I have a basic implementation of the map working in this form, I think I will work on getting the game part of Township back to where it was in the original Python release. After that I will work on making the map generation more interesting and improving the gameplay somewhat.
Spoiler
(http://www.sotk.co.uk/twn01.png)
(http://www.sotk.co.uk/twn02.png)
(http://www.sotk.co.uk/twn03.png)
Awesome, I am muchly looking forward to this. :)
Ok, some progress has been made. Big maps now take forever and a day to generate, but I'll work on speeding that up soon. Here is an example of a hex map, which is then turned into a square tile based approximation of it at a huge scale.
Spoiler
(http://www.sotk.co.uk/township/twn04.png)
(http://www.sotk.co.uk/township/twn06.png)
And for scale:
(http://www.sotk.co.uk/township/twn05.png)
Progress update once again.
I finally finished up the reason behind me starting the map generator all over again. So now the map is properly split into "regions" of 10x10 tiles, only a certain number of which are rendered at any one time. This will drastically reduce the cost of rendering the map, which was the performance bottleneck with the old generator. I've also done a lot of planning how I want the game to work properly, for pretty much the first time ever. So I now have a clear idea of how I want things like resource collection and unit creation to work.
This also included fleshing out an idea I've had since I was working on what was intended to be the second release of the game written in Python - namely giving each villager their own individual personality. Originally that just meant they have a name that can be customised, and they level their stats a bit slower than originally meaning you need to invest more time to get the veteran villagers who are great at their jobs. However now that is tied in with my more recent ideas about resources and training units, along with the idea of having a chieftain being fleshed out. Essentially, I intend to make it possible to mould your villager's abilities by using other villagers to teach them, and for each individual villager to have personality traits that affect their effectiveness at a particular job.
For example, you may get a villager who is highly intelligent and good at teaching others, but is also easily bored and therefore not particularly well suited to menial tasks such as farming or mining. This guy would be useful to enhance fresh villagers' personality traits. Similarly, you could get a villager who is reasonably skilled in a number of fields and charismatic. This guy would be a good bet for a chieftain.
This sounds utterly awesome. Keep up the good work! :D
I hope it will be :D . I still have to work on getting the terrain decorated nicely before I move onto the feature adding part once again though.
Today I work on spreading the trees nicely (only pine-ish trees for now, in the future I intend to have multiple tree species with the type of each tree decided by the amount of moisture and temperature at that tile). Once that is done, rocks will be added on the hills and the terrain will change to match it.
Then onto work with villagers!
Working on getting a user interface implemented :) .
Woop! :)
So, the user interface never got implemented (QML and Qt4-style QGLWidgets don't play nicely). Getting a job meant my free time for this got swallowed somewhat, not to mention my motivation to program when I got home having been programming all day. However, recently my motivation for this has been coming back. I currently plan to re-do the display using more up to date Qt stuff so that the user interface work is nice and simple, then finish the other stuff I said I would somewhere and finally release something for people to play around with!
Wow. Exilian might just become a base for Indie game development!
Anything further to share about Township?
Yeah, I'm hoping to see if we can attract a couple more devs in the next few months :)
I played my original python version of this today, and fixed a couple of the awful bugs that were causing it to crash after a few seconds :D .
I also remembered how unfinished the second python version is, and the C++ version that I managed to break at some point...
I got bored of writing code for yamlui and wrote a thing to generate a map using OpenSimplex noise to create both coherent landmass and easily allow the same map to be reproduced from a seed. The result is vaguely similar to the screenshots of the unfinished second python version, but with larger landmasses and less "randomness" similar to the screenshots of the C++ version.
The neat thing here though is I implemented a system such that the map is generated and rendered in 16x16 chunks, which avoids the issue the unfinished second python version of Township had wherein if the map was larger than about 150x150 tiles the framerate became very poor. I "just" need to come up with a way to load/generate chunks on the fly and there is no reason to limit map size anymore.
It'd be nice to see another working version of Township sometime :)
I agree wholeheartedly. I was talking to Lady Grey about it a couple of weeks ago and decided I had to give it another, better, go. That's what caused me to start actually implementing yamlui after a similar but less strong bout of motivation struck last year and gave me that idea (sadly that inspiration ran out after trying to write an example ui definition).
Spoiler
(http://sotk.co.uk/township/mapgen01.png)
That's what I've got so far with this map generator, trees could use some work to render them less uniformly, and stop them being cut off by chunks below and to the right. This map is 256x256 tiles, but it can be infinite if I just figure out a neat way to generate chunks on the fly. That 181 is the fps I'm getting, which compared with about 30 fps on the old unfinished python version with a 200x200 map is quite an improvement...
I'm also still not happy with the rocks, maybe I'll switch back to tiles that are 32x32 pixels instead of 16x16.
Hm, in visual terms I feel like the rocks could look OK, but probably need a bit more graphical variation and possibly tweaking to look a bit more "smooth" on average rather than the "clutch of eggs" look they have now. What you've currently got looks a bit like the design of a whole outcrop rather than part thereof, I guess, which fits with what you were saying about 32x32 tiles.
I decided to make them less bright, and more smooth. I think they look much better now!
Spoiler
(http://sotk.co.uk/township/mapgen02.png)
Adding that graphical variation is the only improvement I've made so far sadly, but I do now have a clear picture in my head of how the infinite map will be implemented, I just have to get time to do it.
Looking forward to seeing it when you do get the time :)
Another year, another bit of working on Township.
I finally got the time and motivation to implement infinite map generation a couple of months ago whilst flying to the US. That is all I did until recently when I've decided to try and make another attempt at sustained work on this. I've been taking an approach of setting myself a small number of easily achievable things to do each day, and doing just them, in an attempt to avoid getting too burnt out or bored of it. It seems to be going OK so far, since my main problem is wishing I had more time to dedicate to it...
Good to hear from you - I hope it continues to go well.
^ Likewise. I don't think any of my old versions work any more, but I'd be interested to see a new one if it ever emerges :)
Infinite map screenshots!
Near the origin
(http://i.imgur.com/2a1jpqB.png)
Somewhat further out
(http://i.imgur.com/BaS6oxr.png)
Today's progress has mostly been the tile information panel thing, which is only there as a means to the end of me working out what tiles need and playing with yamlui's text labels really.
If you want to play with it and have Python (>=2.7) + Pygame (something recent-ish, idk) installed, you can get the code from GitHub (https://github.com/ColdrickSotK/township). You'll need to get yamlui (https://github.com/ColdrickSotK/yamlui) too and place it alongside mapgen.py though. There isn't much in the way of actual functionality yet though, its still pretty much just a map generator.
Nice, hopefully I'll get time to have a play around soon :)
I've spent the last couple of days doing some initial work on "Stockpiles", which I intend to be some kind of resource drop-site type things. Currently you can only place them and select them. Actually tracking their contents and displaying information about them should be possible tomorrow :D .
Ooh, excellent :) (Also, recent work included in Updates from the Forge!)
Another year, another bit of work on Township. I did some refactoring to make it lots easier to display information in the UI, and I also implemented the beginning of support for villagers. Currently there is only one, its a black dot, and all it can do is be selected and told to walk in a straight line, but the groundwork is in place to support them properly now. The next step is making them be able to do things like gather resources and move them to stockpiles.
Nice :) Good luck with carving out some time for the next steps...!