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 ^.^ ).
This is a blog to talk about programming. I am a student in IT currently working with the C# language.
Showing posts with label RPG. Show all posts
Showing posts with label RPG. Show all posts
Thursday, April 8, 2010
Wednesday, March 3, 2010
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 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 .
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 = FalseMultiply 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 .
Subscribe to:
Posts (Atom)

