When Game Engines Strike

Posted by on January 3, 2014 Comments Off on When Game Engines Strike

So. December’s game did not materialize. Some of this was scheduling. Best laid plans and all that. Partially as well in that after I thought more about the design, I realized that I wasn’t all that excited to create that game. Then! Inspiration! I had an idea that was mostly in line with the original, but considerably better, and I could write it as a test to see if something like this would work well for a mobile programming project.

So, I crack open Unity, and set the project to 2D. Now I have Orthello Pro, but I wanted to take the new 2D stuff in Unity for a spin. I mean, how hard could it be, right? I also wanted to get a little fancy. Since this would be written for Android, and Android devices are pathological about having different screen resolutions, I wanted to program the game field to size itself to the screen at run time.

Algorithm was fairly simple, I wanted the play field divided width wise into 6 chunks, with 4 for the play area and 2 for the score/drop off point. So Screen.Width / 6 (using integer math here, so the decimal is dropped) gave me my chunk size. Play field would be Chunk * 4 in size, and the side bar would get any leftover pixels with Screen.Width – Chunk * 4. I wanted things in a checkerboard pattern, so I needed to know how many rows I could have, so Screen.Height / Chunk gave me that. (Screen.Height – Rows * Chunk) / 2 would give me the offset I need to deal with spare pixels.

Now I know that 1 pixel != 1 unit in Unity. What I did in the past was take a point in screen space and use a Camera.main.ScreentoWorldPoint to figure out how much to scale something. So if I needed a cube to act as a background for a 640×480 screen, then I’d toss (640,480,0) into the Camera call and use 2x the returned value to scale the cube. Easy-peasy.  Of course I’ve found out during this ordeal that’s the hard way of doing it, but I’ll get to that later.  Now sprites should be just as easy.  Right?  No.  Sprites?  They’re bat-**** crazy.

My first attempt at drawing objects in a checker pattern failed horribly and strangely, which is what tipped me off that I had a fundamental flaw in my understanding of things.  So I decided to do some verification to make sure I was understanding Unity sprites correctly.  I took a 64×64 pixel png, tossed it into Unity using the sprite import setting, and tossed it into a scene.  Should be 64 pixels, right?  Wrong, it was 31 pixels.  Or maybe 39×39 if the screen is 800×600.  Needless to say, trying to scale a 64 pixel image by 10 doesn’t take up 100% of the width.  Why Unity, why?

So hence the title, when game engines strike.  The idea that I would place a sprite in a 2D game, and not want that sprite to be pixel perfect on display, is baffling.  I have spent days trying to figure out how Unity internally is handling things to no avail.  I have learned quite a bit so all is not lost, though I’ll save the parts learned for another blog post.  I know it is possible to get pixel-perfect because Orthello has a flag you can check to make it work, so all that’s left is just figuring out how to do that myself.

Lessons Learned from One Game a Month

Posted by on December 14, 2013 No comments

With the year winding down, it’s time to take a look back and see how I did with my goal to complete one game a month. For those that aren’t familiar with the challenge, you can visit www.onegameamonth.com and check it out, but it it’s exactly what it sounds like where you make a game every month.  Theme optional.

So, I managed to get six games out of this.  Three of them came from game jams, one from a 2-hour mini-jam and two done during the month.  Interestingly enough, the ones that I like the best all came from the jams.  The two that were done during the month were….meh.  Both were finished at the last possible moment and were not focused at all.  Then June hit, and I didn’t stay focused enough to enough get a rough game out, and it just went downhill from there.

So…lessons learned?  First, never underestimate the power of scheduling.  In the case of the jams and mini-jam, I had very hard, strict unmovable deadlines that forced me to work swiftly.  There was no time to wool-gather, no time to mess around.  If it wasn’t done it X time, it would never be done, and that was a powerful motivator.

Second is related to scheduling, but not quite the same.  In the case of the jams, I had a very specific time block that was designated ‘game dev time’.  I knew well in advance that these time blocks were to be used for game development.  Not play, not reading, not web-surfacing, game development.  For the two non-jam games, there was no such block designated.  I just had this vague, general idea of ‘Ya I need to make a game this month.  Sometime. Eventually.’  It didn’t work all that well.

How to move forward then?  Well, I’ve got my time block for this month.  Monday is grades, Tuesday I want to work on my UI skills and develop a Starbound editor (awesome game BTW) and on Wednesday I’ll do the December game.  Have the idea already firmly fixed in my mind, so it should be a question of prototype/design/polish to get it hammered out.  For next year I’ll be doing one game with updates each month.  Of course I still need to work out my schedule, but I’ll have time during winter break to figure that out.

In all, even though I failed at getting out 12 games this year, I’m still really glad that I participated.  I learned some more about myself, learned more about the production process, and have some finished games under my belt.  Even if some of them are a bit…lack luster.  So here’s to 2014!  May it be filled with game creation.

Richard Fleming, AKA Languard Gemstrike.

Global Game Jam 2013 Postmortem

Posted by on January 28, 2013 No comments

Well the GGJ 2013 is done and over.   321 sites across 63 countries and over 10,000 people created 3090 games.  At our JCCC site we had 14 jammers including myself create 5 games, with two of those being solo projects.  So overall it was a big success with everyone finishing a game.  So what went right this time and what went wrong?  I’m going to look at this from two point of views; as a producer and as a jammer.  Because really I wore both hats.  So with that…

What Went Right: Producer version

I asked for help.  In the past I’ve ran the events completely solo.  The only reason I could even partially get away with that is because I don’t keep the site open for the full 48 hours, even even with a 8 hour break Friday and Saturday nigh, it was still brutally draining and I was mentally gone by the time Sunday hit.  This year I had a fellow teacher (Thanks Jeff!) cover the Saturday morning shift, which really helped out.  Hopefully next year I can get some more assistance.  Russ.  Looking at you.

Experience does help.  This is the 4th GGJ that I’ve been the site lead on.  For the first I was more team lead than producer, but for the last three I’ve filled a producer roll, helping my teams to ensure their games get made.  Each time has gone a little bit better than the last.  Not sure what I can point to exactly, other than this general sense of ease that I had this time.  The main takeaway on this point is for those that haven’t started yet.  Ya, the first time you try to act as a producer or site organizer you’re going to feel like a headless chicken, but you’ll learn.  It will get better.  But you have to start somewhere.

What Went Wrong: Producer version

Late Start.  This year I started way to late in terms of getting things organized.  I didn’t have the room reserved until the day of which was really taking a big risk.  This impacted a lot of areas from not being able to get more help to not having time to try and find sponsors.  Heck I didn’t even create the site on the GGJ web page until December.  Really need to do better on this one next year.  Related to this was my forgetting to contact facilities management and ask them to leave the AC on in the class room over the weekend.  The room got uncomfortably warm at night both Friday and Saturday because most rooms have the vent system shut off during those times.

Overall Takeaway: Producer version

Practice makes perfect, and I’m starting to get into the swing of this site organize/producer thing.  That said there is still a lot of room for improvement in terms of organization and not leaving things to the last minute.

What Went Right: Jammer version

Scope Control.  Perhaps it was because I just came off the Indie Speed Run where I failed at this horribly, but I did much better at scope control this time.  My original idea had my head filled with visions of a third person action rpg game with sprawling levels, but quickly scaled it down to just the core combat mechanic and focused on getting that implement.  Even then I scaled down the scope even further on Saturday when I realized that I still had to much to do for one person.  Controlling the scope as well as I did is what enabled me to finish.

Leveraging existing assets.  Very little in the game is my own original asset work.  The terrain textures came from the Unity terrain assets package, the skeletons are from bisaniyehocam (how do you even pronounce that?) from the asset store, used Unity’s Gem Shader, terrain layout was generated using the Terrain Toolkit (Unity, why is that hidden now?) and the background music taken from OpenGameArt.org.   Oh and the fonts used mainly came from www.fontstruct.com which is an awesome site for finding and creating fonts.  I did create the model for the crystal heart, the abomination  that is the heart beat bar, and the heart sound effect.  Being solo meant I had to do everything myself, and leveraging existing items like this allowed me to have a game that looks semi-decent as opposed to nothing but untextured cylinders and blocks.

Open to other ideas.  In the past two GGJs I stubbornly kept to my own idea.  I could of course get away with that because I was doing things solo as an organizer.  However I don’t think that it is a coincidence that the only two GGJs that I’ve finished, the first and this last one, were games that had ideas besides my own.  This time around I had an inspiration from the web comic Dominic Deegan, specifically this one.  However one of the ideas tossed out during the design phase was to do a rhythm based game.  I liked that, but still liked my idea as well.  So I combined them.  I think this gave me a more interesting idea to work with, and helped keep my focus late Saturday when exhaustion started kicking in.

What Went Wrong: Jammer version

To much time spent looking at Mixamo.  Not to say that Mixamo is bad, far from it.  Major shout out to them for both an interesting product and supporting the GGJ the way they did!  But between looking at models, looking at animations, and trying to figure out how to use the store because I couldn’t afford to make mistakes, I wasted way, way to much time.  I should have kept to just the Unity store.  And related to this…

To much time spent on sound.  While I am pleased with how my heart sound effect turned out, it spent to much time on it and other sound effects that I didn’t use.  Should have just grabbed the MP3 from the GGJ site and use it.

Overall Takeaway: Jammer version

Controlling your scope and leveraging existing assets can really help keep a project on track.  Of course you have to be careful about both, don’t want to cut out the heart of a project by scoping back too much, and you don’t want to spend so much time looking for existing work that you don’t leave enough time to work on other things.  It gives a very deceptive feeling of accomplishment, a false sense of progress, when you’re surfing the net looking for stuff to use.  Because after all, you are working, right?  Need to watch that.  Also, brainstorming with other people is a very good idea.  This worked well in the Indie Speed Run with my sons, and worked well again here.

So what’s next?  Well there’s still the 12 Games a Year challenge.  I’ll be taking my GGJ project and working it up into a full release to be used for my Feburary game.  Not sure what I’ll do for March, April will depend on when Ludum Dare 26 happens.  Also there’s a local group in the KC area that might do a jam, so who knows.

The games created for our site can be found here: http://globalgamejam.org/sites/2013/johnson-county-community-college/games

Indie Speed Run Post Mortem

Posted by on January 8, 2013 1 comment

So I did the Indie Speed Rune (ISR) (www.indiespeedrun.com) with my two sons, ages 5 and 7, last week.  Fun experience of course, but picked up a few production lessons from it.  Because while we did technically finish, it was bad.  Technical and social issues forced an 11th hour rewrite, and I redesigned and created the entire game as it was submitted in about one hour.  The only thing I was able to salvage was some of the artwork and the very high-level concept.  I hit the upload button with literally 30 seconds to spare, and what was uploaded has a critical bug:  It’s almost impossible to die.  In fact if you just let the game run and do nothing, you never will.  I have cleaned it up a bit, added in a high score (which only works for that game session) and uploaded it to my staff page:  http://staff.jccc.edu/rflemin1/12games/january/

 

The ISR gave all teams two randomized bits, a theme and an element.  In our case the theme was Afterlife and the element was Message in a Bottle.  For what we turned in, you are dead, and have been entertaining yourself by writing messages and floating them down the River of Souls in bottles.  The Grim Reaper has finally had enough, and sent his ghost skulls after you.  You need to toss your bottles at the skulls to drive them away.  And that core does work, mostly.  Just have to ignore the impossible to lose bug I mentioned earlier.

What Went Right:

Fun:
This was a fun project that my sons and I greatly enjoyed doing.  They are very proud of the game they helped to make and enjoyed themselves while working on it.  I have a very thick stack of artwork they generated during the jam, most of which I didn’t get to use, sadly.  But the main point here is that since we were having fun, and not overly worried about impressing anyone else, the work went very smooth.

Design:
Despite their young age, or perhaps because of it, working together to figure out the general story and game mechanics worked really well.  They didn’t deal very will with the highly abstract concept of ‘Afterlife’, all that meant to them was undead or heaven.  Figured undead would be the least controversial  option.  Some of the ideas and mechanics they came up with were rather…random, but in some aspects that worked really well.  I can remember at one point one suggested we have a dragon, the other then jumped on that idea and said it could be a dragon of souls, then back to the first who said the dragon had to be a good guy because dragons deserved to be good too, and I suggested the dragon of souls saved the character from being pulled into the river, and that was the starting point for the story.  There were several other instances where we rifted off each other’s ideas really well.  I firmly belive the final concept we came up with is much more imaginative than what I would have done by myself.

Division of Labor:
Having them work on art while I wrestled with the code and technical aspects worked really well.  Not to mention they got to learn about scanning in documents to a computer, transferring file, and using GIMP to do basic image manipulation.  At the end of the jam I had a flash drive filled with artwork, which is what enabled me to survive the emergency panic redesign.

What Went Wrong:

Scope Control:
I know about this.  I tell my students to watch for this, warn my Global Game Jam participants about this, and I still screwed this up.  The final design idea called for randomly generated levels based on which runes are used to write a message, which you then had to explore and find other runes that you could use.  Of course the levels had to have different enemy types, and there was this epic battle planned against Death and….ya.  Too much.  Trust me I scaled things back, nixed some of their more exuberant ideas, but still didn’t do it enough.  It can be really hard to properly scope something.  Even harder when you’re other two teammates have no idea how much work some things are.  Had I scoped things down to something I felt could be done in several hours and just focused on that, things would have gone much better.

Overestimating your Team/Communication:
Theses two are really intertwined in this case.  For the overestimating issue, I had a 5 and 7 year-old working with me.  There’s a limit in both how well they can focus on a single task and while I had taken that into consideration, I still overestimated a little a bit in this area.  The biggest issue that I ran into was their lack of abstract thinking.  Children that young just don’t do well with abstracts.  My oldest can handle it better, but a 5 year old really struggles with extremely abstract things.  So when I told him to “Go draw some runes” he really struggled with it, and didn’t really produce anything usable.  Compounding this was a lack of communication.  Looking back, I realize I didn’t communicate to them from the start the whole process for getting the art into the game, so several pictures were unusable.  I then had to stop what I was doing, point out the mistake, and send them back to try again.  I also failed to realize that my domain knowledge isn’t their domain knowledge.  I’ve been gaming for a long time, “mystic runes” has been a part of RPG’s since…forever.  Especially since I’ve played all the Ultima series, and read books on actual runes, I know quite a bit about them and can come up with rune designs very easily.  For some reason I though it was sufficient to show my kids a google image search on runes and say “Draw something like that” with no further instruction.

Real Life Compensation:
Real life marches on, regardless of jams.  I had to fix breakfast  lunch and dinner.  I had to let them go when my wife came home so they could work on their Chinese.  They had to have their evening reading time.  While I knew these things were going to happen, I didn’t really think about how much time is spent on them.  I lost at least 8-9 hours on these items, which really hurt.  But the biggest is that my wife teaches at the Greater KC Chinese School, and she had some lesson stuff that had to get done on the second night of the jam.  Only one computer in our house can handle typing up Chinese documents, my main dev machine.  So I got kicked off.  I tried to transfer the project to my laptop, but something went wrong.  I discovered after about an hour of work that the project couldn’t save.  My wife was still working, so I last the entire night.  Oh and I still had to help her in the morning with a few things, which further ate into the time.

Start Time:
The ISR is a little unique, in that teams got to decide when to start the jam.  Once you hit the Go button, you had 48 hours from that moment.  Now in the Global Game Jame, it starts and ends at 5PM.  This means the final stretch of 8-10 hours (depending on when you get up) is during normal waking hours.  I started the ISR at 9AM, which meant the final 12 hours of the ISR was during normal sleeping hours.  Oops.  That was not a good choice.

Final Thoughts:

Had a lot of fun, but things could have went a lot better.  Always keep a close eye on scope, be sure you have a good handle on your team’s capabilities, and make sure you schedule in enough Muphy Law time.  Now to rest up and get ready for the Global Game Jam.

So if Not Random, Then What?

Posted by on November 29, 2011 No comments

So in the previous post, I lay out my argument as to why pure random tables can be bad.  It really depends on the situation.  If this is something the player either must get, or will really want to get, then you need to be careful.  You should always have in mind “It should take at least X time to do this, and no more than Y time.”  Let’s pick on crafting some more.  Let’s say to get a really good weapon crafted, you need high quality ore.  Normal ore happens most of the time when you harvest, and the HQ ore happens only rarely.  I feel as a designer, I should know roughly how long it will take a player to get something.  Here’s what I know about my game:

  • The time cost for harvesting is 30 seconds (this includes harvest time, inventory management, travel between nodes)
  • Average player can harvest for 50 times before inventory is full
  • Town travel time cost is 2 minutes from this zone

OK, now to play with the numbers.  Let’s choose pure random first.  If I say there’s 1 in 100 chance of getting a rare ore, how long is it before I’m reasonably sure the player will get a rare ore?  Well if the player does the activity 250 times, then there is (statistically) a 92% chance the player will get the rare ore.  That’s pretty darn good, so we’ll leave it at that.  That means 125 minutes of harvesting and 10 minutes of traveling, so 135 minutes to get that rare ore.  That’…a long time.  Is that sword worth over two hours of playing?  In two hours of questing/killing, could a combat oriented character get something better?  Of course 8% of your player base still doesn’t have it, and if your game sold like Skyrim did (3.5 million in two days) that means 280k players have no rare ore to show for the effort.

So let’s look at the problem a little differently.  I want this sword to take no less than 20 minutes, and no more than 30 minutes to complete.  Punching in some numbers, if I have the rare ore drop 1/200 times, in 40 harvests or 20 minutes, 81% of my players will not have gotten the ore.  That sounds reasonable.  Now if I boost the chance of the ore dropping by 10 every harvest after the 40th, by the 60th harvest I have a 100% chance of the ore dropping.  Of course every time the ore is dropped, the drop rate and the harvest counter needs to be reset.

Now why do I feel this is a better way of handling things?  After all it is more complex, and complexity can lead to errors. For me it comes down to control.  As a designer, I should have a strong grip on how long certain actions should take the player.  If I don’t, it becomes harder to design good play experiences.  Not impossible of course, just harder.  If I have a solid understanding of how long it will take a crafter to get a good weapon, I can use that to balance how long it will take a combat oriented character to earn a similar weapon, ensuring that both paths feel equally valid.

Hmm, a little abrupt on the ending, but I really want to end this here.  So I will.

Random isn’t all that for loot drops

Posted by on November 7, 2011 No comments

This is something that I’ve been chewing on for a bit.  Is a pure random loot table really all that great?  I’m beginning to think not.  Let’s establish some things first.  Let us assume you have a good random number generator (RNG) to start.  Without a good RNG all of this is moot anyways as your players will figure it out and abuse it.  Second is that you either have a large list of items you want to distribute to your players, you have items that you rarely want to distribute, or both.  If you just have a small list you’re probably fine with pure random.  Third is that you have a large player base, 100k+ at least.  More is better because ‘randomness’ isn’t really visible in small sample sizes.  Now let’s take a look at some numbers.

Assume 10 items in the list, with the ‘ultra rare’ only occurring with a 1/10 chance.  Keep in mind this does not mean you will get the item in 10 drops.  Each time you get the drop (kill, chest, vase, reward, doesn’t matter) there is a 9/10, or a 0.9 chance of not getting it.  So if I want to find the odds of this happening 10 times in a row, I’d do 9/10 * 9/10 * 9/10 and so on ten times, or 0.9^10 which equals 0.349 or 34.9%.  That’s pretty good odds that you won’t get your item in 10 drops.  In 20 drops though this drops to 12.1%, and at 30 drops you’ve plummeted down to 4.2% odds of not getting the special item.  This is why I say a small list can get away with pure random.  Depending on the pacing of course, getting 30 chances at a drop shouldn’t take all that long.

But what happens when that is increased?  Say, we have a really powerful item that we only want to have a 1/100 or 1% chance of dropping?  It is very easy for the mind to think “hmm, that means it will take the player 100 tries to get this item, which will be a bit of effort, but then this is the uber item”.  This is bad thinking.  First let’s extend the example above.  If there’s a 1% chance of getting it, that means there’s a 99% chance of not getting it.  So that 100 tries that takes a while would result in  (99/100)^100 = 36.6% chance of not getting it.  That means over one-third of your player base has not received the item you intended them to receive with that level of effort.  That can cause problems because there’s a strong chance that the unlucky 1/3 of your players are going to feel some strong resentment that they are so unlucky.  They will blame you, the developer of the game, not the RNG.  Oh, and there’s the fact that about 40% of your player base got the item with 1/2 the expected effort.  (99/100)^50 = 60.5% not getting it, so 39.5% getting it.

Honestly, this does cause problems.  They may have changed things, I haven’t played in a long time, but in Age of Conan the crafting skills suffered from this.  At launch there was a flat percentage chance of a rare resource dropping when gathering.  The result of this was some players had an abundance of rare mats, and some players took a very, very long time to get their rare mats.  Which you needed to advance your skills.  Which you had to gather yourself, you couldn’t buy it and turn it in for the quest.  Much frustration over this, as I tended to be in the unlucky group.

OK, so pure random can bad, so what’s the answer?  That shall be in the next post.

Crushingly Small

Posted by on October 24, 2011 No comments

I started this unsure on what to write about.  When I look around the web, when I look at what others have done, it always feels like what I have done is small.  Crushingly small.  Notch and Minecraft.  The Terraria team.  Todd Howard and company and Elder Scrolls.  All these people are close to my age, and I feel their accomplishments dwarf mine.  What could I write about that would add to the gaming industry?

As I sat back thinking, staring at this blank blog entry, an intense track came on.  Refuse/Resist from Apocalyptica.  I sat back, and just listened to the intense sound of metal cellos.  Drank some tea.  Let my mind flow.  Yes I drink tea and meditate to metal.  Perhaps my accomplishments aren’t as epic, but they are mine.  I’ve got many ideas, some even tested out in ultra-rough prototypes.  Screw it, just write, who cares?  That’s mostly how the thought process went.  And that’s I guess the message of this post for my students.  If you’re driven to improve, you’ll always be able to find fault in your work, find others who eclipse you.  But you also need to be able to turn things back around and say ‘This is mine.  It might have flaws, and might not be the most epic thing out there, but dang it I’m proud to say it’s mine.’

So ya, this blog is mine.  Not the most rocking thing out there, but it is out there.

First Post

Posted by on September 16, 2011 No comments

Still getting things setup.