I've spent a lot of time on this software project...four years to be exact. One year was spent reading and researching, and three more years were spent developing and testing. At some point, however, a game engine needs to be put to use in something larger than itself, much like a V6 engine needs to be placed into a car.
In some ways it's a leap of faith at this point. All the hard work of development, testing, and research is kind of meaningless if you don't put the engine into something practical. In other words, it's time to down to the business of actually writing games.
One of the commonly suggested starting points for anyone that wants to get into serious game development is to recreate an existing game on the platform of their choice. The best starting point, however, is not create a multi-player online game. It is not to build the next Halo installment, either. Often, it's easier to start with something simple...such as a common card game (cribbage, poker, etc.) or a retro game such as Pac-Man, Space Invaders, or Missile Command. Checkers would work too, although building a chess game with a full-blown chess engine behind it is a bit daunting at first.
So, armed with Blender, Paintshop Pro, and a shiny new engine waiting to be revved, I'm going to plunge into game development again. Like the advice of old, I'll start with simple projects, with the end goal of building skills which will eventually pave the way for bigger undertakings such as the "Big Idea" I've hinted at in prior posts.
As always...stay tuned. I'll start posting screenshots shortly.
Friday, November 9, 2012
Wednesday, August 15, 2012
Misfire
Okay, not really. But my last post on here talked about "ignition" and how work on the game engine was going to start up again shortly. That was the original intent, but the time schedule got continually pushed back.
That said, this weekend we did some evaluation of the work that has already been done with the tools and the game engine itself, and so over the next few weeks I'll start getting into more in-depth detail on those topics.
Currently, we have plans for one Big Idea in the works, and we are considering in the short term working on some other, smaller games just to "test the waters" so to speak. More details to follow...
That said, this weekend we did some evaluation of the work that has already been done with the tools and the game engine itself, and so over the next few weeks I'll start getting into more in-depth detail on those topics.
Currently, we have plans for one Big Idea in the works, and we are considering in the short term working on some other, smaller games just to "test the waters" so to speak. More details to follow...
Monday, October 24, 2011
Ignition
It's been a while since my last post here, but there has been a good reason for the silence.
I took most of the summer off from the Jasper engine project mainly because I needed a break. Before the break, however, I worked on some low-poly trees and found some great videos that gave me a lot of new ideas. One of those can be found here and the other one can be found here.
Over the summer I also gathered some more game ideas, did some more animation research, and began preparing to take the engine into a game design phase. Much of the game design process will initially take place on paper, and I have given some thought lately to rolling out a short-term (1-2 month) game to demonstrate the engine's capabilities and to get some feedback. This way I could also run the engine through some more realistic tests and get some early user feedback.
I also created some basic trees in Blender and dropped some of them onto a terrain map for testing, but the screenshots are not all that impressive at this point, so I'll defer to a later date before posting those. That said, the major systems of the engine are all in place (particle systems, UI elements, sound, character animation, terrain rendering, etc.). The next goal is to either to start in on the major game I have planned or write up a small, side game project that may become available for download in the future.
Whatever the case, I'll post some more updates in the coming days as to where this technology is heading...
I took most of the summer off from the Jasper engine project mainly because I needed a break. Before the break, however, I worked on some low-poly trees and found some great videos that gave me a lot of new ideas. One of those can be found here and the other one can be found here.
Over the summer I also gathered some more game ideas, did some more animation research, and began preparing to take the engine into a game design phase. Much of the game design process will initially take place on paper, and I have given some thought lately to rolling out a short-term (1-2 month) game to demonstrate the engine's capabilities and to get some feedback. This way I could also run the engine through some more realistic tests and get some early user feedback.
I also created some basic trees in Blender and dropped some of them onto a terrain map for testing, but the screenshots are not all that impressive at this point, so I'll defer to a later date before posting those. That said, the major systems of the engine are all in place (particle systems, UI elements, sound, character animation, terrain rendering, etc.). The next goal is to either to start in on the major game I have planned or write up a small, side game project that may become available for download in the future.
Whatever the case, I'll post some more updates in the coming days as to where this technology is heading...
Friday, April 8, 2011
Debugging Is An Art
Most of the time, debugging is an art. It takes a careful balance of knowledge, hard-won experience, compiler tools, investigative skills, and loads of patience. But sometimes there comes a point when even these things have their limits and you throw your hands in the air in frustration trying to figure out what is going wrong.
Case in point: the strange texture bugs I was finding when I tested my engine on a Vista laptop.
Every other feature seemed to be working fine on the laptop, but every time I used a texture, the results were unpredictable. Often times, when rendering a tile map and some terrain features, the same texture would be used everywhere even though the tile map called for a variety of textures to be used...especially when rendering mountains.
Then, when testing some animation features, the textures on the animated model would look okay at first, but when I pressed a key (and another model came onto the screen), the texture on the original model swapped places with the new model that was being rendered.
Ugh.
Then I created a tile map with an array of textures just to test those functions.
The entire map was rendered with the exact same texture.
Can you say, hello brick wall? What was strange was that the issue was only occuring on the Vista laptop, and was not occuring on the XP box or the Windows 2000 I tested the engine on.
Somewhere, in the back of my mind, I kept wondering if it was a graphics driver issue.
I started eliminating possibilities. Was there some unitialized variable somewhere that was holding unpredictable values? Nope. Was the texture loading function failing? After lots of investigative work, the answer appeared to be no.
Then, I spotted a type/casting issue. Surely that must be it, I thought. Fixed the bug. Recompiled and tried again.
No dice.
At this point, things were getting discouraging. To add to the issues, the frame rates on the Vista machine were down by 10-15 fps compared to the XP machine. I know it is a laptop with a low-end processor, but this was ridiculous.
So I checked out some forums. I looked into the OpenGL on Vista issues. I prayed about it. Ugh...I was ready to just give up and live with it.
Then, I checked on the graphics drivers issue. According to the Device Manager's "Update Driver" feature it said I had the most current version of the driver installed.
I didn't buy it.
I went to the manufacturer's website and checked on the drivers that were available. And wouldn't you know it, there was a driver out there that had an update date of 2007 (vs. 2006, which was pre-installed on the machine itself).
At this point I was so used to hitting brick walls with these bugs that I didn't hold out hope. I was preparing a "Plan B". And C. And D. And E...
I installed the new drivers, ready to hit the rollback button if necessary.
And then I tried the engine again.
In one swoop, a whole class of bugs was wiped out. Every. Single. One of them.
The texturing issues went away. Completely. The frame rates shot up 10-15 fps, and in some cases it was faster than my XP machine. Wow what a relief! Now I can really, truly, start focusing on game design.
Moral: check your drivers!
Case in point: the strange texture bugs I was finding when I tested my engine on a Vista laptop.
Every other feature seemed to be working fine on the laptop, but every time I used a texture, the results were unpredictable. Often times, when rendering a tile map and some terrain features, the same texture would be used everywhere even though the tile map called for a variety of textures to be used...especially when rendering mountains.
Then, when testing some animation features, the textures on the animated model would look okay at first, but when I pressed a key (and another model came onto the screen), the texture on the original model swapped places with the new model that was being rendered.
Ugh.
Then I created a tile map with an array of textures just to test those functions.
The entire map was rendered with the exact same texture.
Can you say, hello brick wall? What was strange was that the issue was only occuring on the Vista laptop, and was not occuring on the XP box or the Windows 2000 I tested the engine on.
Somewhere, in the back of my mind, I kept wondering if it was a graphics driver issue.
I started eliminating possibilities. Was there some unitialized variable somewhere that was holding unpredictable values? Nope. Was the texture loading function failing? After lots of investigative work, the answer appeared to be no.
Then, I spotted a type/casting issue. Surely that must be it, I thought. Fixed the bug. Recompiled and tried again.
No dice.
At this point, things were getting discouraging. To add to the issues, the frame rates on the Vista machine were down by 10-15 fps compared to the XP machine. I know it is a laptop with a low-end processor, but this was ridiculous.
So I checked out some forums. I looked into the OpenGL on Vista issues. I prayed about it. Ugh...I was ready to just give up and live with it.
Then, I checked on the graphics drivers issue. According to the Device Manager's "Update Driver" feature it said I had the most current version of the driver installed.
I didn't buy it.
I went to the manufacturer's website and checked on the drivers that were available. And wouldn't you know it, there was a driver out there that had an update date of 2007 (vs. 2006, which was pre-installed on the machine itself).
At this point I was so used to hitting brick walls with these bugs that I didn't hold out hope. I was preparing a "Plan B". And C. And D. And E...
I installed the new drivers, ready to hit the rollback button if necessary.
And then I tried the engine again.
In one swoop, a whole class of bugs was wiped out. Every. Single. One of them.
The texturing issues went away. Completely. The frame rates shot up 10-15 fps, and in some cases it was faster than my XP machine. Wow what a relief! Now I can really, truly, start focusing on game design.
Moral: check your drivers!
Monday, April 4, 2011
Water, Water Everywhere
Today's screenshot, while rather uneventful looking, actually represents a significant step forward for the engine.
It represents weeks of work...and the final promotion of the water mesh concept into the map tool (and subsequently rendered by the engine). In other words, I can now add water meshes/features to my tile maps, similar to how terrain features (mountains, hills, etc.) can be added to a tile map. Then, when the map is imported into the engine, it will be rendered as a water feature, just like other terrain features.
Additionally, I have also been testing the engine on a Vista machine, as well as a Windows 2000 machine. There are a few minor bugs on each system to work out, but they are not showstoppers. At this point, the engine is officially "feature complete" and I'll be enlisting some other users soon to get rid of as many bugs as possible before moving ahead with games building.
Next up: the game design phase. :-)
It represents weeks of work...and the final promotion of the water mesh concept into the map tool (and subsequently rendered by the engine). In other words, I can now add water meshes/features to my tile maps, similar to how terrain features (mountains, hills, etc.) can be added to a tile map. Then, when the map is imported into the engine, it will be rendered as a water feature, just like other terrain features.
Additionally, I have also been testing the engine on a Vista machine, as well as a Windows 2000 machine. There are a few minor bugs on each system to work out, but they are not showstoppers. At this point, the engine is officially "feature complete" and I'll be enlisting some other users soon to get rid of as many bugs as possible before moving ahead with games building.
Next up: the game design phase. :-)
Tuesday, March 22, 2011
Testing News
No screenshots today...although I have some testing news. I began to test the engine on other systems, most notably a laptop with Windows Vista installed on it. The tests ran reasonably well, although there was a 10-15 fps performance drop on terrain rendering and UI rendering, but that was to be expected considering it is a Celeron/Windows Vista Basic laptop. I'm just happy at this point that it is working without a hitch for the most part. Hopefully at some point soon I'll be able to test it on a Windows 7 system, too.
Over the next couple of weeks I also plan on making some tool updates and will promote the water/mesh functionality I developed over the past month so that it is on par with the terrain map feature I have in the map tool today. I'm also continuing to improve the UI functionality I mentioned previously.
Over the next couple of weeks I also plan on making some tool updates and will promote the water/mesh functionality I developed over the past month so that it is on par with the terrain map feature I have in the map tool today. I'm also continuing to improve the UI functionality I mentioned previously.
Tuesday, March 15, 2011
More Waves and Dialog Boxes
After several weeks of testing several different algorithms, I think I've finally settled on one for rendering basic waves (without the help of shaders). It's been a long road, and oddly enough, I've pretty much come back to where I started, with some minor modifications to an original idea...combined with a minor discovery. First some wave screenshots:
The new algorithm essentially checks the nearby eight vertices (as opposed to the four I was originally working with) and averages them. Also, when a waveheight initially passes over a point, it essentially starts the point "spinning" around. That angle is translated via a sine function into a value which is added to the point's height. The key discovery I made was that through this combination, I could make each vertex of the mesh simluate a dying sine wave by continually decreasing the radius value in the following equation:
Basic trigonometry, yes, but in all my previous testing I ignored the r component for some unknown reason.
I've also been busy working on some 3-D dialog box improvements, seen here:
In this screenshot, I'm demostrating some basic checkboxes, a slider control, a textbox control, a button, and an image control. All on a fully rotatable, 3-D dialog box/window. The main use for this will be heads-up-displays, pop-up dialog boxes, etc. It is also fully alpha-blending enabled.
With these items nearing completion, I'm now turning the corner towards actual game design. There is one last stubborn textbox bug to squash, and after that I'll run some tests over on my Vista box. Then...it's design time!
The new algorithm essentially checks the nearby eight vertices (as opposed to the four I was originally working with) and averages them. Also, when a waveheight initially passes over a point, it essentially starts the point "spinning" around. That angle is translated via a sine function into a value which is added to the point's height. The key discovery I made was that through this combination, I could make each vertex of the mesh simluate a dying sine wave by continually decreasing the radius value in the following equation:
y = r * sin (angle)
Basic trigonometry, yes, but in all my previous testing I ignored the r component for some unknown reason.
I've also been busy working on some 3-D dialog box improvements, seen here:
In this screenshot, I'm demostrating some basic checkboxes, a slider control, a textbox control, a button, and an image control. All on a fully rotatable, 3-D dialog box/window. The main use for this will be heads-up-displays, pop-up dialog boxes, etc. It is also fully alpha-blending enabled.
With these items nearing completion, I'm now turning the corner towards actual game design. There is one last stubborn textbox bug to squash, and after that I'll run some tests over on my Vista box. Then...it's design time!
Subscribe to:
Posts (Atom)



