The last few years have been trying for various reasons, and it seems that other things in life have demanded my attention more and more. This is fine as life is known to do, it changes, but when we cease to change with it, we become stagnant and static, which eventually leads to lack of ... Continue reading Episode One
About this blog
Entries in this blog
Client : PhyerSoft
Contract Length : April 2011 - August 2011
Role : Lead Developer/Programmer
Tools : Troglodyte Game Engine, Adobe Photoshop, Opengl, OpenAL, C++
Platform : PC
Barricade was the first real time game that actually had some content that I ever worked on. Mike Poole from Phyer was the designer of the game.
The game was created using my custom C++ engine Troglodyte, which used Opengl for rendering, OpenAL for audio, DirectInput for gamepad controls.
I initially was developing my game engine specifically for this game, but later left the group. I returned in 2011 to tackle the project again,
with my engine in a more complete state. The torch was later passed on to another coder, and I'm not sure the state of the project these days?
The alpha featured 3 robots, 4 levels, and 2 different kinds of blocks. The alpha showcases the bare systems of the game.
It had interesting block match type of mechanic that is present in the alpha, but do to no visual feedback, is hard to pickup on.
I learned a lot during the development of this prototype.
With the help of Josh Larson, we set off to create a augmented reality prototype that our client Catchfire Media could use at an expo to display augmented reality technology to their client John Deere. It was a simple app that allowed for a 3d model to be displayed on the touch devices
screen when the camera was pointed at a specific image. In this case the John Deere 500J. Users could then interact with the model, rotating and
viewing the 3d model overlayed on the image. Various portions of the model could be selected and information about the tractor was displayed.
This was a fun project and I hope to get a chance to work with Vuforia and Augmented Reality tech in the future.
Client : Soma Games LLC
Contract Length : July 2012, Approximately 30hrs
Role : GUI/Systems Programmer
Tools : Unity 3D, NGUI, C#
Platform : IOS, Intel Ultrabook Touch
Wind-Up Football was a collaboration with Soma Games. I was in charge of scripting all the logic for the graphic user interface,
as well as using Unity's PlayerPref object to setup serialization for managing the games item system. I left this project early on
as I was offered a Lead position working with Salt Shaker Games, but not before setting up most of the frame work for what would be
used to complete the systems functionality.
You can buy the game for the iPad Here
Client : Salt Shaker Games LLC
Contract Length : June 2012 - September 2012
Role : Staging Artist/Scripter/Lead Designer
Tools : Adobe Air, XML, Unearthed Tools, Adobe Photoshop
This was the largest project I've worked on thus far with animators from Russia,Texas, and various coders from all over the country. Unfortunately,
due to various issues the publisher dropped funding for the game when it was about 75% complete.
I started off as a staging artist and scripter. I drew over 200 unique images in Photoshop and placed them in scenes and scripted game logic.
After production quality assets were complete, I would go back and replace the temporary assets, test, and adjust logic accordingly.
Later, the Lead Designer left the project and I was given the opportunity to take over. I got to work on some of the pacing issues and a few
of the games puzzles. If only funding would have continued, but development was abruptly stopped in September.
You can download the Golden Hour Build Download Here
Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!
For work, I am working with a small team of Independent developers. Since joining this team back in early June, I've worked on a various set of contracts. For some of these contracts we have been using Unity 3D and so I've been getting pretty familiar with Unity and have wanted to even use it for my own projects. I had worked with Unity previously to this, but never wanted to really make the switch for my own projects. I had spent a few years refining my own game engine and didn't want to abandon it. After working with Unity for so a while it started to grow on me and the portability options, ease of interface, and many other features, just make it a no brainer to use. Not to mention the free edition and reasonable price of the pro version. The Unity team has really done an awesome job and I'm proud to be a convert now. But enough of an ego boost for those guys .
Wanting to keep my projects in a small enough scope to complete, I'm concentrating on 2D games. This in and of itself isn't a bad thing, but Unity, out of the box isn't streamlined for 2D development. There are a few packages available on the asset store that look to help with 2D games specifically, and I looked at them, and just didn't feel that they were intuitive enough for me to work with in a quick way. So, I decided to port over the most common libraries I used in my own game engine, thus Trinity was born.
Right now I just have plans to use it for my projects. I have completed a first pass integration and have finished getting the same functionality from unity as I would my own engine, but with all the added benefits unity provides. As I continue to add to this functionality, I may toy with the idea of adding it to the asset store. Not really wanting to compete, as I don't want to spend a lot of time publicly supporting the framework, but really to offer a light weight alternative to some of the other frame works that are out there. I should come to a decision on this by the next week sometime.
When I was about eight years old, I had spent the weekend playing a game which the likes of I had never seen before. A title called Actraiser , which was a mashup of action,rpg,and sim city type gameplay.
After playing this game for most of the weekend, I remember talking to my mom about it and describing all the things I liked about the game, and all the things that I would have improved. My mom said something that stuck with me at that time, something that I had never considered up to that point, she said, "Maybe someday, you can make games and then fix all that stuff." I had rented the game for the weekend, yeah I'll date myself by saying we rented games for the weekend back then, so we took it back the next day. It would be fifteen years later before I was able to recall what the name of that game was, and I didn't play it again until then.
The statement my mom said to me at that point planted a seed. However, I didn't get my first computer until I was eighteen years old. Up until that point I had pursued being a musician and a writer. It was when I was eighteen that I started first learning html, and then began trying to teach myself C++. But I'm getting away from the point trailing down memory lane here. The point is that Actraiser was really the first game that I ever played that made me consciously think about game mechanics. I had been playing mario , sonic, frogger, ect.. since I could remember, but this game made me go hum.
Most of the narrative of this game was delivered through the gameplay and through interaction with angel, a little avatar who talked to you, the god of this planet. You would take physical form and go down to the earth to free different areas from monsters that had taken over the planet. After you cleared out the creatures you would then go into the sim city type mode and rebuild the city, using experience that you gathered from the action game play mode. Angel would explain different elements of the story as you went a long. It was all very cleverly done.
It's been a little over twenty years since the experience of first playing that game. It still sticks with me to this day, and is probably one of the most heavy influences on me pursuing game development, the ability to create worlds that people can not only witness, but be a part of and experience. To be able to take on the role of another character is the ultimate empathic experience. It can literally put you in the perspective of someone else, and I look forward to seeing games explore this more.
A perspective is useless however without well defined characters for the player to relate too, and without motives and direction for the player to experience. Of course this is more geared towards games that are character and story driven, and it is difficult to find a balance between a purely linear experience, and a dynamic one where story is involved. As I am currently in a design phase for my current project, I have been exploring various ideas on how to create the best characters and narrative for the game. Through this analysis I have been looking towards other forms of media for inspiration and asking myself, "What has been the most memorable characters, stories, and experiences, and why?"
This is the beginning of a series of articles that will be exploring that question. I will be looking at five television series and five different games that have influenced me heavily in story and character development. I will also be going through and discussing strengths and weaknesses for each, and how specific lessons can be taken away from them, and possibly used in game development. I've chosen tv shows specifically for their episodic structure and because of their ability to weave a universe over time that makes us care about the characters. I have also chosen games because, well, that's what this is about. Now there are a shit load of each of these out there, so I had to make some choices, and while some of them have similarities, I've tried to have some contrast in my selection while still having those that have influenced me. So without further ado --
Our Line Up
So, for tv shows, this is our line up. Next time, I'll start by taking two shows, doing a general overview, and then present my arguments and ideas. So, tune in next time, same bat time, same bat channel.
Since that time, I've been going through some personal transitions as well in regards to employment. I've found myself working a job that while it doesn't allow me as much time on a daily basis to work on personal pursuits, overall it should be excellent for time working on personal projects. The sad part however, that I've been at a loss for what to work on. I have four projects that I could potentially work on that I have not completed from the past, but I have been lacking any solid passion for any direction on any of them. This has been for a number of reasons I suppose, but really what it comes down to is a lack of direction.
I've also been having some financial struggles, an example of that is I currently don't even have internet, but instead am just writing this on my own server, which is currently off line. I think that this could potentially end up being a blessing in some ways as there are less distractions, but at the same time, the endless sources for knowledge aren't as easily accessible. Which really just comes down to me making specific notes and then going else where to perform some research online, before returning here to carry out and apply the results of any research.
This is actually the most I've written in the last three months, and I've got to say it's good be sitting here doing some actual writing. I did spend a few weeks looking at the world of C.F.L. again, pondering whether or not it was worth advancing on that project. At this time, the one thing that has been keeping me from pressing forward with it has been the overall juvenile perspective that it represents. While I think some of the games original design elements are solid, if I were to redesign the game and make less about sex, that and of it self starts to become a different experience completely. On the other side of things, keeping in mind that the game is supposed to have a lack luster view of things, it could also be used to show consequences of sexism and sexist behavior. I could also just neglect any real impact that the game would have on culture and just chock it up to a stupid game that most wouldn't probably play and just get back to work on something to have in my credits. Also simply to complete a project for once.
We are at the end of another year. I don't feel that this year was waste. Instead, I think it was a great example of how not to work with team mates. I think it was a good refresher for me to be back into the world of game development, and with the completion of something like relic in roughly 48 hours, and having had the alpha for the game I was working on with that unnamed team, completed in about 4 months, it was a good boost of confidence and was somewhat reassuring. Looking forward, it is definitely time to get moving on things again, I'm still feeling a little at a loss as where to start.
This is a short post however, I just wanted to share this video from Extra Credits - If you don't know what that is follow this video to the escapist and check it out. This short video does a very good job of giving an example of using game mechanics to communicate an idea. Check it out.Source
this is a subject that has been debated and with most things it really just comes down to how we choose to define it. Meaningful here is game mechanics that are used to express an idea that is central to theme or narrative that the designer/developer is attempting to communicate.
The jam was a great time. There were five games to come out of the event, and rather then do a complete write up for each, I will instead point you over to meaningfulgameplay.com where there is dedicated postings to each project. Some information, including links to download each proto-type is not yet available, some are up already, but the remaining ones should be up within the next few days.
Here is a general recap of the weekend from my perspective.
Thursday, August 11 2011
Thursday night I was attempting to get everything ready for the weekend. I had packed most things I was going to need and had worked on setting up the dev environment I was going to be using for the jam. I had volunteered to give Paul, a fellow jammer, a ride the next morning, but having to work the day before the jam, I could only give him a ride in the morning. So, we both had to get up pretty early the next day. I was excited, but managed to fall a sleep around 12am.
Friday, August 12 2011
Fired and pumped, I was up at 4:30 to pack up the car and head to Ames where I would pick up Paul. By 5:30 I had the car packed up and with breakfast sandwich in hand, was ready to go. Or at least I thought, until I attempted to start the car and had the engine seize up. It wouldn't do anything. So.., I hit the phone and the internet, letting people know the situation. I checked out the car too, one of my fears that I had when buying the car had come true. The intake manifold had cracked and the engine block was now full of oil and coolant. Not a good combination if you want to go anywhere. An hour later I finally ate my sandwich.
I got a ride into work and made a plea out over the nets for someone to get Paul who was still waiting in Ames. Luckily Franco from GBGames was able to swing up and get him. At work, I was doing my job and also dealing with getting my car towed and into the shop. It was going to be a pricey fix and the car wouldn't be available for sometime. In addition to having to get a ride into work, I also had to abandon about 75% of my jam supplies. This would prove to be a small inconvenience in and of itself. (Murphy's law was kicking my ass so far.)
I got a ride from a co-worker from West Des Moines to downtown where the jam was being held. I had to leave work early to get the ride, but I had almost made it. I forgot to get the directions off of the internet before I left work and had forgotten the exact address, so I walked around until I located a WiFi signal and after getting on the net, got the address and walked the few blocks over to the Liberty Building.
It was about 2:30 and when I walked in Josh and Paul were speaking with Ryan via google hangout. They were pretty engaged in conversation so I went a head and started setting my laptop up. I still had to get a stripped down version of the engine setup for a new project and so I began a continuation of struggles I was having that day. Struggles because the laptop was running like pure molasses. I would continue to struggle with the laptop for about 12 hours. Eventually it would be made apparent that the hard drive was about ready to take a dive.
Other people started showing up a few hours later. I believe Beige,one new to our group showed up next. Then Nick at which point four of us went to go get pizza. We trucked around the city for a bit, ducked into a pizza place that was quite full and then ended up at a Domino's when the wait was too long. We did some basic introductions and discussed some general game development things while we waited for our pies. We then headed back to bit method to consume our fuel.
The Dusty and Ryan showed up briefly after that with Franco coming in not long after. I think it was around 8 or so when we officially got things going. Josh did a brief talk about meaningful game play and spoke about some points that Jon Blow discussed at a gdc panel. As well as watched Alec Holowka's talk on holistic design. Then we were off to the races.
I didn't really have a plan of action going into the jam. There had been some general ideas that I had been having, and as I talked with a few people the idea began to take clearer form, in the sense of becoming clear what I really wanted to communicate. The meaning that I was striving for the game to communicate.
An aside on Impermanence - or - How the analysis and presentation should have went.
(Had I had time to work on the analysis these are some of the things I would have spoken about.)
When looking at ideas for what to explore at this jam. I kept coming back to things like commitment, drive, tenacity. As I thought more on it, I began asking myself what do these things have in common? To me the big thing is that they are all components to achieve something, specifically for me, these things relate to my goals as a game developer of being able to operate my own studio. But why are these things important and why is there such an urgency from these things? The answer, impermanence. Impermanence could be looked at simply as change. We are all impermanent, we will live for any undermentioned amount of time, and we will die, at least at this point, all of us. Now what death is and what actually happens there is another topic entirely. But what can be said is that for any of us, dealing with impermanence is something that we must all endure.
In my life, I've recently had some people pass away that were seemingly young, in good health, and then bam, they were gone. That can happen to any of us, and while we shouldn't waste time waiting for death to come, we should let death serve us as a reminder to make the best of our daily lives and help us have a sense of urgency in accomplishing the things that we set out to do. It should also serve to allow us to enjoy the now and to be present in the company of others and to really share who we are with one another.
Impermanence doesn't exist as only death, but death is an extreme that can not be ignored.
Framing our theme into an actual game
Nick Silhacek and I brainstormed for about an hour to an hour and a half about how to best convey impermanence. We had the assistance of Keith Riddle, and another guy who's name escapes me at this point in time, during our brainstorming and we definitely came up with enough ideas for multiple proto-types which was one of the objectives of the jam.
After our brainstorming session, I had to let a guy named Roger into the building who had been waiting for fifteen minutes.(We were in the heat of brainstorming and even though I heard my phone blowing up, it didn't register what it was.) Sorry about that one Roger. We then headed to a gas station for a late night snack and some energy drinks.
I spent the remainder of the night attempting to get my laptop to work enough that I could actually do anything, but I couldn't even type out a line of code in visual studio without the whole system hiccuping and it would take 30 seconds for it to even display the key presses. Not the best situation to be in at a game jam. I did manage to show nick the script that I use in photoshop for exporting sprite sheets and even though his first time creating graphics for a game, he met every requirement I gave him for the asset pipeline and did a pretty good job getting things moving for art resources. Eventually people started going to sleep. I was on a third wind by the time 3am came around and I ended up staying up and watching hot tub time machine because I was too tightly wound. I ended up passing out at 4:30. Thus ended the first day of the jam.
Saturday, August 13 2011
I woke up Saturday at about 8am. Franco appeared to be the first one up. I continued to attempt to get Visual Studio to be responsive on the laptop and eventually I had it so it was some what more responsive. I ended up calling the mechanic and found out my car was done. I called my dad who took me to get the car and I then proceeded to go get my server/workstation from the apartment.
I think it was around 1:30pm on Saturday, I was sitting down and actually starting to hammer out some code. We had a high level concept that we were working towards that was focused around :
Having Impermanence drive the gameplay. - Having the thought of impermanence be the motivation for the player was at the heart of the design. In order to do this, we decided that we would have a time limit for the player to search for an item. If they did not find the item within that time limit they would have the game world reset, and they would have to start the search over again. This would require systems that did some random placement of items, the player character, the item they were searching for and some obstacles.
I took kind of a hap hazardous approach to coding. I did a lot of the interfaces for the levels and stuff first and once I had the flow of the code setup I went back in and added the functionality. That actually ended up working pretty well and made coding pretty rapid. A flaw to that approach though is that you quickly have multiple classes and stuff to manage so the code can potentially get overwhelming. That didn't end up being the case here, instead, sleep deprivation was my worst enemy, causing me to end up eventually getting burned out around 1am or so. I stayed up a while longer, I watched some tv show on netflix as a break and then inspired by the work of others, I pushed myself to code a little more. 3am came around and I was ready for sleep.
Sunday, August 14 2011
Sunday, I was the first one up, I think I was also one of the first to fall a sleep. I was up at 8:30, made some coffee, had a sandwich and got to work. Within an hour or two I was putting things up on the screen and attempting to fix bugs and write new code for additional functionality. This was a good test for my use of my game engine. I've only used it to make Barricade at this point, and that game doesn't use half of the functionality that I have exposed through the engine. So, this allowed me to experiment with some code that I had written months before.
Nick finished the hero sprite and on Sunday he began working on the relic sprite. We worked as best we could but with only five or so hours before the presentation time started there was limited time for what we could do.
By the time presentation time rolled around we still didn't have:
A pattern for obstacles to be placed - They were being randomly placed in the game world, but with
no discernible patterns that would truly make them useful as obstacles.
Collision for obstacles - I simply hadn't coded it yet.
Drawing for Wraiths - We had an enemy character that slowed our player down. There was an issue that I was trying to solve (I had forgotten to initialize memory for their animations) when presentations started.
A world map. - The world is big and should probably have a map for the player to refer to so they know where they are and where they have been in regards to the world.
Behavior for Wraiths - there was no logic to define how the wraiths should behave.
A timer - This timer was central to the core gameplay.
Those items would have constituted our working proto-type and if I find myself with some time this week, I will be completing those items.
The presentations for the rest of the projects went very well. I was so tired and somewhat disappointed with progress from the tech trouble of the laptop that when it was our turn to present, I think I did pretty bad. You can gauge that for yourself in the presentation video however.
This jam is focused on meaningful gameplay. You can find out more info on the discussions that have led up to this here Discussion at Josh Larson's Site
Come join us. It should be an awesome time!
In the meantime, here are some more recent screen shots.
Some core stuff such as the scoring system, continous block regeneration, various game modes, power ups, and more are still in need of being coded, but it gives a general idea of what we are building.
Once the Alpha is complete Mike Poole of Phyersoft will be analyzing the current design, we'll do some internal testing and some testing with people we know, then we will begin on the full production version.
We are aiming for a 4thQuarter 2011 to 2nd Quarter 2012 release, then depending upon the games reception we will be looking to port it to other OSs and mobile devices, if it does well on the pc market.
I've recently been re-reading Hackers: Heros of the Computer Revolution , which if you haven't read and you're a computer enthusiast or game lover, then I would suggest reading it. It's a great history of computing in general.
I've been working on Barricade again for a solid month now and have been making excellent progress on the game. I would post some updated screen shots, but we are waiting until we get a little more polish to start posting any videos or screens. As I've been making progress on the game and re-reading this book, I've been beginning to think a lot about how things have progressed from the 1970s to where we are now, and how the market and business of game development and computing continues to evolve.
Apple computers was the beginning of the personal computer revolution. Some may say it was the Altair, or maybe a few of the other hobby kits that were available back then, but the apple was the first thing that resembled what we still use to this day. This is common knowledge. What may not be common knowledge however is the ideals that sprang forth the birth of that computer outta Woz's head like a titan giving birth to a god. It wasn't initially inspired by business, but more of a love of computing in general, a love of exploration and creativity. A concept that many apple users carried with them for a long time, this helped to inspire the creation of many other businesses, clubs, ect..
One such business that was inspired by the apple computer was Electronic Arts. I for one, before reading the book the first time many years ago, had no idea that EA was founded as a safe haven for programmers and to help those coders in the early 80?s who were starting to get less royalties from publishers such as Sierra Online and other companies that had made their fortunes in the early eighties.
Here is one of my points, the paradigm shifts. Today , at least as far as I know as an observer, companies like EA are no longer promoting the creativity, innovation, and ideals that they were founded upon. The ideals of giving people creative freedom and helping the individuals who were driving the business back then has taken a back seat to pumping out products in a line of IPs that just don't die. I don't know personally, but have read that creative freedom is extremely lacking and these companies that thrived on letting people have expression and ownership in the games they were developing have now become no more then software machines churning out cookie cutter games with little to no passion. There are exceptions here as there are some good quality games coming out of places like EA, Dead Space being one for example, but this seems to be the exception, not the rule.
The same can be said for Apple. The company founded on a machine that was designed for ease of access and sharing and creativity has become another bureaucracy. Previously filing lawsuits over people wanting to modify their Iphones and completely trying to circumvent people doing so. Also, limiting the transfer of files to and from devices through a proprietary p.o.s. program that is a pain to use is a complete 180 of what Apple once was. It's a sad state of affairs to see all these companies turn to the dark side when they had such grand promise and ideals in their founding.
We are currently in the midst of another era that is quite similar to the early 80s where many indie developers are going to be making bank, enough to startup their own companies and such. I am writing this in the hopes to be a beacon, a reminder that for those that do see success, try to think ahead enough to protect what it is that you are doing, in the future. Business is business, but even if a company is started, does well, and then is turned over to suits in the end, there are still safe guards that can be put into place to make sure a companies visionary roots are not tainted.
Ultimately, I know things can grow so big that the vision can get trampled, but if that is the case, maybe the answer is to simply keep things small and focus on making games that you are passionate about? It will be interesting to see how things continue to change and develop, who knows, maybe the big boys will get back to their roots someday?
Fast forward to almost two years exactly and I started back where I left off. I was making some good progress, but I was starting to notice the same trend as before. I was making tools, not games. If you read through my previous posts you may notice I discuss this a little bit, and it is something that I've struggled with. I work a full time job in addition to being a father and as I continued to move forward on the tools, things seemed to be moving rather slowly. The tools were meant to be a means to an end, game development, but they were proving to be more of an end in and of itself. Towards the end of March, I made a decision, I was tired of working on tools, I wanted to make games.
My game engine had been in a usable state for a while and after much debating about whether to use something like Unity, I decided to press forward with using my engine. I had spent years developing it, and with it streamlined for 2D already, it was geared towards the group of games that the development team I'm working with will be developing and last week, we started pressing forward.
As per the Screen Shot above, production on the game Barricade with PhyerSoft has picked up again. We should have a public demo within a couple of months here. I've managed to do quite a bit the last week or so on the game.
To all the guys out there that have said develop games, not tools, I have this to say :
Follow what it is you want to do. I set off on developing an engine because I wanted to learn the ins and outs of game programming. This was useful to a certain point. But at a certain point, you do have to get back to what it is you are really trying to do, which is making games. There are plenty of available tools out there for people who are wanting to start out in game development, so if games are what you ultimately want to do, it's a good idea to go a head and use what's available. If there is something specific that you want to do and a tool isn't already available, why not make it.
No one can tell you the approach that is going to end up working for you. They can only give you an idea of how it may go based upon experiences that they had or that other people have had. The most important thing is to try, experiment, and then come to your own conclusions about which path is right for you. Failure is only present when you either give up, or never even try.
As for me, we are currently moving a head with development with the engine in it's current state. Which is lacking the completed python interfaces for scripting. I will be going back and finishing those interfaces, but for now, getting a completed game under my belt seems like the best approach. Barricade, as it's stands has about 75% of the assets completed and is about a quarter of the way through for the completed demo. We will be releasing the public demo in the coming months and looking for some initial feedback, I'll post links when they are available.
I wrote a few functions that helped stream line the engine that maybe helpful to others, namely :
Pixel_2WorldSpace(float arg) which is a function that simply converts pixel space into opengl coordinates automatically so that object scaling, translation, and rotation can all be done with pixel dimensions. This is ideal for 2D.
I also wrote a couple of functions for automatically mapping uv coords, and they accompany the Animation Export Script for photoshop. They read in the sprite sheets based upon the size of the frame cells. Using these functions , one for static images, and one for animations, accompanied with a SetDimensions function, we can create an accurate in game representation of a game object with a few lines of code. This has sped up the engine itself and sped up getting things up and on the screen in a completely accurate fashion.
bool Sprite::Anim_Map_UV(int first_frame_row, int first_frame_col,float f_width, float f_height, int numFrames, int AnimationNum)
//calculate the initial uv positions
float initial_x = f_width/Texture.width;
float initial_y = f_height/Texture.height;
//How many cells rows and columns in our texture have.
int frames_per_row = Texture.width/f_width;
int num_of_cols = Texture.height/f_height;
//Make sure the animation exist in memory
if(AnimationNum > GetNumOfAnimations() || AnimationNum < 0)
MessageBox(NULL," The animation you are attempting to map is not valid.",
"Sprite::MapUV() Error!", MB_OK|MB_ICONERROR);
int count = 0;
//create our multipliers
int x_m = first_frame_col;
int y_m = first_frame_row;
//If we've reached the end of the row, move down to next row, first col
if(x_m == frames_per_row)
while(count < numframes );
bool Sprite::Static_Map_UV(int frame_row, int frame_col,float f_width,float f_height)
//calculate the initial uv positions
float initial_x = f_width/Texture.width;
float initial_y = f_height/Texture.height;
//How many cells rows and columns in our texture have.
int frames_per_row = Texture.width/f_width;
int num_of_cols = Texture.height/f_height;
//create our multipliers
int x_m = frame_col;
int y_m = frame_row;
MessageBox(NULL,"The texture Coordinates could not be set.",
float Pixel_2WorldSpace(float arg)
float par = ((float)TrogWin.GetHeight())/((float)TrogWin.GetWidth());
void Sprite::SetDimensions(float x1,float x2,float y1,float y3)
Those functions have been extremely helpful and hopefully will be helpful to someone else out there. Of course there are some specific functions for the engine that these functions use, but they should be somewhat self-explanatory.
Spring is almost here. There are a lot of birthdays in my family in the month of March, so it's always a busy time. Spring is in the air, and with it themes of renewal and rebirth. When I first started coding what would later become the base for the rendering components of the Troglodyte Game Engine, it was first called Phoenix. Phoenix was fitting and is fitting for any type of software development as it is a process full of re-iteration and rebirth, but Phoenix is an all too common name and that was one of the decisions in the eventual renaming of the engine.
So, at this point of the engines development, I am going to visit Scripting With Python. I am going to write a series of entries covering the interface development and host API for the engine over the next few weeks. This should help keep me on track and hopefully may provide some helpful hints to anyone looking to dive into the subject matter. If not, it at least keeps me on the cutting edge of typing ;P.
[color="#f0e68c"]Embedding Python - Squeezing snakes in tight places.[/color]
Python allows for two ways of communicating with C/C++. You can have your python application call c functions, this is referred to as extending python, or you can have your C++ app call python functions and have the execute logic on C++ Objects. That is what Troglodyte is designed to do, and what I will be working on over the next few weeks. The process, as I will explain in more detail, can be quite involved. You basically have to change data types between C++ and Python, and for functionality that is somewhat complicated, this may have to happen multiple times for one call. So there is some over head involved in this process. In the end however, it will allow for the python interpreter to update data in real time and will ultimately eliminate the need to recompile the engine every time we change data for a sprite or in game object. It is also my goal to have a modular approach for the functionality of the in engine editor, having the editor being scriptable and allowing functionality to be added and updated at run time.
So, what types of things should be exposed to python? The short answer, things that are dynamic and need updating. This current pass of scripting interfaces is being somewhat streamlined with just the high end objects being scriptable. At the highest level of in game objects is our Sprite Class. Not only does our sprite class need to be exposed to python, it needs to be expandable through python. Meaning that we should be able to specify functionality that isn't inherently part of the Sprite class but that a specific instance can execute depending upon the desired action called by the script.
[color="#f0e68c"]Now For SSSSomething Completely Different[/color]
The Sprite class in all of it's glory is the highest non-game specific class in the engine. It goes through various levels of inheritance starting with the ABT TObject. The Sprite class makes use of texture, audio, spacial translation, animation, and object serialization features. This makes it an ideal point to concentrate on for beginning the scripting process.
When you setup a call to python in C++ every single piece of data that is sent to and received from python must be a PyObject * . In order to make use of the data in C++ from python it has to be converted into the desired data type.
[color="#f0e68c"]To Be Continued[/color]
In the past, I've set specific goals for adding content to my website. It was meant to keep me motivated, to keep things moving forward, and eventually, I was hopping someday that it was going to generate add revenue at some point. When I was initially setting up my server back in 2008, I did pretty well at following a content generation plan for like the first two months. I was doing book reviews and writing code snippets and things. None of the content ended up on the site and most of it sits back in the server archives and probably will never see the light of day.
On the revenue generation front, that was a failed venture. On the pacing and keeping my interest levels peeked, it did it's job at that time.
In that sense, I am going to set a goal to post content to the site, a minimum of once a week. It needs to be relative content to game development of some kind, ideally what I am up to.
Ideally, posts with good content, and possibly something that can be broken up into a series throughout the week. In the past, my gamedev.net journal, and my si.r.o.a.d journal over on blogger were great sources to help keep my thoughts structured and gave me a pulpit to interact with other game developers and such. What I found with those accounts however, was that it really didn't help me with exposure as much as I would have liked. Posting to multiple locations could be helpful by allowing multiple audiences access to the content, and this seems like a good idea. However, now a days, with social media being the norm, you can reach more generic audiences with a simple link and have your content all in one place. This actually allows for easier data management and also gives me control over seeing who is viewing my content and possibly opens up a forum to a potential audience. I will be leaving all previous accounts I setup over the course of the first 10 years of the century, but I will not be updating those accounts any longer.
My soul effort with communicating to the nets will be done directly through my website. I'm hoping that this will allow for less time spent sharing the same ideas and more time spent on game development and the potential discussions spurred by those ideas.
In that vain, I'm going to need to polish the site up a little more. I need to get graphics to replace the navigation links at the top of the site and possibly divide my posts up into more categories. Originally the website was going to be geared towards a community based around the games I developed as well as Troglodyte. This plan has changed at this point and I'm looking more to simply have an interface for me with the rest of the world. This makes more sense as I was spending a lot of time previously developing resources for a community that didn't even exist.
If a community evolves and request for member features are made, it makes more sense to develop them once their is a demand for them.
I also found that there was an issue where if the number of rows exceeded four, then they weren't updating correctly. I fixed this in the new version which you can get Here Animation Exporter 1.5 I apologize to anyone that may have experienced troubles.
Here's a list of features to the update.
V1.5 by Will Canada
Adjusted logic error that was causing frames to, under certain conditions, be drawn outside of the sprite sheet.
In the previous version the script placed the last layer as the first frame, this was counter-intuitive to photoshop, script
now places first layer as first frame.
Fixed Issue where the number of rows wasn't properly scaling beyond a certain threshold.
Corrected spelling error in a user prompt.
Retro Affect is an indie development team comprised of Kyle Pulver, David Carrigg, and Peter Jones. They have a very nice website where they do frequent blogs about the process of creating their current project, a game called Snapshot is a platform style game where you run around and interact with items in the environment by taking pictures. The game looks awesome, but isn't out yet. However, I've been following their progress for a while, and they do weekly blogs about the tools that they use for development.
One such tool, that they released to the web for everyone to use was their RA Animation Exporter script for adobe photoshop.
Follow the link and you can find out the details surrounding the script.
Some people who were downloading the script and attempting to use it were getting errors and when I downloaded it, I was getting the same errors. I attempted to hunt this down and was able to find that certain lines just needed to be included in a try/ catch block. I put those changes in place and the script ran, but images weren't showing up at all when the script was ran, I was just getting a blank 1X1 png image.
It took a little while of going through the code and using alerts, but I was able to find that the getFrame() function that the script used wasn't properly returning the number of frames for some reason, and as such the script had zero frames of animation to use. So, I changed this by prompting the user to enter the number of frames.
I then put in some changes to make the user specify a desired texture width and limited the sprite sheet size to a minimum of 16X16 and maximum of 4096X4096.
With that the script works fine for me. I should also mention however that the accompanying example that comes with the RA script never quite worked the way it should have for me. After messing with it a bit, I think it has to do with the positioning of the images on each animation layer. They are not centered in the image and instead move through out the image. Technically this shouldn't be a problem, so I'm not quite sure why all the frames don't show up using that .psd but have found that if I follow these limitations my version of the script works perfectly.
Canvas sizes must be in powers of 2. (The script actually checks for this and will exit if the canvas sizes aren't set correctly.)
It works best with square canvas sizes, meaning width and height are the same dimensions. 32X32 for example.(This isn't a requirement, but if for some reason you notice undesired results try adjusting your canvas to follow this caveat.)
Center your images on the canvas. This shouldn't be an issue as this is how most sprite sheets are laid out
If, when prompted, you put more or less frames then you actually need, the script is going to allocate for that many frames, so be sure you are accurate. Otherwise, the full animation won't be there, or you're just going to have a lot of empty cells.
You can download my version of the script either from the Retro Affect post at the bottom of the page or from
A big Thanks to Peter Jones from Retro Affect for making the script available in the first place. Before that script, I didn't even know it was possible to script photoshop, so, this introduced me to a whole new bad ass world. Also, thanks for hosting the script on the RA site, and good luck with Snapshot!
So, the new year has already started, even if you weren't ready for it, it is here. With it, is a renewed hope and ambition from within to finish what I have started. This includes having relevant blog posts to share with you inter-webs on a regular basis. As I am still moving to be in a consistent game development mind set this year, I am going to be concentrating on finishing up previous projects and moving onto new a better things by years end.
Here are my goals for 2011:
1. Complete C.F.L. as it was originally meant to be completed, with graphics and sounds and other media.
2. Get the engine into a state that is capable of creating various game projects.
3. Complete my sidescroller.
I am going to be doing all the resources for these two projects this year initially. They may get changed later depending upon interest of other artists, and how well I actually do creating the resources. Conquest For Love shouldn't be too terrible in getting things moving a long as a lot of the content for the text version can easily be migrated over. The time consuming part is going to be getting the engine tools working in the right manner to allow for more expeditious development times.
I had set a goal to have my tools done by this time, but I ended up spending a lot of the down time I had looking for work and then I ended up being out of work for a month, so realistically, the six week time line I had given myself, which was if I worked on the tools full time for six weeks, is pushed back out to a completion of march again.
I've also decided that instead of concentrating fully on my tools, in order to help keep me focused, I'm going to be working on game stuff a long the way as well. This will hopefully allow some motivation to seep through as well as have some content to blog about.
This year, my number one game dev goal is to get at least, one game completed and released. I've been at this for almost eight years, it's high time I finish a game .