Friday, October 9, 2009

Update

Sorry for the lack of updates as my buddy Art so kindly pointed out. So I figured Id just post something quick.

Ive been having constant computer problems ever since that initial hard drive failure, which I think is now related to my PSU, and me drawing too much juice. And I have been working on writing a pygame engine that I may use for this. I have also been reading a few programming books as well, so all in all I have been relatively busy. But no worries, I am not abandoning this project. ;)

Stumble Upon Toolbar

Tuesday, September 15, 2009

The start of a story

Alessandra has just finished some amazing brainstorming and sent me her ideas for the world. It is some very awesome stuff with great ideas and will hopefully prove to be very exciting. After we brainstorm back and forth for a little bit, I will post a general overlay of the world (No plot teasers though!). I think you all will be pleasantly surprised.

Stumble Upon Toolbar

Sunday, September 13, 2009

Minor Update

Just a short update here. I have about half of the zoning code done, I have finished splicing together 9 separate 75x75 cell maps into one zone. The next step is rebuilding the map on the fly.

Yesterday I had an adapter that converts my IDE hard drive to SATA to be compatible with my current mother board die, as far as I can tell. It took me a good part of yesterday to fix my computer, as my master boot record for vista was on that hard drive (Vista was installed on a separate one, as I am dual booting). Fortunately all of my code is on this hard drive so I dodged a bullet there.

I also have spent a bit of time yesterday configuring py2exe to work on my system and did a very quick test build that runs my map generator, movement and fov code. If anyone is interested post a comment and I will put up a download. It has been tested on windows xp, vista 32 and vista 64. There isnt much attached to it so I will only upload via request for it.

I am also in process of reading a few Python books, just to familiarize myself a bit more with it, and get as comfortable as possible before getting entirely too deep and over my head. The next update will hopefully be going more in depth into my zoning system, with some code explaining how I did it.


Edit: I almost forgot, everyone welcome Alessandra Gonzales (Vester on DF forums) on board as the new writer!

Edit 2: Also welcome aboard one of my great personal friends Chris McAllister on board as a creative dev. He will be putting in ideas for story and helping me work out game mechanics.

Dev team so far:

Coding, Concept: Mark McKinley
Story Writer: Alessandra Gonzales
Creative Developer: Chris McAllister


Stumble Upon Toolbar

Thursday, September 10, 2009

Zones

I have been working on Lost Horizon for the past few days now and for the most part, everything is going quite smooth. After I finish working on scrolling code, Im going to dive into how I plan on dividing up the world. I will be using an overlay of zones, color coded for the engine.

The way it will work, is instead of loading up the entire world and having the engine keep track of it, only load what is in the "green" zone, or immediately surrounding the player, and a bit of the adjacent "zones". Anything outside of the adjacent, or "blue" zone, wont be drawn and will be considered the "red" zone. I havent worked out the exact sizes of the zones them selves, but a good rough idea is the "green" zone would be the size of the game console. The "blue" zone would be half of the size of the "green" zone, and would act as a loading buffer. Once the player reaches the blue zone in one direction, the engine will unload the blue zones in the opposite direction, and turn them into red zones.

The exact implementation of how I am going to do this is a little fuzzy, and is still a bit up in the air. I could have the entire zone overlay follow the player and constantly load and unload parts of the map as new ones become available.

The other way would be to stamp the entire world with the zone layout. Each with the large size zone and half sized zones attached to them across the entire world. Same as before, I would only load blue and green zones. But since every place on the world would have the buffer zones, I would have to add a color into the scheme. Green for the zone the player is in, and blue for the adjacent zones to green zones. Red zones would follow blue zones, with the buffer zones for the red zones being black. This would prevent me loading buffer zones attached to red zones, but not attached to green zones.

For wilderness areas, anything outside of town, I will have monsters get created on the fly in the blue zones, that will wander around. Any monster that wanders into a red zone will be removed, and ones that wander into the green zone will engage thier AI for when they see a player. Hopefully this will give the illusion of the world being alive, and provide "random encounters" that seem like wandering monsters.

The reasoning behind doing these zones is it doesnt matter what is happening on the other side of the world, if the player cannot see it, and if the player cant see it, why load it? This will allow for better performance of the game, and allow me to use that saved performance for things like better AI, better spell effects or anything else that the player would enjoy.


The last thing I would like to address in this post, is town zones. This zoning system will work out differently than the color coded zoning. Since I plan on having randomly generated worlds and static towns, I am going to associate each town with level zones. The town, and the surrounding area will have the levels of the monsters and loot controlled by these zones. Since I plan on having the player start out in the same town regardless of how the map is generated, I need to control the level of the monsters around these towns to prevent a newbie town from being dominated by higher level monsters that the player has no chance in defeating. These zones will also control the level and/or amount of random dungeons generated in these zones.


I will hopefully have a rough system set up within the next few days, depending on how finishing up this scrolling code goes. I will test both color zoning ideas to see which one works out the best.

Feel free to post any comments or suggestions!

Stumble Upon Toolbar

Monday, September 7, 2009

The Plan.

Before I start jumping back into this project, I will outline my ideas, concepts and develop a plan of attack to tackle this project. Instead of just going through and doing what ever pops into my head at the time, I will take a more controlled approach this time in order to prevent further headaches.

The Ideas.

I will go over a few of the big ideas I have planned for this game. This is not going to be a list of every feature I will put into this game, but a few of the major goals and a description of how I would like it implemented. As a gamer myself, I always have ideas of what could make a game better or cooler than they currently are, so writing my own game seems to be a logical step. Anyways, onto the good stuff!

The biggest idea so far, is the multiple storylines for the game. Most roguelikes have only a very minimal story, if any. Some have a decent backstory, but its usually its nothing significant, and it works for them but that doesnt mean I have to follow suit. The way I would like to implement these storylines, is to have an even amount of story lines for each race, most likely dictated either by alignment, or choosen randomly. For example: If I have three races, each race would have three independant story lines for a total of nine. Each storyline would interact with each other, and take place at the same time, telling different sides of the story from different points of view. Say you play through one storyline, and a town gets destroyed by something while you were doing something else. In another storyline you might be the person that is responsible for that destruction. I also would like to have class specfic storylines that are more like sub quests which would be optional. I know this seems like a big idea, and alot of writing, but Im not planning on having each story line be 40 hours, just a few to tell part of the big story. I will also make permadeath an option so you can experience the entire story.

I also would like to have a world that feels alive. Seasons, day/night cycles, civilians, road traffic and things like that, that would make the world feel alive. I want a large world, that is randomly generated when you first start up the game or when you want a new world (Similar to the way Dwarf Fortress does it). Towns would be static of course, but the rest of the world would not, nor would thier position on the world obviously.

Destructable, modifiable terrain. This is mostly for magic, or awesome boss battles. Using spells to crack open the earth to prevent a horde of monsters from rushing you. Freezing rivers to make bridges for you to cross or use as a trap. Bosses smashing through walls to get you, or knocking you through them. The possibilites are endless and potentially amazing.

Item generation similar to how Borderlands does theirs. I absolutely love the idea behind it, and seems extremely unpredictable with amazing results. I will have regular weapons as well, that are more basic.

There is alot of ideas here, and these are deffinately not all of them, and of course they are not all set in stone, so they could change.


The Approach.

Before I start diving head first into the code again, I need to put together a game plan. The first thing I plan on doing is to organize everything and base it around one central "core" file. All of the other files will be independent of each other, and will only interact with the main file, which will supply the other files with all of the information that they need.

Next, I will comb through the current code, and delete anything that I dont think is needed, or beneficial to keep from previous re-writes. A fresh start. Then I will set up a solid, fast way to draw to my console. Libtcod will help with this. I will build a nice base, with a scrolling view and movement. The next step would be to build a system of keeping track of time, as I will be going for real time, instead of the origional plan of keeping it turn based.

That should be sufficent enough to build a nice foundation that can be built upon. I plan on starting the coding process in the next few days, and will actively update this PUTDSCM along the way.

Stumble Upon Toolbar

Sunday, September 6, 2009

The Beginning.

A few months back I decided to start a roguelike game written in Python. I wrote non-stop for almost a full month, and loved every moment of it, but I continually re-wrote the game. After a while I took a break from it right after the start of 3rd or 4th re-write, as other projects took over.

Recently however, I have gotten more and more interested into picking this game back up (mostly due to a buddy of mine creating a portfolio of game programming, reading some articles and books on AI, and watching a few tech videos) and decided to start a blog about the development of the game in hopes of keeping with it, and attracting possible fan interest.

In the very beginning stages of brainstorming and deving from an internet friend named Dan from New Zealand, we started to create a brand new world that was not based on any other previous worlds. This was mostly a creation of Dans, with ideas here and there from me for a basis of the overall story of the world. It was going quite well for the short time we both worked on it, with plenty of ideas flowing consistently, and very ambitious to say the least.

The plan is to create multiple story lines, specfic to each "race" that would all take place in the same time frame, at seperate parts of the world with major events in one story line showing up or affecting the other story lines. Only the ideas were solidified, and no hard story line aside from basic concepts were written.

About 3 weeks into the origional dev process, Dan had taken a vactation to Australia for 2 weeks, and I sat around coding the game, less and less every day because of me getting upset over the constant re-writes and bugs that I couldnt figure out. Just before I started the last re-write, my buddy that I previously mentioned, gave me a great idea on how to structure the game so that I would not have to spend as much time re-writing the game, and to make it cleaner, easier to add new stuff, and an overall more intelligent way of doing it. I started doing it in the way he suggested and that is where I stopped.

At this point I had a basic layout of the game screen, basic character classes, movement control and a very early map generator (which happens to be my favorite peice of code I have written to date). Most, if not all of this stuff can be easily re used time and time again, which makes the re-writes a bit easier.

So now, here I am about to pick this project up again, quite excited about it once more. I will be writing my progress, thoughts, updates, ideas and possibly snippets of code during this dev process. This will also be a continual learning process, as I am still relativly new to programming in general, but hopefully it will also help people that are in the same boat as I am. I hope you all enjoy this (as it was named by a friend) Progressively up to date singular chat medium, or PUTDSCM (which is what I now refer to this blog as).


Here is a screen shot of my work before I stopped working on it.

Stumble Upon Toolbar