Season updates

More progress on the continuation of RPGroguelike. Getting more things set up with a complete overhaul of the internal stat system and the beginning of moving things around to their own modules for my own sanity though not sure how clean it'll be in the end. This mostly was started when my main file hit 4k lines and I was having to use the class viewer and comments to figure out where the code I wanted to work on was. Hopefully it'll stay clean enough for my tastes for a while.

Major updates is status effects somewhat hap haphazardly tacked on and better pick up and equipment systems. Though that isn't much of an upgrade as it was pretty bad before.

Major goal right now is to try and get abilities being gained mid game, enemy abilities, and areas linked to different monsters. Should possibly make a goal sheet for here or something.

More progress

Lunch break and coffee breaks are being productive. Continuing to figure out things and expand on rpglike as it's a working model.

Got an Overworld set up and multiple dungeons/towns working. Some minor glitches with that and need to get individual monster encounters in there but it's a very good start. Got a lock puzzle set up so quickly it's leaving me a little sad I with how legend was holding up, but it is giving me ideas on how to generate the puzzle dungeons more effectivly though I have a lot more work I need to do on room generation.

thanksgiving release RPG Roguelike proof of concept

So I've got something finished and pushed it through py2exe and heres the link

RPG roguelike proof of concept

Its got bugs and even the ending is a bit buggy but it's still my first finished game. Which is sad as it is poorly coded to me at least but it's done. Still I'd like to expand on this idea and this is more of a proof of concept, not going to expand this actual chunk of code but going to probably use it as a basis to make someting more fleshed out. The floor generation could use a sledge hammer on it as it is pretty boring though following original 'rogue' in spirit. Read me is put here just for convenience of filling this out. Also finished before deadline, yay.


RPG roguelike Proof of concept.

run main.exe to play

A simple RPG combat system fitted on top of a very basic roguelike idea. Go through 10 floors to defeat the evil demon lord.

forewarning : This game was more of a steping stone for me to complete a project and learn from the experience. The game probably has more than a few niche bugs that I have not encountered and may never fix. Also the balance is somewhat skewed. Also there are bad jokes in here, the character selection for one.


Character classes

Rogue : A thief who starts with the highest dodge. Rerolls dodge bonus for going first in combat and running away from encounters. Uses cowardly tactics to increase success of dodge rolls.

Fighter : A warrior that starts with the highest hp. Rerolls strength bonus to attacks. Uses tactics to lower a foes chance to dodge or protect an friend by making them harder to hit.

Wizard : A Mage who starts with a wand. Increases damage done with wands. Is able to cast spells that ignore toughness damage reduction and create a shield on self and friends that may completly nullify an attack, this is however unerliable.

Cleric : A man of faith who starts with the most potions. Is able to call down a smite on foes that always hit and heal allies however is not entirely reliable.

Paladin : A man of faith and steel. Rerolls toughness bonus for reducing damage. Has an oath to protect when used on a foe rolls dodge to get in the way of the attack regardless of the target on a friendly target will always intercept the attack.

Peasent : Repressed extra brought into the dungeon, not really a good option doesnt' even have class abilities.

Keys

Battle
Arrow keys - move cusor around
Q Quaff - use a potion on the target to heal.
A/Enter Attack - Attack selected target
Z Zap - use a wand to deliver a massive magical attack at the target
S Stance - change the character to a regular stance
C class stance - use the class stance for class specific abilities.
R Run - run away from battle.

Outside of battle
Arrow key - move character around
S Stats - view stats
P Pick up - pick up an item off the ground and give it to a party member
> Go down stairs - Go down some stairs.
Enter Accept option - used in menus

Last week rush

Alright RPG Roguelike prototype has had it's map size increased, A minor change added to map generation so it isn't painfully long for most floors, paladins added with working stances, fighter stances added, and initiative now works. So I guess it's time to add bloat features as the floors are actually boring with little on it. Granted the "floors" are simplistic 4x4 grids with rooms and such but I can still try and improve going around them.

Rise from your grave.

So I have tried things. I am both pleased it works as well as horrified that it works.

With more instinct and less planing I have thrown together a system. I am unsure if I've talked about the "RPG roguelike " on here extensively or not but I have had the idea of a party based roguelike that uses traditional RPG combat. While not very roguelike it was always something I had in mind and so I used the idea as a basis to just throw something together. Bad code practices, no planing of expansion, ad hoc addition of new features, and for no reason it became more complete and better functioning than anything else I planed. Even only really done on a trip to a friends house and done on lunch break but here is some things.

Combat from a more civilized time.

The bread and butter of the game. Guys on the right, enemy on the left. They smack each other until one expires. There isn't much to this, while the stat system is somewhat interesting and different combat is pick an enemy hit enter to hit, force someone to quaff a potion, and maybe zap some wands. A little bit of complex things with classes such as cleric having healing/smiting ability, wizard effectively zapping a smaller wand, and rogue being able to bravely run away. Right now fighter is shafted until I do some thinking on how to just toss in his class feature of making allies harder to hit.

Every roguelike needs that Z key to be very important

Some items scattered about. Nothing to brag about, characters can only have one wand at a time, one piece of armor, and sadly no weapons. I plan on putting weapons in soon but the typical "nothing complicated" philosophy has deterred me from adding it as the state of the game currently works.

Move A'tt for great justice

Rooms are small, whole screen is too small right now. I have a bad testing default that lets me look at code and the game screen at the same time. I want to try for a 4x4 room set up and maybe something that resembles interesting rooms instead of this generic grid. Also fog of war, it's not interesting to explore without a fog of war.

Good, bad, he's the guy who starts with the wand.

I said before 4 classes. Each class has different starting stats that matter less and less as the game goes on but have their own  class stance. Class stances are a cheap cop out instead of having menus during combat but it's seemingly working well. I plan for at least one more class and maybe taking out one joke class I added in to amuse my friends I sent this to.

Current plans for this is to polish up what I have, squash some bugs, add another class and some features, and see if I can push this into an exe format. We'll see if I can get this all done before thanksgiving.

Legend redux

After tinkering and doing a few tests I've come to the conclusion that I have hit the classic blunder.

I have optimized my code before getting it to work.

Trying to add to the system is a struggle that requires far more testing than it should and far more planing. I've learned a lot about trying to get this system to work and got what I thought were nice things to put in but I'm left frustrated trying to add new events and functions without breaking nearly all functions before it. Adding new features often breaks old ones in unexpected ways and that's a way of life but I shouldn't be looking into how to rewrite all the old systems everytime I add a new thing as they were too clunky due to optimization attempts.

So I'm going to look around and look at other developments of roguelikes and reread some articles. I hate to lose a lot of the progress I've done but at least I have some functions I can transplant as they were not reliant on the system. Though I need to stop making this harder than it is, for giggles when I visited a friend I got a very basic roguelike set up using some older code I made in the past in about 5 hours. I can't even add in pits in legend in 5 hours which is what the problem seems to be. It doesn't follow my development style and is killing the project more than I am being lazy.

So rewrite three here we go. Least I'll have a few more corpses of experience on this one.

Work load and updates

Alright been a while so I figure some sort of update is in order. This month has been pretty hectic but between last post and this one I have gotten some things done in Legend. I've found a glitch with switches that has been fixed along with arrow not properly destroying themselves on impact with switches. So the old classic shoot the target to open the door is now possible. I have gotten the shooting mechanic linked to a basic variable that pretty much says "you have arrows proceed to shoot" which isn't something I like but it'll have to do for now. Next step is going to be figuring out how to place switches that require an arrow to be shot at them to open up the door without blocking off rooms. There are some cheap solutions like predefined rooms I'd like to avoid but I'm not proud enough to avoid using them just yet. Right now it looks like the quickest way to do this is to put the switch in a corner and make pit tiles around it, simple, doesn't' block doors, and gets the job done. Later I can expand it.

That said times are looking a bit tough in getting to the keyboard to program things. Extra hours at work and just general things getting done has eaten into this. Break time is not long enough for the debugging process right now and I need a better system set up to just add items to the game. Not giving up on it though.

busy life little posts

Not much to say here. I've gotten some dungeon generation code down that I like and works... most of the time. Right now it's step on switch and somewhere a wall moves so that you can pass and go forward. It's rough around the edges but it has some potential. Right now there is a bug where sometimes rooms will magically disappear and link wrong by overwriting a doorway so that you'll walk into the room and walk out of the doorway you just went through to enter an entirely different part of the dungeon. Effectively this makes it so that you can't go back past that point as the doorway that did it was replaced with another one. So fun times trying to fix this bug. For giggles here's a screenshot. I have arrows added as a shift + directional button and may use this as the standard for ranged attacks. I also have FoV made because I thought I could hack out something and well I did. Probably won't be in Legend but it was successful programing. Also added is a menu system to the left, not sure if it'll make it to the game but it was something to try.

mostly explored room

Room east of first one with 2 switches

Stepping on a "switch"

Firing an arrow at the fake door

Minor update

Worked on some tools that may or may not make it to Legend but have finally got a working a* path finding formula going. Maybe could update with something sometime soon but not much worth showing.

Field of View

Reworking the basic display parts of my game as well as storage ideas for maps. What I currently have is far too cumbersome to work though what I am making may not be too efficent. Will work on it later but results are promising. Though side tracked by trying to figure out the ever elusive field of vision formula I always mess up. Completely pointless to anything I'm working on but I still want to get it licked if I ever use it in the future.

Currently working with something called the Bresenham's line algorithm. It's working for revealing all the squares I want revealed but I'm doing something wrong in pruning the blocked ones. Still working on it and learning from it and also may have something simpler to upgrade legends engine. Would just need some readjusting to work with the current generator though.

Progress

Long short is earlier this week I had a revilation of how Zelda keys work and how I was working on something far more advanced. I probably won't be able to work on giving more updates (as if that is a change) for a while as I'm on training at work which is screwing with my scheduled and a lot of other things. We'll see how it goes but progress. I suppose next would be adding combat back in and populating with some basic move towards player gloop and moblin equivalents and adding some sorta simple boss before a shiny ending spot. Then release a demo possibly with the python to exe creator so we don't have to bother with python problems.  Either way progress.

100th post

You know I was going to hold off on a 100th post till I had more done, but life gets in the way and so does myself. I do however have things to share.

 One weekend when I couldn't get anything done a friend made a bad joke involving anime and dungeon diving and I took it to an extreme and made a prototype battle system in about two and a half hours just to see if I could. I was quite happy with myself and realized that I've been getting wrapped up in the large picture and over complicating my projects which should come as no surprise. Though I learned a lot, after all I got this running in 2 and a half hours and it fully works for what it is. Used a lot of philosophies learned from my other projects and improved on the mistakes there to make something small and entertaining. Then I made the item mixing system I always wanted to test as a side note and an odd floor viewing system.

It was really fun and not the general look at my mountain of code and see just a lot of work and breaking things to get it to work. Mostly because everything was self contained and not constantly building of each other while these things could feasibly be layered on each other which is generally how games work. So this got me to thinking about Legend and RPGroguelike as well as my friends (now plural) games I've been tinkering with.

Long short I need to rewrite a lot of things and break what I have. Not completely throw away everything, I think some of my character storage formats and other things are workable, it's just that I have them poorly formatted to what seems to be my general programing style. Short focused bursts that accomplish something without having to debug something else midway through to get it to work. It may be kinda crappy and kinda unprofessional but that's the way I work on my own fun things. I've spent enough time proving I can debug a single program for 8 hours for the majority of a week and make slow but somewhat noticeable progress and my own projects are suppose to be what I enjoy doing. So I'm going to do just that, break my projects up into smaller more manageable components and live on a philosophy of "if I can't add a chunk on my lunch break I need to make the goal smaller".

So none of my projects are dead, but I'm eyeing up better ways to construct them so I don't end up back at this monumental roadblock that keeps me from doing anything. I've already refactored my friends GUI system and am quite happy with how much easier it is. So more of a learning experience. Hopefully I'll have something to show later, may not be any time soon though. RPGrougelike is quite on my mind with how well my friends joke of an idea got done, but I may have to do more tinkering before anything comes out of it.

Haha delays and the need for flow charts

I've been slacking. Quite a few things going on but in the end I have been slacking. Trying to now schedule my time a bit more effectively and actually set some times to sit down at home and get through the hard bits which seems to be popping up in the two projects.

First off in Legends is actually getting a dungeon randomly generated with keys. Have the corridors system set up and and the key placement set up. Should be a very easy goal to accomplish but debugging it took some wind out of me so had switched up to figuring out inventory. That's mostly been designed but some problems have come up that I need answers for, mostly whats the best way to "stack" bonuses from items and interactions between items and other entities. It was real simple in my simple roguelike as just damage was passed back and forth but I plan on having some things like elemental effects of the classic zelda nature. Freezing and setting on fire namely. So without a clear plan on that it's sorta slow now. It can be done and I just need to focus a bit more on it.

RPGlike is actually going along well, getting casting in and all that. The problem is that it's slowly becoming a mess of spagettii behind the combat engine scenes with how the input is coming in and I need to figure it out before I get to the point where I consider rewriting the engine  with every new feature. So long short, I need a flowchart for both of my projects fast. So that's my next goal is to hammer out something looking like a plan for the current systems I'm working with and match code to it so I can better divide my effort instead of stopping dead at walls.

In other news my friends project is developing nicely with me hammering out the heavy lifting parts. Funny how that works but since this is so bare bones it's like junkfood to me and get things done on coffee breaks, I don't think I'll be putting most of my scheduled time to this as it's a text based game but good lord it's nice to have things work.

Random updates

Wow, getting used to this new layout is a bit weird but anyways, updates. More tweaking and figuring out some major decisions for Legend. I think I have an idea of how the incantatory is going to be set up, nothing fancy for now just current weapon, a selection of active tools, and armor pieces. RPGlike has spured this on as I have it mostly done, I just need to make the items have an effect now. RPGlike has also gotten spellcasting working in it a bit, lots of tweaking to get it up but it's framework is there.

Yeah not much getting into here, lots of things going on and work is picking up more. Also trying to help a friend learn how to code, will have to see how that goes. In any event ,progress.

Inventory management.

More code done and more design patterns to figure out. My current goal is to figure out basic selection and swapping of items on a character. This is leading to some interesting problems. The testbed for most of this inventory programing is the RPG idea I've been toying with but I've started importing a few of the necessary items over to legend, that being threading items.

The long short is every interaction I add I have to nest a little bit more and keep some more variables and states tracked. As well as be careful from having the threads lock input out of the game. I can tell doing this for a single entity instead of a party will be much easier but I'm already thinking of better ways to go about this, slightly more fancy than I should but it just seems easier.

success

Quick update, figured out why Legend wasn't working right. Simple fix that only works in the current context of the generator but it's a start. Now to get the locked doors to work properly along with return doors to previous hallways.

What?! Menu fiddling is evolving!?

So haven't updated much. Been trying to fix a few things (and succeeded actualy), but otherwise haven't gotten much farther on Legend. Though in other news...

Yeah, just as blog post says menu fiddling has sorta taken on a life of it's own. Long story short, I farm out a lot of my practice to other files in order not to bloat Legend and work on various aspects there. Right now legend purely has movement and the dungeon generation system as well as the skeleton I've developed to use that. Another file has some enemy AI and playing with more room randomization. Both Legend and this other system have hit a programing wall where the thing I'm working on just takes far too long to work on breaks at work. While I have taken time to work on weekends it's a lot of work and very few things get sorted out. So I started working on some menu work and learned a lot of things.

For one TKinter is not z axis friendly and two animation is a stuff of nightmares mostly as TKinter key binds is threaded. The general idea was to make generic old JRPG where I have keybindings work differently based on screen and started at the "combat" screen. Hit a wall very quickly and realized I needed to get all these ironed out if Legend is going to work like I wanted. So quite a bit of work (that ate up standard legend time) on teh weekend and I think I have the key binding and seperate screen system knowledge that could facilitate a few things. Though this brings up a decision. As it stands I don't have a complete working system for such items.

That brings me to taking on this secondary "rpg roguelike" to get the knowledge down for legends. As a coding basis beyond the horrible problems I ran into so far it's simpler than anything Legend would be doing so it will serve as a stepping stone in actually figuring out more about TKinter before it bites me on the ass again. So legend isn't getting as much work as I want, but I'm hopefully not going to find more frustrating pitfalls in it after I get them all out making something rather simple in comparison.

So far I have random encounters. A somewhat robust loading system for entities invovled, and the ability to select entities. Lots of problems to get to this point but it's been a learning experience. Goals is to use my roguelike room generator to make a "dungeon" to think on some legend problems but this will be ultimately easier as it's just one string of rooms.

With that said I ironed out the moving between room bug I found in Legend. It turns out my efficiency improvement in code had unforeseen consequences. Now to work on getting the doors to other "hallways" to work correctly. To think I was going to start working on tools to get me out of the "no part to work on" spell and realized I needed to figure out how to make an inventory screen which got me here.

slow progress update.

Some progress that don't seem like progress is the standard at the moment. Legends and my other half played with testing grounds for things have hit some programing roadblocks. I have an idea of what's wrong with both but just not the time to sit down and really work it.

That said I am making progress on it. Legend has the very basic dungeon generation down, it's just the changing rooms that is odd at the moment. Best described as walking into the next corridor telports you back to starting room and the doorways aren't refreshing right. It took a while to figure that out as nothing made sense in my debug map and I couldn't walk through some doorways which were in reality walls. Still progress, I have hopes yet. If all else fails I'll just have to work on the items a bit to get them down.

Enemy design : No one wants to design the newest kobold

And you would feel bad but he's carrying a poisoned blow gun and poisoned darts.

Work has been interesting the past week so little progress has been gotten. Hopefully today I'll change that though it's not the focus of this little post. Today I'll rant a bit about enemy design and more specifically enemy variation. Why this has kobolds in the tittle that will get to in a bit. For now I've been playing a bit of other roguelikes and just thinking about enemy design in general and noticing two types of trends.

One the linear variety where you have Some roles are always filled out on each new level with the exception of bosses. Older games used this a lot with color or sprite swaps like the enemy that runs at you, the enemy that fires a ball of energy and the jumping enemy. Maybe they get more health and damage between levels and maybe a gimmick enemy to change the pace and earlier enemies just to have more variety but more often than not different levels have different enemies which is a good thing.

The other is more of a growing amount of enemies. In the beginning you see a few then as you go along a few more types are added, than latter even more types are added, till the end of the game you have a lot of unique enemies and possibly bosses that just show up in the last area or even just rooms of the game. This isn't a bad thing either, it's a save the best for last approach that only fails if the player doesn't get here which seemingly is a common occurrence.

Now for what I bring up. Roguelikes are somewhat unique that it's rare for people to finish the game, or even to get to mid game. Playing a roguelike people want a somewhat new experience and to see what the game generates as a level and what items they pick up along with what they encounter along the way. With both the previous design patterns the player isn't really seeing much variety. Under the linear enemy addition they see a percentage of the game and may see all the enemy movements but they wouldn't even know that. The constantly growing about of new enemies added shows roguelike players even less of the game. Some players can get frustrated only seeing the first three enemy types and dieing to the first or second goblin or kobold they see as they haven't figured out how the game works yet which can be very frustrating to a player.

Now I can think of a few reasons why this sort of design happens. Linear is basic requirement meeting for a level that came from a time where the technology was limited and wanted to avoid repetition in the players minds even if the mechanics were minimally modified. There was even an article on 1UP I saw a long time ago that reminded just how little variation there was in early games. I hate to say this isn't a bad thing again but it isn't at times. Some predictably allows for game mastery. I digress though, the tradition holds over for seemingly no reason other than it is legitimately hard to to not follow a formula that guarantees the levels will be filled out with enemies that the player will at the very least think are brand new for a few minutes if they actually think about how they work, a more frantic game may increase the period it takes to realize what it is.

The growing type is a bit of a different problem that actually may come from someone with too much thought into it. When creating a game the first few levels are more or less introductions and you want to build from there. So a natural trap to fall into is to keep piling on all the great ideas you have for enemies as the game goes on, leaving all the good bizarre stuff at the end under the assumption the players can take anything or at least put up with it. The other reason being that people would rather make interesting things than just another kobold. Interesting often goes to favoritism which often equates to "this thing will kill you!" design wise. MMOs commonly suffer this  for another reason. This is because they want to keep older players who reach level cap around. Low level zones are rarely upgraded with new interesting content while increasingly complex or gimmicky areas are added to end game. Design wise MMOs are striving for something different but I figured I should note it.

Now a seaway to kobolds. Kobolds have a long standing in D&D as the low level creature new adventures cut their teeth on and generally their traps are more to be feared than an actual room full of kobolds. Now as I said before people don't want to design kobolds, as people don't want to put much work into things they'll be stomped repeatedly. This is also true of D&D where you have entire books devoted to levels most people will rarely reach in normally gameplay unless they started there.

Playing a few roguelikes recently I've been beat over the head a few times with it. Seeing giant rats and various low level kobolds and dieing to them annoys me a bit. Playing crawl, which is the only general roguelike I've gotten far on , I know late game has a lot of enemies. While the start has bats, giant roaches, the first real threat of goblins, and everyone favorite dog to kick kobolds. This is fine except you'll have to go through these same enemies quite  a few times with no real variety (beyond a killer kobold who's picked up a wand of death/blowgun with poison needles) . A thing I have come to appreciate is enemies picking up gear and using it as it's a natural way to add variety when you can see it happening.

So a solution to this? No real solution truth be told. This is a hard problem to tackle if we don't want to overwhelm a player with things to understand in the first few minutes. Desktop dungeon which I have talked about in the past had an interesting approach. It had a relatively easy and simple enemy pool at the start and every class you beat the game with unlocked new types of enemies to be added to the pool. This keeps it interesting every time you play while not overwhelming you. It is somewhat artificial though which leaves me a bit annoyed about it but in practice it's good. For me it would just be more honest to have a larger pool at the start and let only a few of each type be used in the first few floors. Just something to keep it a bit interesting enemy wise would be worth it. For legend I haven't even started working on enemies so I should keep this in mind as I develop things.

Slain hydra

Short update for this. In my last post I mentioned the problem I had with Legends preliminary generation. Now that problem is gone, small little bug as I expected and should have avoided but how it goes. So now that that's solved I have to figure out how to translate the layout into the actual room data which will be interesting.

In other news I'm reading through a copy of Programing AI by Example by Mat Buckland. It's getting me some AI techniques and such though I'm having to look into dreaded math. We'll see how this pans out. I've been playing with a more old style roguelike set up just to cut teeth that won't have any impact on Legend but it helps get the bad practice out.

Hydra

More work done, mostly in other roguelike things as  I thought it would be good practice. I got old style Rogue like dungeon rooms (based off some reading) and a bit of line of sight work. Not directly related to project but gets me in the mind set.

What I do have is in the image. A huge mess that I call a hydra ,it's made of necks and heads that shouldn't' be there. To keep this somewhat short I'll breeze over the idea of how dungeons will be generated. a hallway is placed down connecting to it, then one or more hallways are connected to it until finished for the length. This allows hallways to have an order which require puzzles, room cleared of enemies, keys to open the door to go onto the next hallway and so forth until the dungeon is finished.

Problem up there is that should be 3 hallways of 4 rooms. There is a lot more than that in some order I barly understand what it's doing. Probably a simple bug, but would take a long time to find. Lunch breaks don't offer all that time and my weekends are sorta dominated. Though I keep cracking.

updates event handler edition

Do gibs even belong in this game?

Alright more progress. I had events working before, and have had enemy entities moving around and such. But finally got in "attack" code right now. It happens when an entity moves onto another entity and right now only the player entity has it. Automaticaly sets the others HP to -9999 and their color to red, after that I had to get on_death functions working to properly drop gibs (and later real items), remove itself from the room, and add a death message to the event handler. Right now the event handler is really just a glorified list that keeps 5 lines of text in check, but it's effect is much more so I'll take a moment to talk about it.

The philosophy behind the event handler is that it gets passed to every instance that uses it so that they can take care of themselves. So you get hit and the character object that defines you does calculations, sees that it has an event handler and uses the event handlers add function to put another line on there. This is also used for the doors, the item pick ups, everything. It keeps the main loop from having to know what every single entity does under the hood to properly display the text which I find to be quite useful.

Now I'm not sure wha tthe next step shoudl be. I may play with giving the enemy mobs some attack code and properly patching them up so they don't "eat" each other by destroying their fellow moblin/goblin/mogoblin id at locations or walk through "doors" and cause all sorts of trouble.

Late night quick post

A little more gets added each day. Most important was actually last week but mock up a proper "scene" just didn't seem to get my programing spirits up as tacking on more stuff. So no ascii in game image.

What we do have now is saving through good old fashioned not really efficient pickling. Took a few days to uncouple TKinter from the data structures and getting methods all to the top most module for remembering functions and it was golden. Size was a little big so I subclassed some dictionaries to act as 2d lists, which I could further optimize by making it just a single dictionary with some more trickery and math in it, but I don't do math well. The save right now is about 16 KB which through zipping can get down to 10 KB, not bad for out of the box saving.

I can improve this through some better class sub classing and getting rid of irrelevant data to be saved (like stats in a wall or objects). Though the real size change would come from me writing my own save output. For now though pickling is the way to go and lets me examine a world to a degree and modify it on the fly without recoding in the middle of it.

So saves and loads done. Next I overhauled the display system getting it more towards useable. I have event text coming out at the bottom that is triggered through various things. Only holds 5 of the past events and no logs at the moment so a bit limited but workable. After that I set up somewhat of an internal scripting system to allow events such as stepping on to give commands to the engine without a whole bunch of function nonsense (as there is enough of that) so stepping on an item can tell the DM to remove it from teh room. Somewhat proper object orientated design as the item never needs to know the room it's in or how to interact with it. Last I got done was the beginning of puzzles. I can get objects to disappear and be placed by stepping on them. So things such as switches are now possible. Next I'll see about getting damage back into the game and smack a few mobli-goblins around in the test dungeon. I've already had them spawned just  to see if they'd persist room transition but had no interaction with them beyond trying to get past them as they move about randomly.

Super Alpha release?

Blame friends for bad jokes, and me for actually putting them in.

So I guess this is a release? It's not clean, it's probably got spelling errors and game crashing bugs, but god does it feel good to get it made.

I almost deiced to not release it but this actualy makes me excited. I finally got something that halfway looks like a game, this never happens with my little projects. There isn't much to it and bad jokes abound but it is a piece of software with a start, a middle, and an end (that hangs forever). So I decided to put it up. Next steps will be making more monsters, item pick up, and figuring out how to save this.

Simple run of the engine, not even properly re-sized for the GUI. You walk around with arrow keys and proceed through a whole 9 to a treasure. Though there is a trick to it.

Get it here . Should run on cPython 2.6 though made with 2.7. Read me should be iside if I didn't mix up files. Run the Dungeon_Master.pyw to get the game to work.

Break time is fun time

Family friendly entertainment

As I get breaks at work and bring a thumb drive to have music I also bring code to work on. Last night I got to the point where things could hit things and mobs would move around (after much bad AI work) so I added the bad idea of giblets to the code.

Doesn't do anything but it's possibly going to come up more later. Enemies that drop bombs on death for instance or maybe just good old fashioned key dropping. The random gib tile is a thing given by the on death variable I put in the character so it really could be anything. Function passing in python (with default value editing) is quickly becoming my favorite way to make objects. Next up I'll try going about some actual attack and defense things and get towards the final screen sizes. After that tackle dungeon screens with a hard coded maze.

it begins

<link to music with copy rights here>

So I've revamped the simple rogue like system and spread it over a few files. Easier for me to chew when working on it though a little confusing with all the windows. Right now no movement and such but my tests show it still works for that. Either way progress.

So for this quick blog on break I'm going to go on about my goals for this Zelda Like Rogue Like which really is only taking inspiration from those games. Probably far too much of it considering the format for my goals. The basic goals that are needed aren't even given any tags. The ones that are have special importance. Milestones are goals that I see as doable and would greatly improve the game so I am going for them. Power Goals are goals that I think are great but would require a lot of work and may be more trouble than they are worth, though I think they're worth a lot.

So first off. Main goal for this game. A package of code that can run with vanilla python 2.7 (which I may even package a striped down version with the game to make sure it runs). Not using the Curses library, while it's a roguelike standard I prefer working on it as a graphical approach even if it is a canvas filled with single character text blocks, it just gives me more options that I may use. Now for the List via special categories.

Zelda List

Screens : Rooms both inside and outside
Screen transition *MILESTONE* : Not just teleportation between doors, screen moves in a zelda like fashion between rooms.
Mobs : Standard
Overworld : The large dungeon between dungeons
Dungeons : The crawl
Tool items : Meat and potato of this game. It revolves more around the "tool items" more than monsters and finding better weapons.

Zelda 2 List

Stats : How large or small  I'm not sure
NPCs *POWER GOAL* : And not the vender kind, the ones with random bits of information that could help a player if they get lost, sorta requires towns.
Towns *POWER GOAL* : Where NPCs gather safely and have innae babble

Zelda a link to the past List

Side quests *POWER GOAL* : These technically appear in original Zelda but I remember more little side quests from this game. Get health up and other effects here.

Puzle temples *MILESTONE* : Meat and potatos of game, it'll be hard but it needs to be done. Technically original Zelda had this but in a more prevent you from getting through as you don't have the items that let you move over obstacle way. This is more you need to hit this switch with a boomerang and put a bomb down here and run across room idea.

Own list:

Randomized backstory *POWER GOAL* : I'm not using zelda and I'm not sure where else to get "plot" for. So random list of names and event sequencer could be fun.
"Puzzle" Bosses *POWER GOAL*: I'm not sure where this one started but Bosses being weak to their dungeons item is a common theme.

More to be added at some point or further explained/explored but I think this covers the basics. Only one more thing left

Please don't sue me Nintendo

A bad reason why I'm not using Curses. Wonderful graphical offsets

Not dead just busy

So I officially close the simple rogue like project I've been doing. It's been a fun ride and I learned a lot. but this is not quiting as I actually have accomplished my goals. Killing letters, leveling up, mobs, moving around, picking things up, item use, and changing rooms are all accomplished. Now why am I "giving up"? Because I'm not.

It's changing into something I believe I have enough tools at the moment to do, an actual roguelike with some unique ideas. I'm retentively calling this project "Legend" for which I'll get to in a minute but first. Some progress in traditinal roguelike things. Random map generation.

Ain't it pretty?

Some minor glitches that I won't go into but that's an 11x11 set up of "screens". not a level, but "screens" or rooms for a level. Legend is from what I'm looking at going to be interesting for a roguelike. As it's going to be based on some ideas of the older 2d Legend of Zelda games. This means "screens", boss fights, tools, and most strangely puzzles.

I haven't seen any roguelikes that really have puzzles in them as far as I know. While I'm not attempting something exactly like being in the Legend of Zelda vein It's going to have the same basic idea. You get a tool in the temple, use tool on parts of the puzzle to proceed further. The very basic isn't hard to imagine, just have to have the tool before the parts that require it but I still expect it to have a lot of bugs in coding.

Now I'm not going for ZeldaRoguelike completely but to say this isn't inspired by it would be a lie. What I will be doing is taking the puzzle elements, "puzzle" bosses (if I can), and some other features. Things like Hyrule, rupies, heart containers, Master sword, Triforce, and Ganon will most likely not be making the transition. I'll be making a goal list later at home for what I want to do with this project but I am very excited about it as I actually think it's feasible for me with what I've made.