Design update !!

Hey, I told you all that I would take my time and post something eventually. Well now is the time !

I have been working on the way my main form looks like. I had a few problems: 

First I wanted to get rid of the ugly conversation panel I have. The idea of a form popping whenever you talk to someone is crap, and having to close it again and again is a pain sometimes. I wanted to have some kind of control that would show messages for me. I have recently learned to make my own custom controls and found the idea of having a portable "messages & communication" box quite good. And here is the control and the code: 

The images speaks for themselves. The messagebar has a sub named addMSG() used to send messages to the textbox. The textbox is readonly to prevent the user disturbing the text and because the keys I use to move are the arrow keys I have made a sub to replace the caret (the little horizontal line standing where you clicked) every time a key is pressed. That way you cannot scroll through the textbox inadvertently when moving, only with the scroll bar. 

I have also begun to look into the code involved in moving around. The same 4 subs ( one for each direction) are both used to move and initiate a transition and I think this is a flawed way of getting around since the complexity is very case-by-case and thus need a lot of if's to verify stupid stuff. Due to the complexity of the overhaul this could take some time but I am still working on other parts while I'm digging around for a better solution. 

I have downloaded some tiles on a website because I don't really have *that* much time on my hand for designing .jpegs, time that could be better used somewhere else. They look good and I plan to make use of them someday to showoff a better version of the game. 

The game now looks thus: 

As you see I have made some subs to handle conversation. Now every sprite has an NPC class that is used to store conversation and other relevant stuff. I'll explain it in a later post. On this note see you all at the next post !

Blog is NOT dead.

Like I said in an earlier post. I won't be posting a lot these days. I have a shitload of work to do for school and friends to take care of, so the little time I get to program stuff is spent in fruitless attempts to re-engineer my movement system. That or creating sprites or tiles. I'm hoping to be able to post a bit more in the coming weeks, I just need some new material to blog about. I'll find something new to implement in my game and work on it.


Until then, take care !

Ha, been a week already !

Yeah no kidding, more than a week without post. You guys must be really bored. Well as you know I've been doing design lately and since I'm doing this on paper ( with a pen yes ! Like old times ) because it illustrates ideas better when you can freely draw and cross things out.


I have nearly a page of story and some pages of mechanics for the game that I'd like to implement. The story will be put in a .doc format and sent online so it can be browsed. Its NOT finished yet and I might just take another story that I started from scratch.


Beside that I'm pretty busy with other stuff, school and friends have successfully managed in keeping me away from concentrating on programming ( or sprite creation ), I'll be sure to make a couple big updates when I get a breather.


I'm also looking for books to read on subjects like A.I. , game design, story writing ( for games), graphical design ( Pixel art preferred, I don't do 3d ) and programming ( vb.net, of course ^.^ ).

Big Update is finished.

I have finally finished the overhaul I was talking about couple of days ago. And I think I managed to create some good stuff, albeit messy and hard to understand. 


Part 1: The Problem


The problem I had was the arrays. At first I wanted to be able to store them in a class, or a structure or even inside a text file that I would load. I rejected the first two, because making a class directly for a single array would be contrary to Object Oriented Programming and text files were useless since placing them outside my program was just as bad as bluntly dropping them in the middle of my main form, which was what I wanted to change. 


At first, I had arrays. My procedures would activate themselves with the arrays I needed by parameter and would fix the matrix accordingly. The problem with this approach, is that I need to know exactly what arrays to load when executing my procedures. This is chaotic because of transitions, going from map to map, as my game is not linear. I know not if the player will take a turn right or left. How can I decide what tile array to load in my functions ? This could have been hell...


Part 2  The Solution


 Instead I made a Terrain class. This class would have several parameters to hold the various arrays such as the tile and sprites arrays. As well as track which map is to its right, left, bottom or top. So instead of giving my sub several arrays. I would give him an instance of the clsTerrain class that represented a map. For example BasicRoad. I can them access its parameter inside the matrix such as BasicRoad.Spritemap or BasicRoad.TilesMap.  I would have a block of code on top that job would be to instantiate each map and give them the geographical location in relation to the other maps. 

The clsTerrain class:

So now that all our maps are there, we need to make our player able to switch maps. This is called a transition, it is triggered by stepping in a tile and pressing the according button. If you are at the top tile and you press the top arrow you get to the map that is right on top of the current one.But then we need to identify which tile is a transition, I could just leave it like if you are standing a tile in the border and you press the according button you get thrown to the next map. But then what would I do with doors and such ? I chose to make transition recognition  as early as I can. For this I had a couple of choices: I could just programmatically make them by telling him which tile to mark as such by hand. That is tedious and stupid. Instead I choose to add a third array and in there marking the transitions myself once and let him do the work. But how can a tile remember that it is a transition ? By adding a property, so I created a Tile class that inherits from picturebox and I added a couple of properties like IsTransition, a boolean value that marks a tile as one used as transition.

The clsTile class

This being done, I only need to configure the movement sub of each direction to respond if they are on a transition.  So the procedure is now ( in two parts ):

The moveRIGHT subroutine

Pretty big procedure. Theres 4 possible choices:

• You are NOT on the border and NOT on a transition tile: You walk normally
• You are are ON the border and ON a transition tile: Switch to next map
• You are ON the border and NOT on a transition: Walk as long as the direction you're going is not out of bounds
• You are NOT on the border and ON a transition: This is a "Door-transition", this will teleport you somewhere else. Not yet implemented

There IS a lot cleaner way to do it, but this is just a project to "make it work". The really big thinking process will be done in the final version of the project. Until then I just hack my way through my game and I will optimize later on. This is to keep me from falling out of morale. Since this is my first project that has a slightly bigger scale than normal ( for me ), I think that If I was to take 3 weeks to think out a single perfect function I would drop the project after 3 days. Now I can see my progress clearly, establish goals and accomplish them with relative ease, giving me the satisfaction needed to go forward.

Part 3: What's next ?

Right now, I have no idea. I'd like to take some time to create some more tiles to make rather more complex maps to bring me to the next features. The next logical course of action would be to make "Doors transitions", basically when I am walking on a door transition I get "inside" the building. Which is a map by itself. To do that I first need to create some kind of house tiles and that means a lot of work since all I did yet was some crappy grass and patches of road. And I was lucky with those, I just happened to arrive at a really good result on my 2nd try. I tried to make some mountainside tile a few days ago and it was really crappy. So lots of studies and practice incoming. I'd welcome any kind of suggestion, I understand that since this is not my final product I could just go to some website, rip some sprites and use them like some of my colleagues are doing. But what would be the point ??? I'm going to end up doing all the work anyway, might as well do it now and gloat the power of my magnificent tiles for a while. I would agree with the person that tells me that since they're nowhere near done yet that my tiles are "un-gloatable" but its a work in progress ! At least I can be happy in the fact that I don't need to steal all my shit. Anyway. I should also start thinking about the music and the game-atmosphere like the story and characters, in short the non-VB stuff. I'll be sure to keep you posted with updates. I still have a couple posts about problems that needs some explaining. I would like to explain in details how the transitions work because I think my system is pretty damn well though ( without wanting me to give myself too much credit ). 

I'm pretty happy with my progress so far. In ONE month I went from a corpse-less form with nothing at all on it, to a corpseless form with nothing at all on it BUT at least now I can make characters pop on the screen and move around. OK OK, I admit. Some people could do that in a day and do it better. I am not one of those people, I am studying in my second year. This is some pretty heavy stuff for the amount we learned in class. And I plan on making a LOT more with increasing complexity. I am talking of course about the battle system, and inventory and menus and all. I have yet to know what and how I will do this, but it will be grand I think. 

Until then ! See you on top of the next article.

Update !

Hello, I've been working a lot on the project these days. I have implemented transitions between maps ( will make a post about that piece of code soon, I'm still working on the "Un-escapable loop" post ), and I have arrived at a point where my system began to be messy and unorganized. I have began to code a massive overhaul regarding my arrays. I can't just let them sit at the top of my class. Because of my goal of having at least 30 minutes pf content, I will probably have to make a lot of individual maps. Outside maps, indoor, inside dungeons etc. And triple that because I need to add a sprites_map and a transition_map to each of them. That could mean a couple hundred of arrays just sitting there waiting to be used.

My idea is that I would make individual text files containing the maps ( single map per file or a single big file with all maps, I don't know yet. Or even an XML file on the condition that I re-read on the subject). I now have to make a class and get the I/O working well. Every time you move to the edge of the map over a transitional tile, the matrix will change its tileset and put you in place. This is particularly rough part on me and I need to read a lot of stuff and my post count will probably drop a bit. I will try to keep you all entertained ( all two of you reading my site ). even though I'm busy as hell.

Keep looking over my GitHub page, frequent updates are to be found. For those who forgot the link, check my pages.


EDIT 10:32 24/03/10 :
I have nearly finished the overhaul I was talking about. It is a MAJOR change throughout the project. If I was to explain everything I'd have enough material for 2 weeks. Prepare for some big posts later in the week or the next.

Design UPDATE !

Yes, an update already. I've been messing around with my IDE and decided to give a go to the design of the game. What I did here was to generate the grid of the game window. As you know in earlier RPG's, the world was a series of tiles aligned in a matrix pattern ( Meaning for example: a 16x16 grid, showing 256 tiles total ) and your character and anything in the game world occupied a single tile. I made a few samples to give me a better idea of what I wanted my game grid to look like.


I had a choice between placing each individual tile on the form, or programatically add them after the form loads. The advantage in adding them after the form has loaded is that your form can be easily modified. As well as giving a greater number of design tweaks. I tried both method thought, placing them manually and automatically. And here are my results:

The one on the left is the automatic, right now is manual.

I chose the colors at random just to give me an idea on the output. Not a lot of difference you might say ? Well when you look at my design form, you can see it is a lot less cluttered. 

Automatic generation yields a much cleaner form designer.

The one on the left is the auto-generated window, the one on the left is the one I added every single tile by hand ( with the help of CTRL+V of course ). You can see the absence of picture boxes on the one on the left because there is currently no tile alive yet. They have yet to be created. Also, the code for autogeneration is MUCH smaller than the manually added at start. 

Let me explain why: When placing controls on the form, even thought you cannot see the related code, some is still created. For a single picture-box, is looks like that

      Me.PictureBox195.Location = New System.Drawing.Point(288, 372)

        Me.PictureBox195.Name = "PictureBox195"

        Me.PictureBox195.Size = New System.Drawing.Size(32, 32)

        Me.PictureBox195.TabIndex = 213

        Me.PictureBox195.TabStop = False

Multiply that by 256 times, and you get quite a big file to load already at start. Meanwhile, when adding them automatically when the form loads, they are added one by one with much cleaner code thus making your source code smaller and lighter. The code I used for both forms is thus:

The first one is for the auto-generate, and the second one is manual. You can see on the second image that the only code running is the color-chooser, thats be cause there IS NO code needed on the main() procedure for showing all the picture boxes. But when you compare the first to the second, one simple method is much cleaner than 265 chunks of designer data.


All in all, auto-generation is a much better choice for the purpose of making game because the grid is not static. As we move to the edge of the screen I have to be able to change the map very quickly and efficiently .

Update on the blog and an Upcoming Project !

Blog Update

I wanted to re-assure you that my blog won't be focused EXCLUSIVELY on programming, the vast majority of my posts are going to be around that subject but I might sometime write tidbits of text about this or that.

Upcoming Project

Since the last few days, I have been looking for a project in which I could submerge myself and work on in my spare time. I am still searching but I am getting closer to having an idea in mind. I've wanted to program a game for a long time now, not a good one or anything remotely revolutionizing but something that I could do that would strengthen my grip on my programming language. I tried a messing around with a console interface but I couldn't bring myself to making anything else than a very boring text scroller without any semblance of combat and adventure. 

So from this day on, I am leaving the world of console game programming and moving on to 2D graphical game programming. I was thinking along the lines of one of these two screens:

The big panel in the middle of the second image and covering the whole window is where the game will take place. 

My idea of the game is that it is going to be a 2D top down RPG, much like Lufia or Golden Sun and the likes. I would draw the sprites, make the music and the "animations". The biggest challenge to my mind right now will be to program the engine of the game and make it as easy to re-use as possible. With my little experience in the domain I expect this to be quite a challenge.

Feel free to check my gallery of pictures related to the project here. Not much right now but I will update it as I make progress.