Motivation waning...

Gah.. I hate this part.. So, I'm not happy with what I've done so far in the game, and it's making it so I have really low motivation to keep going.  I feel like I need to rewrite the engine, and at the same time, all my friends are kind of "meh" on the game concept.  I don't know who I thought would play the game, but that's part of the fun of making a game for me, is imagining people playing it.  I suppose I could just make it for me, yada yada.  So, my todo list right now looks like:

1. Copy the most recent codebase off my craptastic laptop so I can work on it on my much nicer desktop machine.
2. Reorganize the game engine, and start a rewrite focusing on making things more clear and encapsulated.
3. Try not to feel guilty every time I sit down to code that I'm not doing something more productive like look for a job, or something.
4. Find the motivation to continue working on it, even though I might be the only one who plays it.

Yeah, that looks about right for now.

Intermission

Alright, I realised the other night that I was totally lost in my own code.  I was writing code and just waiting for the error messages to see if I was doing it right.  Bad, bad, bad.  So, I decided to just do a rewrite, with a mind toward consistency, readability, and ... yeah, just kind of a rethink.  For one thing, I'm going to be a little more lenient with my self about what's an entity and what isn't.  I mean, I tried when I first started, making the screen an entity.  It was a pain.  Recently I tried to make the map an entity.  I mean... will the map ever have an image of it's own, or get turned into a shoe or something like that?  No?  Then it really shouldn't be an entity.

Oh, another important lesson I learned the other night.  If you're going to load an image into memory for every entity, don't make a 1024x1024 map filled with unique floor entities.  Yeah... didn't think that one through.

So.. different topic for once.  Just for fun.  I

Crap... Gotta pick up my son from school. Until next time... :-)

Fragmentation blues

This constant starting and stopping work on my game is really becoming a problem.  There's no way I can just work on it non-stop, which I would do if I could, so I need to find some kind of project management tool.

For instance, I set up my ghetto laptop (the old Dell that had water mysteriously spilled on it. Still works, but needs a usb keyboard hooked up to it) at a friends house the other night and got to work for about 4 hours straight.  It was nice.  One thing that came from that though, is that I found one major instance where I was working on two different solutions to the same problem in different parts of code.  Ugh.  I think every time I would sit down to code for 20 minutes, one or the other solution would come to mind and I would chip away at it.  Never realised what I was doing until I had enough time to work the problem all the way through and ran into the other solution.

Anyway, a good friend of mine, and professional project manager, suggested at least I use a project outline with items I check off as in progress or completed, etc.  He spent some time with me yesterday fleshing out an outline.

Another problem with not having any type of project management, as well as having unpredictable obligations with family, is getting interrupted in the middle of big rewrites or major changes.  I feel like a surgeon, covered in blood holding a patients guts in his hand, who is just told he needs to stop immediately and do something else.  Meh.

There's nothing useful in this post.  Just venting.

Oh, I'm back on map crap.  I think I finally found a solution that will work.  I forgot to think about what will make it easy for the render function to quickly get all the items that need to be drawn, and in what order.  Plus the ordered list for what's in a tile location is gone.  I'm going with three layers.  Background has only one item, foreground has only one item, and midground has a list ordered by eid (arbitrary, doesn't matter but shouldn't change).  Background and midground are always passable and foreground always blocks movement and line of sight.

And.. I should be coding instead of yakking.

Not dead yet

Alright.  Normally this spiraling out of control obsessing about a problem would kill a project for me.  Especially when I'm getting zero time to work on it.  Today, I'm using up part of the half hour I have to work to write this.  I keep swinging back and forth between maybe I'm doing too much, to maybe I'm doing too little.


So here's what I've got so far, and this is what I'm gonna try to implement:
Dictionary of Maps -> Dictionary of Areas -> Dictionary of tiles -> lists of objects.

Map keys are tuples, (name, level).
Area keys are tuples of grid coordinates (area_x, area_y)
Tile keys are tuples as well (tile_x, tile_y)

Sick of maps yet? Yes I am.

So, yeah, there's all this great technology for storing data, retrieving it quickly, etc.  Just realised however that there's not really a magic bullet, as I thought there was, there's just lots of ideas that may or may not be useful.  The key is to define what exactly you're trying to do, then find the tech that lets you do it the best.  For example, I was recently reading about John Carmack of id software doing some cool stuff with shadows in Doom 3.  Well it wasn't a solution he came up with, it was one he implemented that someone else came up with in 1976.  So yeah, it wasn't the magic bullet for a lot of people, but it was for him, he just found that it solved his particular problem.

Alright, enough exposition.  What's my problem?

K, we've got entities, lots of em.  The walls, the monsters, the items, maybe even the floors.  They're all in this massive dictionary at the moment.  Which.. now that I think about it.. probably isn't going to work once we're talking about a couple million entities.. Hunh.  Dangit.  Well, no, wait, hold that thought.  What will solve the map problem should solve the problem with the rest of the entities.  For one thing, getting the map to work should let us break our massive lists of items into small chunks.  Though.. how will that work.  They're all in a big dictionary right now.  Even if we're not looping through every item in the dictionary, looking up items by name in a million entry dictionary is still time consuming.

And now that I think about it, if we're talking about a million items, and they have memberships in many multiple dictionaries, then we've got multimillions of stuff in ram.. :P

Alright alright.. stop that.  I have no way of knowing what is and what isn't a misuse of resources or whatever.  I wouldn't know because I've never finished writing a game.  So,back on point.

We have, entities.  We need, simple boolean grids for line of sight, for light fall, for collision.

Okay random thought.. (darn you add) so, I'm trying to see how we're going to deal with AIs that are off screen.  Unless we're simulating the entire world, then we need to break it down.  So here's a thought.  We run the ai for all entities within one screen of the player, so nine total, but then also run it for all the screens he's visited for a certain amount of time.  That way you can't piss something off, run away three screens, and when you come back it's forgotten about you.  Plus it would be cool if it's computationally economical to run the ais for more than just one screen around the player.  We'll see.

---
man... I've got dora the explorer playing on a tv that's about ... well it's about one foot away from my head.  Plus I was asked to rip an avi of Elmo's Potty time.  My thought process is totally screwed.  I guess I'll be back for episode 24 of maps in hell...

Maps maps maps...

Alright, so one of the problems I'm having I think is that.. I don't so much need a traditional map, with or without layers.. I need a world space for things to exist.  I mean, everything has coordinates, so why would some things be in a special map grid, and some things not.  Still not totally sure how the map is going to work, because for some things like LOS calculation or pathfinding, we're going to want a simple 2bit array of walkable/visible space.  But I think it'll probably be some type of BSP tree, or other hierarchical structure.  The entire world being the first node, then somewhere along the line there will be a screen sized node, then a square tile sized node, then ... what else.  Need to keep reading, both for education and inspiration.

Map hell

Dear god.. what am I doing.  Spending hours reading about bsp trees, sparse matrices, other crazy stuff.  I feel like there's a right way to do something, and that's the way I want to do it, even if I have to spend hours reworking or learning something to do it.

Of course, the problem is how could I possibly know what the "right" way is.  Maybe it helps that I get fixated on ideas sometimes.  Or that's the cause, not the cure.  Eh.  No matter... I have to take the fam to the grocery store right now anyway.

Alright, so, more map brain storming...

Alright.. I'm liking the map scrolling system from the last post well enough.  Well enough to test it out at least.  Now, as far as storing map data.. how are we going to do that.  If I'm using something like libtcod for line of sight and pathfinding, then I'll need to pass it an array, not a list of entities.  I can have a system that creates that and passes it to the lib.. though I feel like that would be really computationally intensive...

Having a little trouble keeping a solid train of thought.. At my mother's house at the moment.  One kid is playing 10 feet to my left, one is playing 5 feet to my right, and my wife is talking about something.  Not to me.  I suppose I'm being a little rude by doing this rather than participating in various activities.  Eh, oh well.

Ugh, plus I've got to do something incredibly stressful in a couple hours. :-P  This guy that I worked with before I was laid off a couple months ago needs help with some computer stuff, and for some reason wants me to come down and help him.  He's paying me some unknown amount, rather than ask the IT staff that still work there, probably because the guys that are still there are jerks. ;-P  Well, no, really, they are.

Alright, totally sidetracked at this point.  Not going on a rant ... :P  Can either stop writing... oh dear, my 2 year old is pounding on the piano now... or try to muster my concentration and see what I can do.  I really am interested in finishing this game, so I'm going to try and keep working.

It would be cool if I had a laptop or something.  I could be programming right now instead of just blogging.. or journalling, or blathering, or whatever..

Anyway.. okay.. so the problem is, how do we deal with the map.  If the map tiles are going to be just another entity, then they shouldn't have a special map aspect since there will be a lot of things drawn besides map tiles.  They might need a weight, or layer property somewhere.  Maybe in the form aspect, like they already have an x and a y, so maybe they need a z.  The problem there is.. keeping track of what's on top of what.  Somewhere there has to be a list of what's in a tile so that we don't end up with two things with the same z.

Argh... interruptions every two seconds... gah... I need a hole in the ground, or a tree house, or a log cabin on the side of a mountain, or something. :-B

wtf.. where was I.  The ground is immutable, since it's a 2d game, so you could just have this massive grid and everything is assigned a unique id for what square in the world it exists.  That seems to go against the whole entity system though... I guess it makes sense though.  The alternative would be what.. you have each entity know what is above, below and beside it, and you draw the world relative to the player.  This massive linked list.. sort of.

Ugh... this is obviously not a good time to be working on this.  My wife just asked if she left some persimmons in the trunk of the car and I nearly lost it.  Wtf?!? Go look! I have no idea what you did with the persimmons you bought.  Are you telling me we have fruit rotting in the car?  I suppose if they are in the car, you need me to go get them, yes? :P

Eh.. better vent here than cause problems.  Gah...

Map brain storming..

Or should I say, thinking out loud.  Or.. thinking.. while/through typing.. or whatever.

I'm trying to visualise the movement system.  I don't want to do zelda style because that kind of breaks with line of sight.  If you're going to have connected maps you can't walk off the screen and be right next to some terrible danger or off a cliff or something.  Since we're doing fluid, connected maps..

Well, even that.. why think of the world as a series of connected maps?  I guess for one reason, so the game doesn't have to think about the entire world just to show the small area the player is in.  But back to screen movement.. I don't want to ahve the player be a fixed point on the screen and have the world move when you walk.  Then again, that's how world of warcraft does it.. and how all fps games do it.  Heck, that's how real life is.  Seems like it would be "cinematically" disorienting though.  Kind of like watching a movie in first person view.  Hmm.. maybe it's only disorienting when you're not in direct control.  Like, do the player in the center version when you're tap, tap, tapping your movements, but hold the world still and move the player when you're doing walk to point movement, then reorient when you stop. ?  eh.. gotta go pick up my son from school.. think about this more later.

Maps...

Ugh... how am I gonna do the game maps.

In the past, when I've needed a map for a tile game, I just create a 2d array, and there you go.  Fill the array with tile objects.  Now though, with this entity system, things are different.  For one, all entities already have coordinates, so there's no need for a map array.  Although having one could make looping through just the map tiles easier.  Plus if map tiles are just another entity... and this is a 2d game, I've got to separate layers.. like what's passable and what's not, what gets drawn on top.  I don't want to necessarily say that just because something is terrain it's on the bottom layer.  There will be other entities laying about, and they all need layer information too.  No reason to create a special case just for terrain.

Another thought I had was... what is the coordinate system even based off of?  Is the whole world just the size of the screen?  Should it be infinite?  If so, how do you work out the offset for coordinates.  Maybe the game should run old school zelda style, where if you walk off the edge of the screen, another map slides into view.

Ah.... interesting thought.  So, what if... You have a map aspect/entity that represents one screen full of information.  Then tiles, monsters, whatever can have their x,y grid relative to the map they are associated with.  Then the map has the names or ids of the four other maps that are adjacent to it.  Then you can have infinite maps without coordinates.  Oh six maps, I guess.  For above and below as well.  Hmm.. another thought.  This wouldn't even have to be screen sized maps either.  They could be anything.  256x256, 16x16, whatever.  It would just be a way of chunking up the map.

Alright, so, big question.  Are we doing the Zelda style maps that flip when you reach the edge, or smooth scrolling to infinite distance...

You know, it would be a lot easier to do the zelda style.. but more fun to have the infinite scrolling style.  But much harder..

Wierdness..

Alright, so... The weird thing isn't that blogging has helped me work through problems, the weird thing is that now I just imagine blogging and the solution comes to me...

meta entity.. possible misuse of the word meta...

Alright, form thingy done, dead code pruned.  Now I only have two aspects, goal and form.  To be added will be things like container, and health, and other stuffs..

So.. I want to have an aspect that designates who is controlling the entity.  The idea being that the player might at some point be in control of a monster, or something.  Plus the AI systems would have lists of who they were controlling.

Well, I guess that answers my question.. sort of.. maybe it's more of a trailhead than a finish line.  Anyway, the problem is, if the player entity needs the id of the controlling entity, would it be itself?  Or can I assign an entity id to someone sitting at home playing this game on their computer?  I think the answer will come when I decide how the AI system will work.  I'm assuming it will be sending a stream of goals for the action system to chew on, just like the player input system does.  So, however I decide to identify the AIs of the game will be the same way I identify the player.

Latest issue

Ugh.. okay, so got the little dude running around.  Now I need a world for him to run around in.  So, map tiles.  Seems like they could be just another entity.  I like this idea.  No idea what the performance effect would be, but hey, this is 2011, not 1988, so it really shouldn't be an issue.

Now, the issue is, I want a "blockable" or "blocking" flag for my high-tech tile based collision system.  So, do I create a new aspect called "blocking" or do I tack that on to appearance.  But now appearance isn't just about what the item looks like, so as long as we're doing that, maybe we should roll the "position" aspect into appearance and call it "form" instead.  It would let me pass just one thing to the render system, though how many things I pass is really inconsequential.  I dunno.  I want to avoid lumping too many things together, though how granular do I really want to get.  I can't think of too many things that have a position that don't have an appearance, eh... screw it, I'm doing it.  Lets see if I can keep from breaking everything as I roll everything into a "form" aspect.

Why am I doing this instead of coding

I guess because I was thinking about it as I was falling asleep last night.  I was wondering how many lines of code it took me to get to "little guy moving around the screen". The answer is.... 461.  I have no experience to tell me if this is a lot or not, but I do know in other languages I've done the same thing, at least on the surface, in about 10 lines.

Edit: decided to go for 16x16 sprites.  For good or bad, it'll let me draw the whole map on the screen at once and not worry about scrolling, at least for now.

Oh, and how hard was it to change from 32x32 tiles to 16x16?  Just had to change the number 32 to 16 in one spot.  Neat!

Too fun

I should really go to bed.  I just finished my Coke, but caffeine has never done anything for me.  I can honestly go right to sleep after taking ritalin, though I've only tried it a couple times.

So why am I still writing?  Eh.. I dunno.. it's like having someone to talk to I guess.  No one else is awake, and if they were, they probably wouldn't want to talk about this stuff.

Eh.. good night internet.

Okay, timed it..

Hunh, it's actually faster to multiply on the fly than to look up a precomputed value.  Weird.

import timeit

setup = '''
y = []
for x in range(80):
    y.append(x*32)
'''

t = timeit.Timer(stmt="a = 80*33", setup=setup)
print t.timeit()

t = timeit.Timer(stmt="a = 80<<5", setup=setup)
print t.timeit()

t = timeit.Timer(stmt="a = y[79]", setup=setup)
print t.timeit()

So yeah, that gives me the result:
0.0310996928381
0.03094031504
0.049108406236

Some miniscule advantage with bit shifting (I multiplied by 33 on purpose so it wouldn't bit shift behind the scenes.. though maybe it does then adds 1... :-/ who knows.) but yeah, there we have it.

New questions...

See.. now here's one of those places where I get into trouble.  I have some choices, and I usually pick the hardest one if it's a matter of doing things "  Hence building an entity system from scratch when there are many tried and true methods of doing roguelikes that don't use one.

The problem: Since the game is grid based, when a player moves he goes from space 1,2 to space 1,3 for example.  But, depending on the size of the sprite, say a 32x32, he moves 32 pixels each time he moves.  Now, do I have the rendering system look at a the single spaced grid and just multiply coordinates by 32 for every single thing it needs to draw?  Seems like a lot of calculations.  Maybe the compiler knows enough to just bit shift a few spaces over so the multiplication is trivial.  Dunno.  Maybe I should keep track of two coordinates for everything, and only do the multiplication when something moves.  Maybe I should make a lookup table where all the multiplication is precomputed.  I dunno.  Crud.  Hate stuff like this.  I guess I could time it, see what's fastest.  Then again, this is a turn based game, there's not really any FPS target to worry about.  Maybe I should be worrying about just making something that works and not so much on the best way to do it. :P Ugh..

Movement..

Holy crap.. I actually got the movement system working.  And by movement system, I mean the whole player input, entity goals, action system working.  Wow.  :-D  <-- Happy me.

It's 12:37 at night, but I just sat down a few minutes ago and I'm drinking a Coke, so I may as well use this time alone to see what other damage I can do...

Watching The Island

Ended up going to my friends place after all. :-)

More lessons

It's kind of interesting, with this 'entity system' I've been fooling with.. For one, it's definitely taking me to new places with Python.  Well, and in programming in general.  For example: something a little different than a giant list of if, elif conditionals.  Puting a list of functions in a dictionary.  Of course, this hasn't worked out quite as smoothly as I was originally hoping, but still, a learning experience.  Once it was all said and done though... I'm still not sure if it's better than a bunch of if, elifs... Ah well.  We'll have to see if I can get back on my computer some time this evening to fool around with it some more.

It's kind of sad... I'm still at the pre-player movement phase of the game.  I can't even walk around yet.  Lame.  So, yeah, that'll be my next milestone.

So, it must be said... I'm typing this with a little bluetooth keyboard into my phone, running a Blogger app.  I should probably submit soon to see if this all even works.  Well, the Blogger app part at least.  I'm also sitting in my car in front of my son's school, waiting for him to get out of class for the day.

What else...  Oh, my wife noticed my last blog post and wanted to know what the heck this cult was that I'm joining.  I explained the name to her.  She seemed happy to hear that I was working on making a video game.  She immediately asked me if I'd applied for any new jobs as soon as I was done telling her about it.  Yeah, I'm unemployed.  Go me.  Anyway, I just can't imagine sitting around feeling crappy that I don't have a job 24/7, so yeah, sometimes I work on fun projects like trying to make a video game instead.

Looking forward to hanging out with a friend this evening.  Usually we watch movies together, but there hasn't been anything out lately that we've wanted to see.  I'd like to just hang out at his place and continue programming, but I don't really have a portable development setup.  Ah well.. we'll see what happens.

The Grid

Man, I keep obsessing about this.  See, the problem with making a graphical roguelike is that even years and years ago, with text, you can have an onscreen tile grid of 80x25 or less frequently 80x50.  To do that with sprites, say I gave myself a measly 16x16, I'd need a 1280x1024 screen to do 80x64.
I like pixel art, and I can do a lot with 16x16.  The problem is when you're at 1280x1024, those 16x16 sprites are like, half a centimeter square or something.  You've also got the added problem that, now that you're not using abstract representations for the various creatures and objects, your images aren't going to be to scale.  Dragons are the same size as potion bottles for instance.  You could escape the tile size vertically, by having tiles that overlap the tiles "behind" them.  In that case though, you might want to make your tiles rectangular instead of square, to imply an angular view on the play map.  Ugh.. endless possibilities.  One problem when you're not working with a team is you get to flip all the coins, make all the decisions... meh.

Now my wife is looking over my shoulder and I'm feeling self conscious about what I'm writing, so that's it for now.

The name of the blog...

One other thing I should write, as long as I'm imagining someone reading this besides me; an explanation for the title of the blog.  It's the name of the game I'm working on.  I don't know precisely where it came from, just oe of those things that popped into my head and stuck.  The Horned God is a reference to the being of the same name in Celtic mythology.  I thought it would be fun to do a Roguelike with monsters from Celtic/Irish myth.  Pretty much my plan is to go through Katherine Briggs dictionary and make a list of creatures I'd like to see in the game.

The "Cult of the" part comes from my love of the Cthulhu mythos.  I was thinking it would be neat to take celtic mythology and treat it with the same horror noir that Lovecraft usually gets.  I'm not sure yet if I'm going to set the game in the early 1900s yet, or what.  Kind of playing with the idea of maybe making the player be a member of some organisation like the BPRD, or a supernatural hunter, or something like that.  We'll see.

Do I really need a title for another ramble?

I'm just thinking.. this isn't a typical blog, or at least I'm not trying to make it one.  Well, maybe it would have been 10 years ago, but today people try really hard to make blogs a publishing platform.  They edit and re-edit their content for impact, seo, information, whatever.

So... yeah, I'm not doing that.  If I'm the only one who ever reads this, that's good.  Well, I guess the fact that I'm writing this says otherwise.  But basically I'm just writing this so that if someone stumbles across this blog.. I don't know...  They'll know, that I know, that this isn't a "well written" blog.. It's just some random crap.  An attempt to add some continuity to my thought process.

More yada yada

Alright.. played some battleship, a little Wii Fortune Street, and now the kids are in bed.

I hate this time of the evening.. I finally have free time to work, but my brain is starting to shut down and I'm really worthless trying to get any programming done.

Back to the thing... So yeah.  It was supposed to be a simple Roguelike, but not only did I decide to use graphics, but I also decided to roll my own entity component system for the game engine.  At this point, thinking about how stupid that was is moot because it's pretty much done.  It's done to the point where all I'm doing with it now is trying to figure out how to do little things like player movement with it, and philosophical things like is the player an entity, meta entities, etc.

I kind of ran into a chicken and egg problem where I wanted a player that I could walk around the screen, but I would need a world, character generator, etc.etc. So I just faked it and created a "test" system that gets called by the system manager during init that just creates a player entity and slaps him on the screen.  Doesn't work 100% yet.  Trying to decide how player control should go.  The obvious method would be to read input, check for collisions, and update player position.  Basically.  With our shiny new entity system, it's going to be something more like, Control System looks at game events and sends keystrokes to a dictionary of methods.  The methods decide what game components need to be updated, then various world systems check the components for new information and execute the changes required.

Ugh.  I don't even want to think about this right now without a clear head.  Gonna watch Neverland or something and fall asleep. :P

Whatever,,,

So, created this blog as a sort of journal.. just as something to keep track of my latest attempt to make a video game.  I wanted to be able to look back and see my thoughts as things went along.  I've tried dozens of times to make a video game, and I think I've got the brains to do it, I just don't have the willpower, perseverance, ... whatever.

I've already started working on the game, and immediately I've fallen into one of my classic traps.  I picked something simple to do, because I knew I should pick something simple if there was any chance of me finishing it.  But.. then I immediately made it complicated.

So, I decided to make a Roguelike game.  They're fun to play, although I haven't played one in ages.  Rogue, on an actual Altair, was one of the first video games I ever played.  This was back in the... early 80s.. probably.  I dunno, I was a kid, so, hadn't really started keeping track of dates.

Interesting.. That last paragraph is a good example of how I take something seemingly simple and somehow decide it needs to be more complicated.

So yeah, decided to do a roguelike.  Simple enough.  Good points, from an actually finishing something standpoint, are: no graphics other than text, no animation, no sound, no physics, no FPS (it's turn based) so your loops can take a lot longer, and... yeah.

So then I decide, I should give it graphics, at least.  Not animated of course, that would be crazy.  I like doing pixel art, though it seems like everyone is doing that lately.  Especially with dungeon crawl type games.  I'm thinking right now of either doing 64x64 sprites in a 1280x1024 screen (grid would be 20x16) or maybe 32x32 on a 1024x768 screen (32x24 grid)

Alright, have to stop typing now.  My 6yo son is guilt tripping me into playing battleship with him.