Tuesday, September 27, 2016

Keltar's Lair

So I got a little side tracked the last few days and missed my original date for releasing my two week game.  The time was not spent on the game but with general life and family stuff so I'm not going to worry too much about it.  So without further ado I posted the game I have been working for my two week game project to itch.io you can see the link below.  I will do another post when I have more time as kind of a short postmortem about the experience because I found it really interesting.

Tuesday, September 13, 2016

Incremental Development

So my recent exploration of tackling my personal game projects in a different way has been paying off massive ways.  I have been far more productive and creative.  With that comes excitement for the project and even more excitement to show people the game because it is a constant state of completion.  I was digging around the internet more and watching programming talks and reading papers on software creation when I came across one that I had heard about but never read.  It is a paper called "No Silver Bullet" by Fred Brooks.  It is a wonder paper and I was super excited when I came across this section towards the end because it turns out it is exactly the approach I have been taking and I have been experiencing the same results from a personal and production level.

Incremental development--grow, don't build, software. I still remember the jolt I felt in 1958 when I first heard a friend talk about building a program, as opposed to writing one. In a flash he broadened my whole view of the software process. The metaphor shift was powerful, and accurate. Today we understand how like other building processes the construction of software is, and we freely use other elements of the metaphor, such as specifications, assembly of components, and scaffolding.
The building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be specified accurately in advance, and too complex to be built faultlessly, then we must take a radically different approach.
Let us turn nature and study complexity in living things, instead of just the dead works of man. Here we find constructs whose complexities thrill us with awe. The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and selfrenewing. The secret is that it is grown, not built.
So it must be with our software-systems. Some years ago Harlan Mills proposed that any software system should be grown by incremental development. [10] That is, the system should first be made to run, even if it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit, it should be fleshed out, with the subprograms in turn being developed--into actions or calls to empty stubs in the level below.
I have seen most dramatic results since I began urging this technique on the project builders in my Software Engineering Laboratory class. Nothing in the past decade has so radically changed my own practice, or its effectiveness. The approach necessitates top-down design, for it is a top-down growing of the software. It allows easy backtracking. It lends itself to early prototypes. Each added function and new provision for more complex data or circumstances grows organically out of what is already there.
The morale effects are startling. Enthusiasm jumps when there is a running system, even a simple one. Efforts redouble when the first picture from a new graphics software system appears on the screen, even if it is only a rectangle. One always has, at every stage in the process, a working system. I find that teams can grow much more complex entities in four months than they can build.
The same benefits can be realized on large projects as on my small ones. [11]

I found this piece of the paper to really jump out for me, but I think that is because it most closley matches my mental thinking lately.  However there are absolute gems in the entire paper so treat yoru self and give it a good read, and then another read and another.  My hope is that it might kick start something exciting for your own work too!

Sunday, September 11, 2016

Solve For The Actual Problem

Recently I posted about how I created a finished game loop right away for my side game project.  I have continued to work in the same way I talked about then and have had time to reflect on why this is working for me.  Simply put I solved my biggest problem first.  Everyone and every game has different problems, but sitting down and being honest with myself at the very start allowed me to address this right away.

As progress moves forward I still maintain this reflective thought process.  I look at what is actually stopping or slowing down my progress and then I solve that problem, in the most simple way as I can.  That means I solve only that problem and not problems that I think will arise down the road.  These are also tending to be my workflow problems so completely unique to my current situation.  For example when I completed the finished game loop I had a few different game objects like triggers to enter new rooms, player spawners and dart traps.  When I made these objects they were put together in the most simple way as possible so I hand built each and everyone of them and just duplicated them around the room.  Then in a new room I would hand build them again and repeat.  This only took a few minutes to do and for the finished game loop I only had two rooms, which was the bare minimum to solve the problem I was working on at the time.

Then when it was time to add in some more rooms I found my self slowing down.  I would think of an idea I wanted to see and start hand building the objects.  While this only took a few minutes after about two rooms I was starting to get bored with doing this over and over.  It was tedious and repetitive work and I didn't want to do it.  So I spent the time thinking about how it was taking time away from actual design work.  So I took the time and built some quick macro like buttons to just give me each of my game objects already setup in a single button click.  Then I only needed to hit one button, and place the object where I wanted.  Automating even the short setup like this also meant I removed any human error from the setup process.

I found my self trying out more gameplay ideas quicker then before and more willing to throw out the work completely because it now took no time to start building it up again.  I was in the iteration loop of actually working on gameplay.  I had solved my actual problem.  Now that I was able to make rooms faster and easier I hit the next problem and it was one I had not even thought about.  While I keep making new rooms the list of rooms is growing really quickly.  The room transition triggers use this list to select the room to transition to and wit the list getting bigger it is harder to make sure I pick the correct room to transition too.  This problem is only going to get worse the larger the game gets.  I had a new problem.

Just like before I thought about the actual issue and how to solve it in the easiest way possible.  I thought, well if I am tagging the trigger with the room why can't I add a button right there by the room tag that takes me to that room in editor.  It was simple enough to put in, only a few lines of code that took me maybe 5 minutes.  A side effect of this is I can easily follow the flow of dungeon that the player will take in editor using the actual game data so I don't even have to leave the editor to make sure the room links are linking to correct rooms.  Now I can quickly make new rooms with new gameplay, link them together AND quickly test that they link together correctly.  

So simply put having this kind of honest conversation with my self during the development cycle is a huge productivity booster.  It is also exposing the actual problems that need to be solved right then and there to move the entire game forward, not just a single part of the it.  It is about being honest with your self and looking for the actual problem in that moment in time that you are facing.  Each problem I encounter is unique to my game, my tools, my data, my setup and my workflow.  So spend the time working to help yourself during the development cycle and spend the time to think about the problem and how to solve it, it will speed you up the long run.

Wednesday, September 7, 2016

Finish The Game First?

Okay so recently I decided to work on my game development and design skills.  I have a horde of unfinished projects on my hard drive.  I have learned so much from working on each and everyone of them, except how to get better at finishing the game.  I want to fix this so I decided to take a different approach than anything I had ever done before.  I decided to start by making a finished game.

Let me explain what I mean.  On my current project I did something completely different than before.  I made the most simple version of the finished game as quickly as I could.  Not a prototype but an actual finished game...not a good game but a finished from start to end game.  You start at the main menu, enter the game, reach a goal get the win screen or die and get the game over screen.  It's simple but the from the point of view from the player it is a completable game.  All in all it took my 4 hours and gave me something I can look at and make decisions on.  Its kind of like when an artist starts with a blank canvas the first thing they do is get rid of all the white so they can start putting things in and making decisions on what is there.  I wanted to get something to look at from the point of view of the player as soon as possible and keep it in this finished state during the entire development cycle.

This way I have a complete view of the entire game at all times.  I have my start and finish states and now as I add to the game I have a better idea where things need to go and what needs to be added next.  Increase in scope or feature creep is now easier to control because they become part of the design process.  If you have ever worked on a game or any creative project you know that things change as you work.  Instead of fighting this why not find ways to use it to make something better.  When you can view the entire project as a completed game it is easier to look at it and find ways to make it better right then and there then to think of solving hypothetical situations of gameplay you can't see yet.  We have all reached the end of a project and thought about all the things we could do to make it better now that it is done but there just isn't enough time to change or polish it.  Well the idea is to get you to that point as quickly as possible and keep you there for the course of development.

That is the key to this way of working.  The game must always be in a completed state at all times.  What this forces me to do is keep me focused on bite sized chunks that improve the game and are quick to implement from start to finish.  Since the entire game is structured I can easily see where things should be placed.  It is kind of like building a sandwich the bread is the completed game and the new bits I add are the meat and veggies each new layer making the sandwich bigger and tastier.  Now this is all just my own opinion and one that I have found helpful to keep me focused on the right things.  Not everyone will find this useful and most will probably think it is the dumbest thing they have ever read, but there might  be one person out there like that this clicks with and to that person I say give it a shot you might have fun.

I'll post again in a week or two after I have done some more work like this and give an update on my experience.

All the best!