Further investigation yield the following:
Just thought of a new idea when I woke up this morning. Actually it's not new, but just an idea that I can incorporate some of the classic shoot-them-up (Gradius, 1942) gameplay into the mix. The current design is to let the player have total control on where to go, and if the player don't move, the robot will stay stationary. However within a level I could include strips of area, in which the robot has to constantly move in 1 direction as if in a "current." In this zone the gameplay will be like Gradius or 1942, except that the player can still decide to shoot in any direction they want. In another words, when the player enter the zone, the gameplay change to Gradius, where the player has to dodge bullets and obstacles while moving (scrolling) through the area automatically. When the player exits the zone, the gameplay returns to normal.
So what's the point and fun factor of this? I think those shoot-them-up has some different challenge factor like forcing the player to be "on a track," and limiting player dodging area etc. On the visual side, it can give the player a sense of speed and "rush." It has a very different tempo from games like Contra. Yet their game mechanisms have many similarities. So if I can put them together, it might be nice.
Again though I can't be too overly ambitious. I think I should finish the game first then add in this feature later. Now...where did I get this inspiration...I think it might come from Prince of Persia, which I played recently.
The original model and the entity direction (rotation) has been setup. Also, some process such as entity transformation matrices calculation has been moved to entity update function. The model exportation actually did not cause any trouble. I just use DirectX 8.0 export in milkshape 3D and it works...except a little glitch seen here, which I don't yet have a clear idea why:
The next thing I need to do is to add in animation control and setup a good control scheme or system. The system I used previously, a state system, might still be good, but I have to do a review about it and see if I should try another way, use the old way or improve on the old way. Another thing I should implement probably is a smooth rotation for the entity.
Yet I encountered another weird problem. When I added the second mesh, it does not show up. I thought it has something to with the world matrix, but after I reset the matrix with identity matrix, it does not show up neither.
Problems after problems, I wonder when will this ever end.
UPDATE: LOL, Cannot believe this. I left a device Clear (backbuffer clearing) call in the frame rendering function. That's why every time an mesh entity is drawn, the backbuffer is cleared, which cause the above problem. That was kind of stupid...got to watch out for this type of mistakes. In any case, it's always enjoyable to solve problems and see things finally working:
Hmm...so what's next?
Scaling has been done. I was able to do so by buffering the transformation matrix into the existing vertices's transformation.
Now I think of it, I should be able to use MultiplyTransform after SetTransform instead of multiply it directly. Doing that way might make the code simpler, although...it's not that ugly now anyway.
My heater broke on the weekend, and it looks like the cool temperature froze my brain as well |o|. As such I didn't get much done except doing some clean up.
Seriously though it makes me realize an "acceptable" working environment is important to program efficiently. I was thinking of the world "comfortable" instead of "acceptable" but I realize "comfortable" could mean a place where you can just get sleepy as well. I wonder...could a comfortable place makes one sleepy or staying sharp depending on the desire of the individual, or are there 2 types of comfortable places, one that makes you sleepy, and the other makes you stay sharp?
The mesh functions and data structures have been integrated into EntityMesh class. One function GenerateSkinnedMesh gave me particular trouble, because I wasn't sure where to put that function. Originally I thought to put it in EntityMesh, but CAllocateHierarchy is also using it. So I attempted to use static or singleton etc, but realize those don't seem to work. Eventually I realize that only updateSkinningMethod in EntityMesh is using it, and this function I might not need it anyway. So I just comment it out and put GenearteSkinnedMesh in CAllocateHierarchy class.
Now I look at it once again, I realize I should be able to put updateSkinningMethod in CAllocateHiearchy class, but...maybe I shouldn't do that. Nevertheless I think I will promote CAllocateHierarchy object from local function object to class object to enable the updateSkinningMethod for the future. It makes sense to do it that way I think.
Later I will clean stuff up and try to have 2 entities.
Hmm...Changed the look of the blog. Not sure if it actually looks better though. Just for the record, this is what it looks like before:
Ha...can't tell which way I like better...but whatever, some experimentation is always fun.
Update: Wow, I just realize with this new setup I can actually put bigger google ads. And for some reason the bigger version seems to show graphics ads more often...very interesting. |o|
Finally I got the mesh to be drawn and animated. Actually I didn't have to do much but pass the elapsed time to move frame function. But still quite some work needs to be done...:
I am able now to render the mesh. I still haven't setup the animation but I imagine it will be easier since now I have the mesh shows up correctly. Well, almost correctly. For some reason, on my game application, the mesh appears to have small glitch, but on my editor side there is no such thing (left from game application, right from editor):
As can be seen, on the application side some polygons are drawn in black or they might be missing. I suspect most likely it's due to CEGUI setup again, or it could be some unknown minor setup differences between the application and the editor. I will have to investigate this more.
The problem before was I didn't actually call the update bone matrix function, which I thought was called in rendering function. Now the problem is I have to update the animation, which I don't have a clear idea how yet.
Although I didn't spend a lot of time with it, it's a good progress now that I have gotten an animated mesh to show up. Again I should spend more time with it to speed up the development. Definitely in the up coming holiday I will do that. Sometimes though it's not just the time, but the energy. During the weekend I have time but sometimes I just find myself exhausted already. But again it's probably just human natural laziness kicks in.
Finally, some mesh shows up on screen, but what is this mess |o|:
I suspect it's probably because the time frame is wrong or the bones are not setup properly. I guess the next step would be to debug this problem and make sure the animation is working. Also I have to scale down the mesh (although I am not sure why it should be so big). After those I can finally put the function into objects and see if I can generate multiple mesh entities.
I recently bought and play Valkyria Chronicles. I haven't finished the whole thing but so far so good. I think it is a very nice and unique TBS/Actoin/RPG (or maybe it should be categorized as another genre all by itself) game. The visual and art of the game resemble water color arts of course, which is also very unique (I don't think any other games ever done it before). Also the story telling, the presentation and the imaginary world reminds me of Japanese anime, especially the older one directed by Hayao Miyazaki such as Nausicaä of the Valley of the Wind, Porco Rosso and Laputa: Castle in the Sky.
The idea on the combat system is actually not totally new. In fact, another game I played recently, Eternal Sonata, has similar combat system. They are not the same, and the resulting game play works out quite differently, but the concept of taking turn, move 1 unit at a time to attack enemy or get into position, while the other unit stands by or taking defensive measure (blocking in the case of Eternal Sonata, dodging or firing back in the case of Valkyria Chronicles), is similar. Even the Action Point (AP) system has been used quite often in other TBS including X-Com. Also in X-Com the units will take defensive measure (shooting at enemy) as well, but only if they have extra AP left. There are a lot of difference in camera, controls, AP consumption,...etc, which in accumulation make the resulting game play very different, even though the general concept is similar.
Which brings me to another thing I noticed: is Valkyria Chronicles what Dreamland Chronicles: Freedom Ridge could have been like? For those who don't know about DC: FR, here are some link containing some interesting information on this canceled project from the developer of X-Com:
I was able to re-setup the skinned mesh function and get it to compile. Now what I should do is probably trying to call the drawing and update functions, making sure the model paths etc are correct, and see if the mesh shows up at all.
Judging by the progress it looks like I am going at snail pace 0. Although recently I am a bit busy on other things, I really need to spend more time on this.
After trying out the indexed rendering the mesh still doesn't show up. I also tried changing the camera direction, distance and different model, but still no showing. I think I am completely lost here.
I will try a totally different approach later. Here is new approach: use the code from DirectX example directly within in the project, with only small modification. I think it's possible. All I have to do is to create the hierarchy and the container etc, save those pointer in MeshEntity, and just call the functions from the example to draw and update the mesh. The only thing I might have to watch out for is the loading file directory etc.
Unfortunately I am still struggling with the skinned mesh. I wish I have more energy and time to spend on it. But it's not without progress. I tried to use the model from DirectX example, and it give me skin info, which shows that there is something wrong with the model exported from Milkshape 3D. I think I have to check out the Milkshape 3D website to see if they have new plug-ins etc for exporting .X model with skin info etc. But even after the experiment nothing shows up on screen, although the debugger indicates all the rendering step has been gone through...perhaps it's the light setting or the material that cause the problem. Further investigation is needed.
Another problem I noticed before but didn't mention is that for some reason I need to set material, even for Sprite...otherwise nothing shows up. I don't fully understand it yet but I will just leave this here in case I encounter similar problem in the future.
UPDATE: After some investigation, I decide to try rendering the model without using HLSL. Although the example from DirectX provides the HLSL usage example, I can't seem to get it to work, and I don't have enough knowledge about it to debug it I think. So I will skip that for now and try to get the model to show up and animated properly. Later I should research on HLSL and try to put the shader in.
This blog is about the ending of Fallout 3...I won't go into describing it etc but whoever doesn't want to know anything about it should stop reading. (but who the heck is reading this blog except me anyway, ha...)
I would say the ending, especially the fights before the ending, are very well done and climatic. The tension are built and you get to use all the high tech weapons and armor the game can offer. Seeing the events unfold with large explosion and bodies flying all over the place or burnt to chock is quite satisfying. (It's kind of weird in a way because I imagine in real life people will feel afraid and gross out but for some reason in the game it looks good).
Video game violence aside, it's also satisfying to charge into enemy strong hold with the main character's buddy and the Brotherhood of Steel to accomplish the objective. The ending is faster pace than the rest of the game which is refreshing. I wish they could have more of these type of combat mission in the game. Another thing they could have done better is to have more involvement from the player in the climatic battle. Because in the final battle most of the time I just spend following and watching. They could have given me more stuff to shoot at. But still overall it's a very good experience.
Although I would say the story's final ending doesn't give me strong enough "satisfying" feeling like some of other games. For example Metal Gear Solid 4 and Final Fantasy 7's ending seems to have more "punch" to me. The feeling is hard to describe...perhaps the best words are it could have been more "powerful" or "emotional." Still the ending sequence are quite nice and the game does have an interesting theme.
Overall the game is nicely done.
Recently I didn't spend enough time on the game development to have any major progress. (played too much Fallout 3 I gather O_O). But still some progress has been made.
I have setup the skinned mesh class but so far it still doesn't working properly. Right now my investigation showed me that I am missing skin info (Null point as one of the parameter). I am not totally sure what the skin info is even. I think I should first investigate that. Then if I can't get it to work might want to try another drawing method for now and see what happens.
I did find a small bug about material...although I have no idea why it's a problem anyway, because I don't think I even setup lighting...
Everything becomes unnecessarily complicated when one is not familiar or doesn't have full understanding of the tool, in this case DirectX. Hopefully I will be able to get more familiar with it.
Just got Fallout 3 and play a little bit yesterday. Most of the people and game critics gave it high score and high praise...but for some reason I find some of its features annoying, and they stand out quite a bit. I don't know why most people don't have my kind of problems with this type of game (Fallout 3, Oblivion etc). I actually played Oblivion before as well, and don't like it that much. But I thought I gave Fallout 3 another try because it just looks so good. It's actually better than Oblivion so far but still I find the following things annoying. Most people I imagine will disagree because I think they are actually personal preferences in which you can't have one way and the other at the same time.
1. No immediate access to mini-map: to see the mini-map, you have to bring up Pip-Boy. But couldn't they just put the map on the t0p-right hand corner? Yea, it's not as real or authentic, but it seems more convenient to me. Because I find it quite disorienting especially when I am in a new area.
2. NPC walk too far away and too often: I notice NPC just go around doing their business etc. Most of them stick in certain area but still there are time I wonder...couldn't they just make all of them sit tight in one place? Yea, again the realism will suffer, but it's more convenient if I can just see whom I want to speak with at exact location.
3. 3rd Person view gameplay looks bad: or at least it doesn't play as well as 1st person view. The animation is bad and the aiming is kind of weird I think. That bothers me a bit because I like to see my character most of the time, and 1st person view makes me dizzy sometimes.
4. Health Recover difficult: Again it's a realism/convenience trade-off. Yea, I imagine in real wasteland it's tough to get a good rest or eat some good food. But come on...why gives us a hard time just to recover some health. I can't even find a bed in the first town right away that I can sleep in, and the doc is just way too expensive. Other ways come with side effect like radiation...it's just a lot of headache in my opinion.
Maybe I just like simpler, dumber and faster pace game like Diablo 2...yea, most likely that's the case.
UPDATE: Although I still find those things annoying, the game become more enjoyable once I got a hang of it. The VATS, especially, is a new feature that I enjoy. Also the game let you save any time so it's good for "experimenting," and being able to stop playing at any moment is good for a "busy" guy like me, ha.
As I tried to setup the skinned mesh and skeleton animations I researched on the subject and found many interesting information regarding the utilities provided by directX and D3DX. I am pretty sure it will make my life easier and help my implementation of the game. Still, it's a lot of work to implement and make everything work properly. But I am pretty sure now it was a good idea to switch to DirectX because it seems to be more game oriented. OpenGL also works well but it doesn't seem to provide easy and searchable access to game related technologies. Since I don't have a lot of time and budget, DirectX seems to be a better choice indeed. At least I am also learning new stuff as I go along.
Some implementation has been done during the weekend:
1. FPS display
2. CEGUI events setup
3. Camera follows
Right now I am in the process of implementing skinned mesh for the robot.
Finally solved the problem. I have to download the CEGUI code and find out the render state it's setting so I can set them back. Apparently CEGUI called the following on directX device:
SetSamplerState( 0, D3DSAMP_ADDRESSU, D3DTADDRESS_CLAMP);
SetSamplerState( 0, D3DSAMP_ADDRESSV, D3DTADDRESS_CLAMP);
For some reason the clamp setting cause the sprite to use only the first pixel of the texture image. This is really weird. The reason behind it is still unknown to me. But now I just set them back to D3DTADDRESS_WRAP and that solves the problem. It proves that while these type of libraries are supposed to be black box, during debugging, it might be worth it to look into their code. (Yea, that's not supposed to happen but nothing in this world is perfect).
While at solving this problem, I also found some interesting directX classes such as LPDIRECT3DSTATEBLOCK9 and LPD3DXMATRIXSTACK, which is good.
An interesting link is also found: http://www.codesampler.com/dx9src/dx9src_2.htm
I have made some more progress in setting up the CEGUI. Right now I am able to use scheme to show up a window, and tried out CEGUI's utilities.
But now I encounter a very weird problem, which is still under investigation. It appears that after drawing CEGUI windows, my texture coordinate of sprite is messed up. It's kind of wierd because the model's texture is still correct. I think CEGUI must have change something in the directX device.
I think I might have encounter similar problem before, but not sure. In any case, further investigation is required.
Now I got the CEGUI initialization setup, I attempt to load the image set. But then I started to get some really weird errors. The debugger did not help because it just shows some weird location and some exception that just does not make any sense. The CEGUI message dump in CEGUI.txt did n0t help neither because it just ends right when it attempts to load the image set.
Eventually I get to see this BLOCK_TYPE_IS_VALID assertion failure, which leads me to this link: http://www.zeroc.com/faq/windowsLibraryMixup.html...it's not related to my application, but basically the problem is caused by building application in debug mode and linking it with release mode libraries...yea, because I see all these debug information not found warning, I thought I can just use the release libraries instead of dubug libraries...
Yea, very dumb, but that's another interesting information. Now I am back into the "normal" situation, and trying to solve the usual image file not found problem...ha.
After all the trouble, I finally found out the cause of the exception...basically I can't use any CLR compilation in any of my projects with CEGUI library. I might be able to do it if I compile CEGUI from its source code, but I think I won't bother to try that. For now, I will just have 2 compile setting, 1 for the game application, the other for the editor. In editor, it will use CLR and not using CEGUI, and in the application, the reverse will be set. That should solve the problem finally.
But man, I should have thought of this earlier.
Another thing is...it seems CEGUI changes the renderer states after it renders. Hm...shouldn't it restore the states instead of me trying do it myself? Yep...looks like nothing is perfect in this world.
It now becomes obvious to me that programming is a tough job. Actually I realized it before already but then I thought it would become easier. But now although I have learned a lot during the past few years, I still encounter problems which I just have no answer of.
For example, now I have setup the basic robot model and WASD control, I encounter a weird problem. Actually I have no idea if it's a problem at all. But it just looks to me the animation stagger a little every few 0.1 second. I have set things up, including the timer, the same as the previous project, so why do I see this thing which I have never seen before? I have no clue what it is.
So next I thought it would be nice to setup the frame rate display to check if it's just the lower frame rate in Debug mode that's causing the problem. I thought I would setup CEGUI first because I always wanted to try library, and I am too lazy to setup my own GUI library again when someone else already did a similar thing. And ha...after I set it up all the problems starts to pop up and burying me alive. First of all there seem to be a incompatible issues between CEGUI and Windows Form (or CLR), then after I setup another project using Win32 project, it compiles but has a StackOverflow problem...which I have absolutely no clue how it occurs.
Eventually I will solve the problem most likely. But I just realize once again how tough software development can be even if I have certain amount experience in it...no wonder people usually underestimate time required during development, because it looks straight forward but then problems big and small just keep poping up. I wonder if most programmers in this world have similar experience.
And here is how the game looks now. No proper lighting has been set yet, only color value is used. I think this time I should also try Cel shading...it might be a cheap way to make things look good (I highly doubt it but it's worth a try)
I have setup the basic tile system. The tile image selection algorithm has not been implemented yet, but it's more cosmetic and therefore can be implemented later.
I will do it step by step. First I will try to export the model to X file used by directX, then make it show up on screen. Next I will try to animate it.
I invented 3DLTS approximately 1.5 years ago. Originally I got most of the game to work but the stage just looks blend, and I was looking for ways to make interesting stage or maze without too much work on using 3D modellers. I was hoping to have an easy to edit systems which I can use to create a lot of different stages without too much efforts in creating art assets. It was a great idea at first I think, but the system proves to be complicated and hard to implement. In the end I get it to work, but it's still difficult to manage, create its art assets and it's hard to debug. Various improvement has been made to simplify the process. But during development, not much consideration has been given to the editor. So when an editor is required, it creates further complications. Although most of the difficulties have been overcome, it's not a system that works perfectly. Other unforeseen complexities effecting the game play etc also occurs. In the end it's a system that cost more than it's worth.
So yea, the system works and looks nice, but after some thoughts I think I still made the right decision to abandon it for now and to create a simpler version of it first. Perhaps later my other game ideas can use it. But first I have to make a simpler version of it to work well, before I can make a more complex version of it.
Keeping it simple is still the key, especially for this no budget project.
Currently I am setting things up in GameLogic and StageMap classes so I can have the tiles entity shows up according to the specified XML file.
It brings me to the design issues with the data structure storing the tiles. There are several possibilities I can think of currently:
Here is an image of the prototype setup. Some of the game classes etc has been set, but this is just a test scene using Microsoft Direct X example and using D3DXSprite.
This time around when I design the program etc I think I will also take into account the editor at the same time. It might make things easier. Maybe even develop them concurrently. Still, I have to remember the principle this time: keep things simple.
Here is the design of the robot control after some thought:
The idea will be the same as the previous OMA. IE. The robot's upper body will be rotating and can fire in all 360 degrees. However, this time the robot will be view in complete side way (no tilting). So, at the same time the body is rotating, the arm (and the body will partial tilt as well) will tilt to aim 360 degree with Z axis. IE. the body will rotate with Y axis at the same time the arm will rotate with Z axis, while the view will be complete side way, looking down the Z axis. Ex, arm tilt 45 degree, body rotate 45 degree (counter clock wise). The rough picture above will illustrate the concept.
This way, the mechanism of shooting in all direction will be maintained, while the style of the game is good as well. To implement this, the most likely method I thought of now is to use 3D editor, to do a complete arm direction animation, with key frame at 0, 45, 90, 45, 0, -45, -90, -45 and back to 0 degree. Setting the frame between this animation as 360, I should be able to use each frame according to the direction the player is aiming. The rotation of the body will be the same as the previous OMA.
Another thing is the boomerang throwing animation. It poses another problem. But I think if I tilt the upper body a little, and making the animation of the throw a vertical movement (arm raise then goes downward to throw), I can get away with it. (It will look like the robot is throwing it upward or downward etc). Another way is to make just 1 set of throwing animation, but tilt the whole robot robot to face the direction it's throwing (ie if it's throw down, the whole robot will face down). This might work as well. But these are aesthetic concerns which won't impact the game play.
Here is the design and reason behind the decisions. I should stick to this and keep it simple. The past project experience has shown me that sometimes I can have a new idea, or few feature I want to add in. At first it's simple. But then it becomes difficult with later implementation of the game. (Example: multiple layers in a stage, with stairs, causing difficulties with AI path finding, 3D model creation cost, large code to setup the tiles in flexible ways, complexity in editors,...etc). This time I will keep it simple. If a new feature needs to be added, it should be just cosmetic. The reasons will also be given to keep remind myself of my thought process so I won't let my mind wonder and blow the later design out of proportion. This design in a sense are both guidelines and restrictions, that I should abide by myself to keep the project in check.
1. Single layer, with background: a stage consist of a single layer of obstacle course or maze, which the player has to navigate through. Some background can be put in for looks. Of course, if more "background/foreground" cosmetic layer is required, they can be added. But the principle of player and AI playing on just 1 layer should not be changed.
Reasons: Multiple layers might not be that hard to implement, but when you have multiple layered (floors) stage, other implementation also become difficult. For example, you will need to worry if those thing obstruct the player's view. You will need to worry about the AI path finding more. You will need to worry about extra axis. Plus a bunch of cosmetic questions like how to make the stage look nice etc. Camera also a big issue. So to put all these concerns aside, just stick with single layer.
2. Tiles should be 2D: The tile sets etc should be in 2D. No 3D models should be involved.
Reasons: While the 3DLTS was flexible, and I believe it could also create some amazing stage, the cost of it is too high. And like one of those designer in Blizzard said, randomness cost a lot (not exact words but I remember that's what he meant). With 3DLTS, the stage needs some "randomness" to look interesting. To create with randomness the system also needs to be flexible, and all these cost time and effort exponentially, in my opinion.
3. Animated Unit in 3D, Static Unit could be in 2D: Both 3D and 2D unit should work. Although it's also possible to have 3D model posing as 2D (flat 3D model). Although ideally all units should be in 3D, allowing 2D units to be placed can cut down the cost.
4. General Control: The game will be a side-scroll action shooter. The player control a robot, moving freely in X and Y direction (no Z direction). There will be obstacle (tiles), which the player can not go past by. The player control movement of robot using WASD, control the direction of the shooting and the firing using the mouse. The view will be from the side (directly). The direction should be 360 degrees. If 360 degrees is not possible (due to animation etc), it should be proximately 45 degree up and 45 degree down for both the left and right hand side.
Alt 1: it might also be possible to let the player shoot in 8 different directon, but no more. This way, the animation is easier. Plus it might simplified the control a bit.
Those are the guidelines for now. More might be added in later. Simplicity should be a major concern of these project. Complex design or design that require big change should be disregarded. Design that can simplified the development should be implemented.
Ha, I have decided to start from scratch. The current project is just too troublesome to handle. Plus I want to learn more about direct x.
This time I will keep things as simple as possible. And with the previous experiment, I should be able to do things in better way. Of course some codes and data could be reused from previous project, but I should do a lot of things in simpler way. Keep it to the essential stuff.
Currently I am stuck with an access violation exception running the Level editor. The cause is still unknown. I also tried to compile the program in debug mode but for some reason it has problems with dll etc. Makes me wonder...why do they always make things so complicated.
I have setup the new Windows Form project as the new editor executable, and the original LevelEditor project as a library. Now I think I have to do is to transfer the control from the LevelEditor old Windows App GUI to the new one, which I don't think would cause too much trouble.
With Windows Form I can have much more features without too much trouble. For example, I can setup the light color using the color selection dialog. I think this is going to work out great. Now if only I could concentrate and find more time for this crap...
I have been thinking about this for a while. I realized that the graphics doesn't look that sharp on the game, especially the model, colors and lighting doesn't seem right. Here is some notes that I think might help:
There might be other stuff I can do but these are what I can think of right now.
I haven't played the game Space Siege, and from the reviews that came out I probably won't ever play it. The game seems to have a good background story, but the game play proves to be too limited.
A lot of people complaints and suggested the game play should perhaps be more like running and gunning. For me these comments suggest that I am on the right track in terms of my game design and philosophy behind it. I think if I have the time, budget and skills to make it into a full, it might actually be good.
Update on the development: Fixed some compile problems, and setup the added tile indicators. The plan is to have the indicator to indicate where the tile is placed (might even use different color to indicate different set), and when the user press refresh or change level etc, the stage will reconstruct with the new tile setup.
I have also decided to use Windows Form for the editor instead of the old WinAPI. It's much easier to use and has much more support. Yesterday I just thought of how to make a easy switch. I will just add in new forms, and slowly transfer the functionality from the current windows to it. That way I can avoid a lot of hassle like setting up a new project etc. Hope this scheme will work.
But it also makes me realize that the new tools etc keep rolling out, and I have to stay updated on what is available and what can be utilized and integrated etc. This process of scouting and evaluating etc I would say is a difficult task in itself. Yet again I feel I could have moved the development much faster if I can work on it full time. It would be easier to move into a zone etc. Perhaps what I need is to concentrate on it during weekend, when I have most of the free time. Sometimes though there are a lot more work than meet the eyes. There are a lot of design decision etc that I have to make, which all takes time and efforts, unfortunately.
Recently I am busy moving and doing other stuff. It's fun because it's a change of flow in life. But it caused my game development efforts to stall. That is expected though because I have heard a lot about it from other game development hobbists or indie game developers on the net. At certain point, a lot of the developers will just hit the wall...some will overcome, and some will give up on the project.
During this time I was actually trying to come up with another game idea, that has original gameplay concept, or concept that hasn't been explored well yet, with minimum arts development required. So far, I had some different ideas but none seems to satisfied the criteria.
Another thing I thought about is switching to DirectX from OpenGL. Because now it seems DirectX is actually simpler to use, at least to me. That is, to achieve the same effects, DirectX seems to provide a cleaner path than OpenGL. But switching would also require a lot of work probably.
In any case, I think I am almost ready to get back to the development. Gradually I should be able to pick it up where I left off.
For some reason when I use the file open dialog box, all the file read afterworld can't get to the right directory. This is a very weird problem, which I can't think of any possible reasons.
For now I have add a list box for stage selection, to avoid the file open dialog box. Later I should make the list box read the world.txt file to get all the available stages when the program startup. Also an update is needed when the users save a new stage. This design should work well. It's easy to use and easy to implement I think.
Man...moment like this makes me want to have all day working on the game or have 2 or 3 people working for me on the game. If I have 1 programmer, 1 artist, I am sure I can make a descent game out of it. But it won't even sell probably, which is the problem because I will have to pay for the programmer and the artist.
Another thing is I have decided on the adding new tile implementation. I have set things up so now the editor communicate directly with StageMaze class. I will use it to add the tile into the map, and also show the newly added tile in 3D box in the editor view. I will have a reload button or something similar in the editor, and when the user press it the system will regenerate the stage with the new map, thus give the user a correct view of the stage. The 3D box would probably have to have a number on it or something else to indicate the face it's using.
REF: 2008/04/tile-system-upgrade-progress-and-design
Recently I have been busy with something else so can't concentrate fully on the development. But still there has been progress. I have restructure the stage data file as mentioned before, and add in the light setup tab page, although it is not fully functional yet.
But right now I am facing a weird bug. The texture file and animation time file can't seem to be opened properly when I tried to load the stage in the editor. I have spend quite some time to try to figure out what is wrong. After fooling around a bit right now it seems the problem is with the open file dialog...I have no idea why and further investigation is needed.
Currently I am in the process of restructuring the stage's setup XML files. Before it has 2 files, one data file and one map file. Right now I am just going to combine them because they are seperated before only because of legacy left by development progression.
One thing that worth remembering is now I should allow the user to specify stage data (name, lights, etc) within the editor as well. Especially the light I should be able to use the editor to specify the locations etc.
I have clean up a bit and fix some bugs in the editor. The good thing is I realize I have done a major change (in the visual) but with other editor logic intact. I don't need any heavy modification in the editor because of the change in the visual. The camera move button, the tile selection and addition of tiles, enemies, event points etc would stay the same.
A small function left that still require some implementation is I need to tell the visual logic (GameLogic) to load the proper stage. Right now it just load the first stage. Now the only big problem is, how to display the construction of the stage in the visual. There are 2 possibilities I can think of:
I was reading some Wiki and other info about Lua, a scripting language. It seems very nice and a lot of games are using it, in different areas. I think I should learn about this language and try it out later. There should be a lot of info online, and I think one of those Game Programming Gems book also mentioned it. I should check them out when I have time.
http://www.lua.org/
Finally get the picking done. It seems to work well. The problem I had was putting gluPickMatrix inside GL_PROJECTION matrix mode and before gluPerspective. It's funny how they usually don't mention this type of calling sequence in the obvious place in the book etc. I only found this out in Lesson 32 of NeHe production example code. Without knowing the details of the function it's hard to evaluate what the problem is. But it's a good lesson about OpenGL.
Now I will have to start the next phase, which is...how am I going to add in a tile etc?
I think I almost got the picking to work, but for some reason it's off. The only explaination is the drawing during the picking operation is different from the normal rendering. But I check and re-check and can't find the difference. I might have to search the internet a bit and see if I can find the glitch.
After some testing and thinking, I think I will try to simplest way: rendering grid and use them for mouse picking. A side benefits of this design is I can also have a very simple implementation for multi-level selections. The user will select different height, and I will just draw and pick grids at that height. It's simple and clear.
The disadvantage of this is I can't use the mouse to cycle through different faces of a tile by letting the user click on the face. I think I might be able to add another window maybe that let the user select it using drop down or scroll bar (ideally).
But first thing first, I will have to get the simple stuff done before I get to the finer details.
This weekend I attempted to implement the mouse function back into the editor. Of course the first thing to do is change the OpenGL picking setup, and of course it didn't work properly. I didn't tried too much because I was busy with other stuff and didn't spend a lot of time on it, but right now it's effecting the performance, and might not even pick the right spot. If possible I should develop some sort of module ore class to handle this picking things more easily so next time I need it I can just plug it in. It may or may not be possible...will have to see.
One thing that distracted me from game development is me playing Titan Quest trying to entertain myself. But now I think about it...what a waste of time, haha... But hey sometimes one has to relax. I did come up with some interesting thoughts about APRG genre though. It seems to me on PC the only successful ARPG is Diablo series. Even some developers break off from Blizzard, forming their own companies, they still can't best Diablo in my opinion, even with new technologies. Different gimmicks, skill trees, stories, different amount of side quests etc etc have been tried in different games, and a lot of them sound more impressive than Diablo, but still, it can't be beat in my opinion. At least Diablo gave me more enjoyable time than the others. After playing Titan Quest, here is few of my observation on making good ARPG (obviously my opinions might have high probability of being incorrect, since so many others have failed to beat Diablo):
1. Fine tuning of level of difficulties and type of challenge: ARPG should be simple, dumb but not too dumb I think. It means that control of the character should be simple. The difficulty should be easy, but not to the point of dumbness. The games should offer player some challenge but not to the point of frustrations (die often, heavy punishment on death which include long reroute after death, long loading time after death etc)...Another way to say it might be it should be convenient for player to die, but rewarding to stay alive and kill a bunch of monsters,...I think.
2. Look Good: This sounds shallow but I think it's extremely important for ARPG to have everything look extremely good and cool in the game. This actually a bit related to point 1's reward aspect as well. I highly doubt any player will feel good if he gain a knife with +200 attack but looks like a banana. With a bad look, number and stats don't matter. It would be nice to make the player feel his character has become more powerful by the look of the equipments, statures and the attacks. Actually I think that's one of the problem with Titan Quest: equipments look blend and better equipment don't look that different or better. Titan Quest's expansion Immortal Throne did a much better job in my opinion. The armor etc actually make your character look nice. Few ARPG try to make the attack looks different when level up (except more varieties of skills) but I think that's actually one cool thing that can be done. The enemy also need to look nice, and they have to look better and better as the player progress, because it gives player more satisfaction when the players destroy them. If every enemies look like Tofu of course no one will get any satisfaction out of it, even if you make the Tofu extremely hard to kill. Blizzard's Diablo I think, actually did a good job in this area. The only exception to this "Look Good" rule might be some "need help" NPC since it might be better to make them look sorry to trigger player's sympathies.
3. Varieties: This kind of games need varieties...whether it's in the environment, type of enemies, quests, story etc. Anything that can shock and ow the players would be nice. But in my opinion it doesn't mean "a lot of" side quests. Because usually a lot of side quests means a lot of blend side quests. Plus, people are lazy, and might just ignore the side quests, or frustrated by it. It might be better...to force the varieties onto the player, challenge them visually and mentally rather than give them a bunch of similar challenges.
That's my thought so far. In general I think the expansion Immortal Throne is done much better than Titan Quest, it shows that the company did learn something. Unfortunately I heard the developer Iron Lore is closing now.
Another thing that makes me wonder is...Consoles should be the better platforms for this type of ARPG. I knew a few from the SNES etc. But consoles offer more possibilities with the control etc in my opinion. Yea, puzzling, how come not a lot of developers attempted ARPG on consoles.
Finally get the visual system integrated into the editor. Now the editor can see the stage as the players see it. The camera control is also implemented.
But this is only a start. Tough road ahead. Hopefully there won't be any unforeseen obstacle that will block the way. The biggest challenge is probably porting the conditional logic in the stage build system into the editor's adding and removing tile function.
The next step would be trying to add the mouse control (mouse indication) back in.
Interesting to note that...it took me more than half a month to get this integration done, ouch. I always thought it would take less time. But I guess it's fortunately enough that any got done at all since I only work on this during spare time.
The amount of integration in all these different components might vary from game to game I think. For example, in the making of God of War 2 documentary, the game's engine and tools seem to be tightly integrated . So in a way, game construction would be similar to other engineering. But because it's all software (game ideas, art works, programs), there might be some significant differences as well. In any case, it's quite clear that the power of a well constructed tool sets cannot be underestimated and are one of the key in a successful game or franchise.
Well, I guess here is the current result of the editor modification. Obviously it's not working properly. Looks like there are still quite some work to be done. No idea why the video card shows some left over image pieces from some games I was playing though.
After some development on the editor's visual system, I suddenly realize it might be a good idea to move all the classes etc from the main project into a separated LIB project. By doing this, my editor in theory can just reuse the same code my game is using for the visual. For example, if I just initialize and use battleView class I should be able to see the same thing I see in the game. Also, it makes logical sense, seems to me, to group code above the lower level independent LIB into a LIB of its own.
I am thinking if I can just use the same classes such as stage etc, but I have to make some additional functions such as addUnits, deleteUnits etc into the classes to make it more dynamic and easier to be used by the editor.
I have already moved the files and setup the project properly. Necessary backups are also created. Now I am ready to commence the next step.
Another interesting thing worth mentioning is I read the sci-fi military classic Starship Troopers by Robert A. Heinlein. Of course it's much better than the movie, haha....It's a controversial book, and I can see why some people might dislike some of the ideas in the book. Some ideas seem plausible, but because it's so different you wonder if it's actually good to think that way. Nevertheless the book has some very interesting ideas about politics and military.
What's important here though is it might give me some new ideas about my games etc.
