After a lengthy hiatus (not in a small way caused by my not having a desk), I've begun delving into Urban Crawl again. I've now refamiliarized myself with the code, and in the process I discovered a number of little inconsistencies and deficiencies that I am sure I would not have noticed for a long time had I not neglected this thing for 2 months. I've come across this sort of thing before, and in an attempt to be a massively cool dude I've decided to dub this phenomenon the Lazarus Effect. Because, you know. The project was dead, and now it is not, and it is almost better now for having died. Lazarus. Yup.
I finished up the whole shoreline generation and lake filling algorithm. I know now that my fortmer attempts at space filling were ridiculous and silly and filled with bugs, but I fixed them up and now you can really watch the tildes fly as your very own lake is created LIKE MAGIC. I've begun the generation of rivers, which in all likelihood will consist of boring straight lines of water instead of being all bendy and interesting. After that, my initial terrain generation will be complete and it will be on to roads.
I'm considering taking a short break from city generation to actually complete the interface and display library that I wrote. It's full-featured enough for my current uses, but I get the feeling that once I get deeper into the interesting bits of city generation I'm not going to want to take a break to go write some boring menu code. We'll see. Maybe if I complete the library I can release and become internet famous. Wouldn't that be a treat?
Wednesday, August 25, 2010
Sunday, June 6, 2010
Progress, Episode 1: Maximum Recusion Depth and the Problem of Filling a Lake with Tildes
So I've finally begun writing the city generator. First up is terrain, which for the time being will consist of water features. This will include rivers, and a large body of water like a lake or ocean. Typically large urban centres are built around water features, so I think it's a good place to start. I got a random ocean shoreline generator working first, with a parameter controlling where the water will be located. It makes pretty neat shorelines half the time, I was sort of surprised that it worked so well.
Next up was the simple task of filling the lake with water. The little function I have is recursive, spreading water tile by tile from the appropriate edges. Recursive functions are so fun to write and think about, I've loved the concept ever since it finally clicked for me. Unfortunately though, this led to a little problem I was entirely unaware of: Python has a "recursion limit". Apparently you can't go 1000 deep in a recusion loop without fiddling with scary settings. Gah. So for larger lakes, I was getting crashes galore. Oh noes. Luckily enough a quick little reshuffling and a few extra lines of code fixed that up good. I don't like thinking about optomization as I'm doing things, but I have to admit my first lake filling function was a lapse in good judgement on a couple of counts.
The shoreline generator actually draws out what it is doing as it is doing it, so I finally have something cool to look at. As a result, here's a really unimpressive looking screenshot.
You can enlarge that image bby clicking on it. Things are pretty messy right now, but you can see the generated shoreline there. The water doesn't always hug an edge like that, sometimes almost half the total map will be covered in water. Maybe I'll make it so you can get a boat and be a pirate! Of course, should you not like what the generator gives you, you can tell it to try again. In time you'll be able to explicitly tell it how much water to strive for, shoreline straightness/complxeity, etc.
After polishing up a couple issues and fiddling with some display things, the river generator will be up next. Rivers will probably be pretty straight and unnatural for now, it all depends on how tricksy things will be. I am very much flying by the seat of my pants with this stuff, haha.
Next up was the simple task of filling the lake with water. The little function I have is recursive, spreading water tile by tile from the appropriate edges. Recursive functions are so fun to write and think about, I've loved the concept ever since it finally clicked for me. Unfortunately though, this led to a little problem I was entirely unaware of: Python has a "recursion limit". Apparently you can't go 1000 deep in a recusion loop without fiddling with scary settings. Gah. So for larger lakes, I was getting crashes galore. Oh noes. Luckily enough a quick little reshuffling and a few extra lines of code fixed that up good. I don't like thinking about optomization as I'm doing things, but I have to admit my first lake filling function was a lapse in good judgement on a couple of counts.
The shoreline generator actually draws out what it is doing as it is doing it, so I finally have something cool to look at. As a result, here's a really unimpressive looking screenshot.
You can enlarge that image bby clicking on it. Things are pretty messy right now, but you can see the generated shoreline there. The water doesn't always hug an edge like that, sometimes almost half the total map will be covered in water. Maybe I'll make it so you can get a boat and be a pirate! Of course, should you not like what the generator gives you, you can tell it to try again. In time you'll be able to explicitly tell it how much water to strive for, shoreline straightness/complxeity, etc.
After polishing up a couple issues and fiddling with some display things, the river generator will be up next. Rivers will probably be pretty straight and unnatural for now, it all depends on how tricksy things will be. I am very much flying by the seat of my pants with this stuff, haha.
Saturday, June 5, 2010
Progress, Episode 0
Here's where the technicals come in, and I'll talk about what's done so far. Later progress reports will be sort of a "here is what I did today, here is a screenshot, whatever" sort of thing. So far, we have:
I tested it by giving it a large 1200x840 window, containing a grid of 100x70 tiles. A big giant loop was run where a random tile's glyph, background colour, and foreground colour were changed to random values, and then I rendered. Repeat 10000 times. Running this way, the thing managed a speed of about 267 tilechanges rendered per second. Okay, so that's not actually that impressive. But if I changed it to rendering after 10 random changes, the speed went up to 2721 per second. 20 changes per render was 3827 per second. 50 changes per render yielded a speed of 7241 per second. So, it seems as if there is some overhead in the render function that isn't actually related to the number of tiles being updated at once. Nevertheless, under this test I was able to achieve render rates of more than 20000 changes per second, easily enough for a turn-based roguelike. With some improvements, you could run really low resolution video through this bad boy I'm willing to bet. That'll be for later though.
The interface system came next. I've designed it to be based around a sort of container system. Interfaces are made up of windows. Each window holds numerous elements. The elements are placed with respect to its window. Under this system, windows can be updated individually when needed, and placing objects is made a bit easier. I've also got a snazzy function for drawing interlocking borders around all the windows. Colours for windows can be controlled, and the colours will filter down and apply to all the elements (text, images, menus, etc.) inside the window. In time, the system will be expanded to allow for the resizing of and moving of windows, keeping everything nice and ordered. It sort of works like DIVs on a website. Things can be relative or absolute, yadda yadda yadda. I haven't fleshed it out entirely yet, but it serves my needs for now.
I'm trying to keep things open and extensible. I'll be the first to admit that I don't know a whole lot about how real programmers do things, but I imagine that I'm on the right track. I don't want to rewrite this thing. Not the whole thing anyways. Adding, enhancing, sure. I'm trying to plan ahead. Hopefully things stay manageable.
Now that I've got a bunch of the boring stuff done, it's on to the city generator. Terrain -> streets -> zoning -> buildings -> groups -> people -> history. That's the order I have planned, although it might change (still npot quite sure when to put history generation). Super-rudimentary versions of steps 1 through 3 will be first on the chopping block, along with a tool for viewing the result. Wish me luck.
- Display: Current display uses 24 bit colours for foreground/background, can handle both spritesheet and regular fonts for the tiles.
- Interface: Nice interface system set up including classes for windows, multiline text, menus, arbitrary grids (with image-to-grid conversion), etc. plus functions for handling placement and efficient updating of interface elements.
- City: Storing and retreiving generated cities implemented, but this will be reworked pretty soon.
- City Generation: Interface for city generation is partially up and running.
- Other: Main menu is functional, not pretty. Keyboard input works.
I tested it by giving it a large 1200x840 window, containing a grid of 100x70 tiles. A big giant loop was run where a random tile's glyph, background colour, and foreground colour were changed to random values, and then I rendered. Repeat 10000 times. Running this way, the thing managed a speed of about 267 tilechanges rendered per second. Okay, so that's not actually that impressive. But if I changed it to rendering after 10 random changes, the speed went up to 2721 per second. 20 changes per render was 3827 per second. 50 changes per render yielded a speed of 7241 per second. So, it seems as if there is some overhead in the render function that isn't actually related to the number of tiles being updated at once. Nevertheless, under this test I was able to achieve render rates of more than 20000 changes per second, easily enough for a turn-based roguelike. With some improvements, you could run really low resolution video through this bad boy I'm willing to bet. That'll be for later though.
The interface system came next. I've designed it to be based around a sort of container system. Interfaces are made up of windows. Each window holds numerous elements. The elements are placed with respect to its window. Under this system, windows can be updated individually when needed, and placing objects is made a bit easier. I've also got a snazzy function for drawing interlocking borders around all the windows. Colours for windows can be controlled, and the colours will filter down and apply to all the elements (text, images, menus, etc.) inside the window. In time, the system will be expanded to allow for the resizing of and moving of windows, keeping everything nice and ordered. It sort of works like DIVs on a website. Things can be relative or absolute, yadda yadda yadda. I haven't fleshed it out entirely yet, but it serves my needs for now.
I'm trying to keep things open and extensible. I'll be the first to admit that I don't know a whole lot about how real programmers do things, but I imagine that I'm on the right track. I don't want to rewrite this thing. Not the whole thing anyways. Adding, enhancing, sure. I'm trying to plan ahead. Hopefully things stay manageable.
Now that I've got a bunch of the boring stuff done, it's on to the city generator. Terrain -> streets -> zoning -> buildings -> groups -> people -> history. That's the order I have planned, although it might change (still npot quite sure when to put history generation). Super-rudimentary versions of steps 1 through 3 will be first on the chopping block, along with a tool for viewing the result. Wish me luck.
Urban Crawl: Big Roguelike in the City
Welcome to the Urban Crawl Developer's Log. On this site I will be documenting my adventures in creating my vision for a modern, unique (to my knowledge) roguelike. On my side I have a mild-strong determination, a medium amount of programming ability, and a somewhat fleshed out set of monstrous ideas, and it is with these tools that I plan on forging this game.
What is Urban Crawl, you ask? Put simply, Urban Crawl is a roguelike based in a giant procedurally generated city. Your ultimate goal: to rise and become mayor of your city. This game will be based in a somewhat cyberpunkesque future, all corporations and squalor and insane urbanization and degrading society and mild nuclear fallout here and there and everything. A slightly dystopian, crumbling near-future. Planned features include:
Subsequent posts will detail my progress on the game so far. I've been coding lightly on and off for the past month or so, and I plan on ramping up progress as the summer continues. I'm really excited about this project, and I think that while I may not end up implementing all of my grandiose ideas, just creating something will be its own reward.
What is Urban Crawl, you ask? Put simply, Urban Crawl is a roguelike based in a giant procedurally generated city. Your ultimate goal: to rise and become mayor of your city. This game will be based in a somewhat cyberpunkesque future, all corporations and squalor and insane urbanization and degrading society and mild nuclear fallout here and there and everything. A slightly dystopian, crumbling near-future. Planned features include:
- Persistent City. Even after death, the city will remain for subsequent adventurers to explore and conquer. People you once knew will remain, and your enemies will still be around for you to exact your revenge on them.
- Dozens of square kilometers. Millions of people. Cities will be modeled on actual urban scales.
- Realistic environment, realistic needs. Heat, cold, hunger, fatigue, sickness, all will be a factor for both you and the citizens of the city. Take care of yourself, even the robust adventure type needs a place to come home to.
- People have minds, people have memories. Watch as the people around you react to what you do, or go about their own business. Gunshots will attract rubberneckers, or scare away the yellow-bellied. Footsteps will be investigated by guards and protective homeowners. Enter some dude's house? You will be yelled at. Come back later to ask for a favour? That guy might remember you and throw a lamp!
- Gangs, corporations, neighbourhoods, DJ collectives, there will be all sorts of groups and figures that people will swear allegiance to. Join up, rise the ranks. Or create your own. Or just start killing people off and watch the group lose followers and disappear. Gangs will wage wars for control of parts of the city, and corporations will buy and sell eachother on a simulated stock market, while undermining eachother's operations (perhaps with your help!)
- Information is king. Through news outlets, rumour, speculation, and word of mouth the city's happenings will become known to the general populace. Through your influence and your deeds (along with, perhaps, some carefully worded lies and fibs), mold the minds of the many to further your goals.
- Build. Create. With resources, money, and the name of a good contractor, design and build a house. Or 6. Or twenty. Construct your dream home, a planned community, a new downtown if you like. Buy land and become an influential land-developer. You know what they say about property...
Subsequent posts will detail my progress on the game so far. I've been coding lightly on and off for the past month or so, and I plan on ramping up progress as the summer continues. I'm really excited about this project, and I think that while I may not end up implementing all of my grandiose ideas, just creating something will be its own reward.
Subscribe to:
Posts (Atom)
