Let there be light!

I just got an idea. I always wanted to do something special with the game concerning light. I always planned on bringing back the time of day, complete with Pokemon that can only be found at certain times. But I want to do some special things.

First off, I want to do something like GTA: San Andreas. In that game, the clock runs fast and an entire day cycle happens over the course of an hour or something like that. I’m thinking about doing that, except having it over the course of twelve hours. So you’d have two chances a day of getting rarer Pokemon. I always thought that was a problem with the first iteration of time in the game. It actually corresponded with real time, and only the freaks who got up super early or stayed up too late could get those rare creatures. So let’s halve that and give players a chance to encounter them right in the middle of the day. And the beauty of it all is that on the computer, I can automatically align the game to the computer’s clock.

Next, I’m thinking about lighting. The lighting should change over the course of the game day, going from bright during midday, to a darkish purple at night, just like in the games. That will actually be somewhat easy to do, as I can change the color overlay over the entire screen with one call, and make that change values based on time.

Lastly, and my favorite idea, is that of actual lights. With OpenGL lights are fairly easy to implement (probably easy for an experienced programmer but not me). So, when it’s time for the streetlights to come on, I can actually turn on the lights stored in tile objects. These can be streetlights that shine toward the map, or lights in windows that shine toward the screen.

Now, I have not played the newer, pseudo3D (or are they just 3D now?) games. I’d imagine that they use some sort of OpenGL implementation (because hell, even phones can pull them off now!) so their games probably use real light sources now. I’m going to go look that up. Adios.

So here we go again

I swore I’d never do another recode from scratch again. I swore it up and down and made a deal with the devil that involved the blood of a virgin prostitute. Do you have any idea how hard it was to find a virgin prostitute? And yet now I am in the midst of a complete game recode. What? Why? How?

Who? What? When? Where? These questions and much, much less will be answered in the following smattering of loosely organized letters.

How much of a recode is this? It’s a total one. I created a new program and copied pretty much nothing over. All of the code is handwritten, even if it does some of the same stuff.

Why am I doing this? Simple. I am recoding the game because the engine has become too complex due to hacky code. I’m starting from scratch to put some major thought into what I write. When I am forced to used hacky code to mock up a proof of concept, I immediately look to see how I can optimize it.

What have I gotten done so far? Well I’ve only been working on this a few days but I’ve gotten plenty done. I’ve created a new map and tile concept which will load serialized maps, including a default serialized map. Basically everything I talked about in my post about the One Map concept has been implemented.

So I have a scrolling map now, which scrolls smoothly in a very Pokemon-like fashion. The beautiful thing about it is that I have done it in less code. Significantly less code. Hell, I’m not even sure how. All the concepts I wanted to implement in the last iteration of the engine, but couldn’t figure out (forcing me to use long, hacky code), I finally figured out. Things look great now and the functionality is identical.

The map now uses a VBO to render, bringing me up to the forefront of OpenGL rendering specification. I was having a problem at first that almost made me reconsider the recode. I was passing the vertex array, and then passing the four texture arrays. Things weren’t going so well with that. Then I just passed the same vertex array with it all four times and BAM it works perfectly. Honestly I don’t think there’s any speed increase for my tiny game, but at least I’m standards compliant now.

I implemented my mappable keys using an EnumMap. Again, it works perfectly and hell it even worked on the first try! I’ll have to figure out an in-game method of changing them.

Something I’m immensely proud of is something I did just today. I was messing around with the TextRenderer class. I had used it before because it was the easiest way to print text to the screen in an OpenGL context. I abandoned it because I could not get it to work in the way I wanted.

I needed it to take an unbroken string and split it into pieces that could be printed a certain width across the screen, in chunks of one or two rows. So you know, just like in the game. I couldn’t figure out at the time how to calculate the width of the string printed, or a good way to split it. So I resorted to loading my own set of characters and using them as textures in the complex manner I posted about earlier.

Today I decided to dick around with the built in functions again. This time it clicked in my head that I should use the draw3d, not draw method. I never read the javadocs the first time, or this would have been clear. Whereas draw stacks on some new camera modes in order to draw the text, making comparisons difficult, draw3d simply uses the existing GL context to render the font. From there I could find the width of the string representing the row of text by getting its bounds and multiplying the width by the same scale used in the printing of the text. The result is a normalized width that matches the coordinate system. That means that if the width of the string is 1.0, it is as wide as a single tile in the orthographic projection system I use. Using this new revelation, I can build rows in much the same way as I did when I used textures. Add to the first row until either the end of the string or the desired width is reached. Then do the same for the next row. When that’s done wait for input to continue. The beauty is that the rows are set to empty strings by default so they can automatically be printed and nothing will pop up. This means that they can keep their string chunks as long as they have to, so I don’t have to use offsets to populate row one while adding to row two. Row one keeps its data until it is deleted.

That sounded overly technical and complicated. Let’s just say that, if you just skipped or skimmed that paragraph, I got the text to work in a much simpler way. Just like how my brain clicked on how VBOs work a few weeks ago, today my brain clicked on the TextRenderer.

Currently I am working on getting the OGM to work. The OGM is the Out of Game Menu. Basically it is the state the game starts with, with the intro video and main menu where you can start a new game, continue and old one, or change the settings. I’m skipping the intro for the moment to work on the menus. Printing the text of the menu options is no longer even the slightest of problems. I have my menu manager set up and just need to have it select the right things to display. This includes a pointer feature again, which is just a little triangle printed at the right coordinates. It will need its own vertex and color array. Borders will be an interesting problem. I’ll skip them for now and just consider them visual trim to be saved for later.

What do I have planned for later? What do I have planned for tomorrow? I don’t even know. There’s certainly some commenting and optimization to do. The poor little personal wiki that was supposed to help me understand my own code in depth later has gone unnoticed. Maybe I could get some of that done.

Whoa

That’s my Neo impression. Anyway, I have a hell of a post coming at some point soon. I have done a LOT with the game’s recode.

New format

I’m announcing a major new format change. I feel that this blog is causing a problem, in that it’s giving me a chance to goof off and not get any programming done. I make new concepts more concrete in my head, sure, and when I do code I’ll incorporate those changes. I haven’t done any actual programming since before I started the blog though. That needs to change.

I downloaded wiki software, and will be using it to act as an extended commenting system. There are also pages to put down my thoughts, as well as sections for art and storyline.

What I want to do is blog about the game as I program it. So, first comes the initial game loop and setting up the OpenGL context. Then I’ll blog about it, probably including a bit of code and possibly some diagrams.

Let’s see how that works.

Proper post coming soon

Times have been turbulent here at home, and at work. Things at both locations have been taking up my time. I’ve been working on a draft, one that you can see in my schedule post as being about doors and transportation. It’s a very, very long post that will have lots of hand drawn pictures (diagrams mostly), and code taken from the game. I can’t say for sure when it will be ready, with luck tonight.

I’ll try to keep the drunk posts to a minimum, but this is a programming blog overlaid on a personal one. I try to keep the technical writing light, with a bit of humor. Kind of like a programming book you’d find in a bookstore. Those can be pretty funny sometimes.

Hope you like the new avatar. Couldn’t find an easy way to fit it into the actual design of the site. I’d love to program my own blog, and god knows I have the know-how to do most of it. But there are a lot of services here that I’ve never had any experience with, and it’s best not to reinvent the wheel in this case.

EDIT - I have installed a personal wiki on my computer. It is my hope that I will use this to organize my thoughts on the game in one place (rather than bunches of paper), and help provide further insight on my code than a few lines of commenting can. Not to say I won’t comment my code, but this will explain it more thoroughly and help me trace inter-file/package threads of code.

Working on a new logo

I actually have the base image I want to use. The problem is shoehorning it into this blog’s template. I’m still working on a way to get that done.

The hats, they are everywhere!

It’s time to put aside all the hardcore thinking and puzzling I’ve been doing for this blog lately, and put up something as silly as it is relevant and informative. So I’ve written a few items down on paper that will be incorporated in my game. This list is not final by any means, and I have a lot more to add.

Something you’ll find as a standard feature in any computer game is the ability to change the default key bindings. That is, you can change the controls. Now, you can’t do this on a Gameboy, because there are only just enough buttons to do what you need. And it would be stupid to reassign them. Since my game is meant for the computer, I’ll have to implement key mapping.  I’m a big fan of Notch, the guy who created Minecraft, and I have watched his live stream (or at least the recorded videos), so I have some ideas on how to easily do this. Not that it would be too difficult to implement the system on my own. It should be as simple as using a map to correlate a key to an action. The game will let you change the values of the specified action. Just like in all games today.

Another feature new to the Pokemon games is the concept of a HUD. I won’t get this too far because I’ve already written a post about it, and have more posts to write about it in the future. Suffice it to say that there’s information I feel should always be present on the screen, and the increased size and resolution of a computer screen should allow me to do that without spoiling the view of the map.

Graphics is something that by the nature of games I will not be ‘adding’. I will be ‘adding to’ them, however. I am no artistic man. I have very little talent in that area, especially when it comes to pixel art. I will probably find a friend who is much more talented to redo the sprites, at a higher resolution than they are in any of the games. I’m sorry to say that this game will not be three dimensional in any way, but at least I can provide sprites that are several times the size of the ones in the games.

Along with the improved graphics, I want to add little touches of my own, like shadows. I’ve seen fan-made games that included shadows, and they looked fantastic. Especially in one level that seemed to have taken place in a forest, with the camera below the canopy, and tree shadows playing over the ground. I also want to change the way day times are handled. Now, I have not played any of the games on the DS, and I don’t know how they handle the transition to different times. I remember that way back in Crystal, the lighting just switched completely. I never liked that, and want to make my transitions a little more gradual. Fast but gradual. Think Grand Theft Auto, where an hour represents a whole day (or something to that effect). I hope the end result is fantastic, with shadows (moving shadows?), street lights, and transitions in lighting around the clock.

Bigger is better. Don’t let anyone ever tell you otherwise. In my game’s case, I’m wondering if I want to have larger towns. Little cities, perhaps. The towns in the games always have little distractions, little things that might amuse you if you go looking for them. There are also little diversions, side quests and such. But for the most part the towns only have things that relate to the game, to furthering your mission toward the Elite Four. I want to change this. I want the towns bigger (not so big it’s a challenge walking through them), I want more NPCs milling about, and I want the buildings to be a slight bit truer to their real size. And I want them all to be enterable. Maybe some might be locked, because real people lock their damn doors. But I want ever single building to be a separate exploration. I want the game to have near infinite replayability.

Mods. I’m not really sure about this one. I don’t even know what people would want to mod in. Their own Pokemon? I don’t know. I feel like this could open Pandora’s Box and allow for abuse of the game. I’m just throwing it in here because it is definitely an idea.

The story mode never lasts long enough. Crystal did a decent job of this, by tacking on the original Kanto region after you’ve played through the first half of the game. But did anyone else catch that there wasn’t as much effort put into the second half of the game? The objectives weren’t as complex and there wasn’t as much to do. It felt sparse. I want a single storyline that’s just as long as Crystal. Something that will take players a while to get through, but not so long that they feel the end isn’t in sight. I don’t know how I will make this happen, as I have not even given a single thought toward the story. But I’m hopeful the end result will match what I want.

I want the NPCs to be a bit more complicated. I mentioned that in my NPC two part post a few days ago. I want them to have branching conversation, and be able to move across maps. I might implement a phone system, where you can call them up and get information or challenge them to new battles. The trainers will have Pokemon that level up as the game progresses, although I’m not sure how to handle that either. I keep thinking up new ways to make the NPCs better, and I’ll get into more detail in my next NPC post.

Lastly but not leastly: hats. Hats everywhere. Creative consultant Storm Surge has been very adamant about the hats. It started out as a joke, but will become a very observable part of the game. Just my attempt at adding a little childish humor. You can pick up hats or receive them as gifts, and store them. Then you can whip them out and wear them whenever you want! I promise there will be much more, but appropriately contained child humor in the game.

Well that’s that for now. Next up is transportation across the map. Until that gets posted, adios.

Fumbling around with the code

The blog looks slightly different now. I hope I made improvements, rather than the other way around. I’m still looking for more things to improve here.

My next post is written. As usual I will be drawing doodles to scan in and add. I just need to do that and then it can be posted.

The schedule

After I wrote my thoughts in my last post, I jotted down a few topics for future posts. I just wrote down another one, bringing the current queue to four future posts. I can’t see with certainty how quickly or by what schedule they’ll come, but I’ll get them all out in short order, hopefully within a week.

In order:

  • New innovation ideas that will set my version of Pokemon apart.
  • Getting somewhere - Handling doors and other transportation across the map.
  • Shallow pockets - Should I change the way items are stored?
  • NPC advanced - Time to figure out the complete NPC object.

So those are the next few posts. Complete will silly doodles.

Those pesky little Phiks Part two

Ah, welcome to part two of the exciting NPC series! In my last post I touched briefly upon some of the problems with my current NPC solution. My code is stringy, hacky, and just damned ugly. But I think I’ve come up with a better way of controlling them. At least most of the NPC aspects, anyway.

In a pinch, here’s the solution to my problems:

Of course you can click the picture to see it full sized. In simple words, here’s what I came up with. When you start a new game, all the Phiks will be read in from the default file into a single array. Of course if you are resuming a saved game they will already be in a file, serialized. After they’re loaded, the engine iterates through the array, and gathers the coordinates of every NPC, then inserts their index into the correct Tile object. There will be no more putting them in a separate array. Straight into the very fabric of the game for simplicity and ease of access.

When the map manager runs through the near tiles (the ones drawn onscreen and the one tile buffer in all directions which is drawn offscreen), it will pass on its list of NPCs to the NPC manager, which stores them in a list. This list represents the dynamic characters, that is the ones that should be animated. So instead of drawing everyone in the map (which could be hundreds), only the few that are nearby are drawn.

This also works well for letting NPCs cross map boundaries. I feel like I should let the little guys run free. If one of them wants to go to route 45 from route 44, who am I to say they can’t? As long as they follow the same rules as the player, and don’t try to zip through rocks or trees, I’ll let them travel. They just won’t be able to go into or out of buildings unless it’s part of a cut scene. For some of them, I’ll come up with a way to keep them still or follow a path. But for most they’ll be running free.

Well, I think that’s a good solution I came up with. Obviously, I haven’t dreamed up the most complete NPC organization here. I’m not good at planning, especially when it comes to code. I’m much better at being the kind of guy who just opens up his IDE, rolls up his sleeves, and gets to work. I’ll get better at planning, I hope, because it seems like the bulk of the NPC code will be better written if I have that image as a template.

I’m not quite sure what my next post will concern. I’ll get a mini-post up once I figure it out. Until then, adios.

1 2