Hello, hello, hello my dear interwebs!
Exams are finally over and done with and I can get back to developing posting and generally being awesome.
A couple news items first though.
1 Concentric happened. Made a prototype for a casual puzzle game with bubbles and jewels. Definitely a keeper, but it's not that developed. The rest of the Con was awesome. I should know; I spent most of it playing games and shirking on the game jam. Don't give me that look. I needed a fun weekend, and boy did I get one.
2 I just became president of UVic Gamedev. It's an honor. Thank you to everyone who voted for me, and I look forward to working with you to make out club a thousand times awesomer than it already is. Congrats to Marta for VP. It's gonna be great semester.
3 ...? Oh forget the numbers, this is just the rest of the post anyway.
As a way of introducing myself and the club to new members in January, I have challenged myself to make a complete game (as in menus, high scores, few bugs, and impressive tech) over the christmas holiday. I'm cheating a bit by using game maker, but it will make the art and sound integration way easier than trying to do it from scratch.
The pitch is to have a game where the player sprite moves along a curved path. The player will exchange projectile fire with some toer like enemies in fixed positions while they travel the paths and will have to avoid the incoming attacks. I haven't quite flushed out the victory conditions yet, but there's plenty of ways to use the basic mechanics so I can leave that until the game is a little clearer.
Besides, I already have plenty to figure out. Drawing and following curves in game maker is no easy task. My plan is to use a bezier spline, but first I need to learn a bit more about them. I spent most of this afternoon migrating some point moving code (and a lot of other extra code, because course projects are spagetti-code nightmares) into a bezier spline drawer and I can now play with the points in a 7 point curve to se what kinds of shapes different arrangements will produce.
One of the other things I want to experiment with in this project is video posting. Fingers crossed, I'll be able to do some screen captures and show you the prototype as it gets developed. I hope to get the first video posted this weekend.
Now before anyone asks, no I haven't forgotten about stratagem. It's still my back burner project, but the scope of it means I don't have time do constantly pour into it just for the sake of it. I also want to be able to leave UVic with a large portfolio of playable prototypes, and stratagem isn't worth much good if it's the only thing I have and it isn't even finished. Not to mention the 2013 game a month challenge that's been circulating on the gamedev page. I want to have a strong showing for that. So all in all, I want to release roughly one new small game a month to build my roster, and have stratagem as a masterpiece still in development. That being said, I want it playable so I can use it as one of the summer month entries. That way it will be presentable when I'm searching for a co-op again in 4 months.
So that's where I'm at right now. Anyone from UVic gamedev, and anywhere else for that matter is welcome to jam right along over the holiday. I would love it if we had more than one project to show off when December starts.
So long for now. I have to go read about spines. And sleep. Maybe.
Thursday 20 December 2012
Saturday 20 October 2012
Bu-Bump. Bu-Bump. Bu-Bump.
It's alive interwebs! It's ALIVE!!!
I realize that doesn't make much sense out of context, so let me backup.
Firstly, I am obligated to tell you that the rumours of my death have been greatly exaggerated. I had a lot of things to balance as this semester at UVic began: I moved back to my old house, then into my new one two weeks later, I've been organizing my design project for next semester, and trying to keep up with my coursework. Unfortunately, I kind of failed that last one, and the last couple weeks have been an un-punctuated cluster-f*#$.
But at last I have emerged from under the oceans of work, and just in time for Jam'oween at UVic. And of course, with my head above water, I blew the dust off Eclipse, opened up Stratagem, and got back to work.
I have to be honest, it's taken me almost two days to comprehend my old code. This is partly because of my poor documentation, but also because I was halfway through testing something when I stopped working on it, and there are a number of vestigial and half implemented constructs cluttering up my screen.
But among the disabled print statements and half sarcastic notes to myself, there were two statements just above the parse_order method:
Man it's good to be back.
I realize that doesn't make much sense out of context, so let me backup.
Firstly, I am obligated to tell you that the rumours of my death have been greatly exaggerated. I had a lot of things to balance as this semester at UVic began: I moved back to my old house, then into my new one two weeks later, I've been organizing my design project for next semester, and trying to keep up with my coursework. Unfortunately, I kind of failed that last one, and the last couple weeks have been an un-punctuated cluster-f*#$.
But at last I have emerged from under the oceans of work, and just in time for Jam'oween at UVic. And of course, with my head above water, I blew the dust off Eclipse, opened up Stratagem, and got back to work.
I have to be honest, it's taken me almost two days to comprehend my old code. This is partly because of my poor documentation, but also because I was halfway through testing something when I stopped working on it, and there are a number of vestigial and half implemented constructs cluttering up my screen.
But among the disabled print statements and half sarcastic notes to myself, there were two statements just above the parse_order method:
#This is the key. When you have tested this, the prototype is ready for further design.
#Until then, CODE YOUR ASS OFF!!!!
And I have.
As of tonight, the parse_order method, the beating heart of the system, can take a series of orders, created from json strings, and execute the operations seamlessly on the board, producing a series of json statements that detail the individual results of the orders as they occurred. The key part of the engine is running.
That being said, the server side development is still a ways away from being able to support a client side, and I'm really not sure how to set that up yet. This weekend's goal is now to create the data structures that go around the game on the server. This is mostly the player order lists and the single order list that the player lists will combine to form. There is also the matter of how the board will be stored and sent to the client for viewing, but that shouldn't be too difficult. Hopefully I will be able to leave the jam with a ruby server side for a prototype version and a javascript program that can send and receive a json string, in at least a primitive fashion. If I have an awesome weekend, I'd like to be able to print the board and list the turn results. Orders can be done in text form for now.
But the first thing to do tomorrow is something my colleagues have been asking for for quite a while. I will at last be throwing the code onto github. This is partly as a source control and management aide to myself, but also to allow me to start showing off the early prototype, and getting some feedback on the technical side. All I want to do first is clean up and comment the existing code base for newcomers, and myself the next time I go a month without working on this.
Of course, all of that will be difficult to do without sleep, so goodbye for now. I'll talk more about the system after the jam when the code is up.
Oh one quick piece of advice: If you ever find yourself writing a note to yourself tell yourself to "code your ass off," be specific as to what it is you want this coding to be on. Otherwise you wind up looking at a spline editor/interpolator and a link layer protocol for two sleepless weeks.
Man it's good to be back.
Thursday 6 September 2012
OhMyGodICompletelyForgotToPostAboutOrcaJam
Generic greeting interwebs!
I was just filling an hour and I realized I should do 3 things with my blog while I have a minute.
First of all I'd like to assure all of you that I am still alive, and have merely been very busy. Repeat: Not dead, just busy.
Second Strategem Update: I was too busy to work on stratagem the last few weeks, but by next week, I should be able to pull myself out of my little quagmire very soon. I did get some game development done on another project, which brings me seamlessly to my third topic, and that is....
ORCAJAM!!
I really meant to post during or after orca jam, but I had difficulty doing so while I made up the sleep debt from the event. But since I have time now, here's what I remember.
Night 1
After some confusion, I set up the brick as my development machine with flash develop fully functional, and my mac riding shotgun for internet access. I had already settled on a project which was an attempt to make a simple platformer in a very non sequitur style. It's main features were:
I was just filling an hour and I realized I should do 3 things with my blog while I have a minute.
First of all I'd like to assure all of you that I am still alive, and have merely been very busy. Repeat: Not dead, just busy.
Second Strategem Update: I was too busy to work on stratagem the last few weeks, but by next week, I should be able to pull myself out of my little quagmire very soon. I did get some game development done on another project, which brings me seamlessly to my third topic, and that is....
ORCAJAM!!
I really meant to post during or after orca jam, but I had difficulty doing so while I made up the sleep debt from the event. But since I have time now, here's what I remember.
Night 1
After some confusion, I set up the brick as my development machine with flash develop fully functional, and my mac riding shotgun for internet access. I had already settled on a project which was an attempt to make a simple platformer in a very non sequitur style. It's main features were:
- The ChiliPiper, the player character who ran around and jumped with floaty physics and a bagpipe that could shoot flaming chili peppers out the top of it.
- Flaming Chili Peppers, flaming projectiles as dangerous to the player as to the mobs who littered the level.
- The orca. This had nothing to do with the orca jam, but is instead pulled out of a dream I had in which I was chased out of the ocean and back to my house by a killer whale with human legs. In keeping with that, the orca relentlessly chases the player and cannot be damaged by the chili peppers and will kill the player by touching them.
- Syrup Mobs, a last minute integration of the maple syrup theme for the game jam. Evolution was also a theme for the jam, but I felt the whale with legs had that covered. But I digress. The syrup mobs are generic bad guys who behave like red koopas and wil kill the player on contact and be killed by a chili pepper.
- Solid platforms, ladders, one way platforms, slopes, moving platforms, and of course, an exit.
- One level as proof of concept.
And with that I started building. First I programmed a rudimentary physics system for falling until something hit the floor, got the player jumping, and then I set about creating the one way platform and the solid platform. This was the first time I'd really done anything like this, so it took a while. I was working on the solid platform responses when I went home for the night. It was late.
Night 2
Got up early and beat the crowd in. I was there by 7 or 8 or something. I had been having some sort of problem with the solid block, although I can't remember what it was. Anyway, the night before it seemed like an endless bug, but when I came in that morning, I fixed it in about 10 minutes. Never under estimate the value of sleep.
Next I got the ladder working and then moved on to a massive refactoring job. I took the player and made it a subclass of Actor and then created the chili peppers, syrup mobs, and nightmare orca as other actors. This took most of the day, but you should know, I was a bit distracted. Somewhere between this day and the next, I set up a game reset function by keeping a list of all the actors in the scene. When the game ends, all the actors are deleted, and then the system re-creates the player, orca, and enemies.
Scope is the hardest thing to control at a game jam, but you won't finish anything if you aren't willing to cut stuff. I dropped slopes, moving platforms, and anything other than the two platforms I had and the ladder.
I may have had the music going that night, or I did it the next morning, either way, I came to the conclusion that I had all the components I needed to make the prototype. Now I just needed actual sprites (hitbox sized coloured squares had been standing in), proper victory, orca AI, and a level. I outlined the basic AI for the orca that evening, vowing to complete it in the morning, then headed for the bus.
What followed was a bit of a gong show. I started penciling out the level as soon as I had enough light and was so engrossed in this task that I missed my stop and got off several blocks later, winding up lost on a street in Esquimalt with in the middle of the night. So much for getting home early. I kept walking until I hit the 14 going the other way out by admirals, took it back to my usual stop and made it home for about 1:00. At least I didn't have to walk the full way.
Last Day
I admit to sleeping in a bit the last morning, but I still beat most of the crowd in. I set to work on the orca AI and got done a basic system. Then I built the level. That wasn't difficult, just tedious. After that I marshalled the services of Marta Ligocki who generously provided sprite art with simple animations. It took an odd combination of game maker and Flashpunk to convert them into sprite sheets, but when it was finally working, it was awesome.
In the final moments, I got the start and restart text going, and debugged the Whale. When time ran out, I had a game with floaty physics in which the player is almost always killed by a merciless killer whale. Unfair? Yes, but playable, and therefore complete.
Anyway, I accomplished my major goals. I can confidently say I know some Flashpunk, and I can try flash normal for my next project. I have been to the orca jam.
On a final note, a funny thing happened on the last night. Even though I badly needed to sleep, I was driven to get on Ruby and start implementing Flashpunk infrastructure and creating Tetris in Gosu. I didn't finish it, but I went for a good 2 hours with no deadline, no pressure, no instructions. It was very out of character. It's moments like that that give me hope for myself as a developer.
And now, I believe I have been at this for enough time today time to post.
Thanks again for reading interwebs, and please comment. I feel like I'm talking to the wall....
Tuesday 21 August 2012
One Mythical Man-Month Later
Good evening interwebs!
As some of you may have guessed from the title, I have just finished reading "The Mythical Man-Month" by Fred Brooks. I can't remember exactly when I started reading it, but I think it's been about a month. For the record, while I generally don't read things very fast, this only took a month because it was read almost exclusively while on the bus.
I must say, I hope that Mr. Brooks has come to appreciate the humor to be found in reading the book today. The fact that it's first listed copyright is in 1972 would make it 40 years old and would make the images of prehistoric creatures on its cover terribly ironic. There is an underlying hilarity in the juxtaposition of the books wisdom, which is just as applicable today as it was 40 years ago, and it's technical land marks, which come from a time long ago when fortran was advanced and programming in assembly was common practice; when computers needed operators, scheduled machine time, and occasionally lubrication; and when a text editor was a business luxury in the same vein as an in office pool. To give you an idea of what I'm talking about, frequent explanations of the complexity of programming systems made reference to overlays. I asked around and no one knew what they were off hand. When we looked it up, it was pretty close to what I had been thinking: overlays were basically virtual memory for storing the executable code. Not the data, the code itself. Today, the entire program usually just sits on one end of the stack. This is back when ram was measured in kilobytes. KILOBYTES!!!!
Anyway, I said briefly that the books wisdom transcends it's technological references (though not in those exact words), and it does. Having read it, I am forced to look at my own work, both professional and academic, in terms of the surgical team and the architect, the implementation and the design. Looking at stratagem this way is, admittedly, a bit weird, since the dev team consists entirely of me, myself and I (the big three). All at once I am forced to play the roles of manager, architect, surgeon, toolsmith, language lawyer, and secretary. On the upside, interteam communication is almost detrimentally easy. For the most part, I've stuck to playing the architect, at least until I have a clearer specification done, but in time I will be switching hats.
I heartily recommend this book to anyone who will be working in a group software project, or even around one (psst that means ALL my fellow gamedev people). Brooks' style makes for an excellent read, and while a lot of the technical references were a bit garbled due to age, I never had to struggle to understand the point. It's easy to see why this book is one of the holy scriptures of software engineering.
I might talk a bit more about this in the future, but I really have to get to bed.
So thank you thank you readers for your reading, thank you Colton for lending me the book, and a big thank you to Mr. Brooks.
Oh and thank you to my commenters, whom I hope will someday number more than one.
Goodnight.
As some of you may have guessed from the title, I have just finished reading "The Mythical Man-Month" by Fred Brooks. I can't remember exactly when I started reading it, but I think it's been about a month. For the record, while I generally don't read things very fast, this only took a month because it was read almost exclusively while on the bus.
I must say, I hope that Mr. Brooks has come to appreciate the humor to be found in reading the book today. The fact that it's first listed copyright is in 1972 would make it 40 years old and would make the images of prehistoric creatures on its cover terribly ironic. There is an underlying hilarity in the juxtaposition of the books wisdom, which is just as applicable today as it was 40 years ago, and it's technical land marks, which come from a time long ago when fortran was advanced and programming in assembly was common practice; when computers needed operators, scheduled machine time, and occasionally lubrication; and when a text editor was a business luxury in the same vein as an in office pool. To give you an idea of what I'm talking about, frequent explanations of the complexity of programming systems made reference to overlays. I asked around and no one knew what they were off hand. When we looked it up, it was pretty close to what I had been thinking: overlays were basically virtual memory for storing the executable code. Not the data, the code itself. Today, the entire program usually just sits on one end of the stack. This is back when ram was measured in kilobytes. KILOBYTES!!!!
Anyway, I said briefly that the books wisdom transcends it's technological references (though not in those exact words), and it does. Having read it, I am forced to look at my own work, both professional and academic, in terms of the surgical team and the architect, the implementation and the design. Looking at stratagem this way is, admittedly, a bit weird, since the dev team consists entirely of me, myself and I (the big three). All at once I am forced to play the roles of manager, architect, surgeon, toolsmith, language lawyer, and secretary. On the upside, interteam communication is almost detrimentally easy. For the most part, I've stuck to playing the architect, at least until I have a clearer specification done, but in time I will be switching hats.
I heartily recommend this book to anyone who will be working in a group software project, or even around one (psst that means ALL my fellow gamedev people). Brooks' style makes for an excellent read, and while a lot of the technical references were a bit garbled due to age, I never had to struggle to understand the point. It's easy to see why this book is one of the holy scriptures of software engineering.
I might talk a bit more about this in the future, but I really have to get to bed.
So thank you thank you readers for your reading, thank you Colton for lending me the book, and a big thank you to Mr. Brooks.
Oh and thank you to my commenters, whom I hope will someday number more than one.
Goodnight.
Monday 20 August 2012
Press-Ganged
Well interwebs, it's official!
No, I haven't got any demonstrable software for stratagem yet. This post is completely unrelated. No today, I instead cave to vast amounts of peer pressure (and industry pressure) and bring my old windows machine, henceforth to be referred to as, "the brick," back into service and learn flash.
Two things have compelled me to do this.
Firstly, I am always intent on keeping up with my fellow gamedevs, and there has been a collective realization that we all need flash in our respective tool boxes. Not wanting to fall behind, I have have made it the top of my temporary priority list.
Secondly, orca jam is coming up this weekend. As my good buddy Colton Philips pointed out, a serious game jam is a great opportunity to learn a new tool. I have a simple twist on a platformer in mind and I want to learn flash quickly enough to implement it at the jam.
While I'd like to do this from the ground up and really understand flash, I don't have all the time in the world, so I'm taking a bit of a shortcut for this weekend. Flashpunk is a collection of libraries specifically for game creation that also has a good tutorial. This seems to be a good temporary stand in for a detailed understanding of the underlying features, at least for this first run.
And this brings me back to the original point of this post. As I have been reminded every time I have looked at flash in the past, Flashdevelop is the editor of choice, and its installation is step 1 of Flashpunk's tutorials. However, there is no Mac version. And this my lovely readers is why I have the task of dusting off the brick and reacquainting myself with the burden of carrying it around (I think the air has spoiled me a bit in that regard).
I'm not a mac fanboy by any stretch of the imagination, and a windows partition was always planned in to my original decision to buy a mac in the first place. On paper, I could have the best of both worlds: Mac for sleek, fast running professional things, and Windows for fun times and anything I couldn't get a mac version of. However, I underestimated my memory needs, and windows 7 is unreasonably large, leaving me caught with two equally unattractive options. Go through the painstaking process of installing windows xp on my mac and accept that the compatibility will only extend to old software created before about 2011, or fork ove the cash necessary to upgrade my hard drive. Money is a bit tight right now, but I don't want to go backwards, so I have resolved to take the second option as soon as it becomes viable.
Until then, I'll just have to make do with the brick and dream of the day when I will at last be able to play dragon age origins. Until then, NO SPOILERS!
Anyway this rant has sufficiently distracted my while my laundry runs and flash develop installs itself, So I must be getting back to work.
Before I go, I should mention that I have started a bare bones stratagem project in eclipse and will be tending to it as time allows, but it's all scaffolding with nothing operational just yet. Big things take a while to get moving. That's just physics.
Later!
No, I haven't got any demonstrable software for stratagem yet. This post is completely unrelated. No today, I instead cave to vast amounts of peer pressure (and industry pressure) and bring my old windows machine, henceforth to be referred to as, "the brick," back into service and learn flash.
Two things have compelled me to do this.
Firstly, I am always intent on keeping up with my fellow gamedevs, and there has been a collective realization that we all need flash in our respective tool boxes. Not wanting to fall behind, I have have made it the top of my temporary priority list.
Secondly, orca jam is coming up this weekend. As my good buddy Colton Philips pointed out, a serious game jam is a great opportunity to learn a new tool. I have a simple twist on a platformer in mind and I want to learn flash quickly enough to implement it at the jam.
While I'd like to do this from the ground up and really understand flash, I don't have all the time in the world, so I'm taking a bit of a shortcut for this weekend. Flashpunk is a collection of libraries specifically for game creation that also has a good tutorial. This seems to be a good temporary stand in for a detailed understanding of the underlying features, at least for this first run.
And this brings me back to the original point of this post. As I have been reminded every time I have looked at flash in the past, Flashdevelop is the editor of choice, and its installation is step 1 of Flashpunk's tutorials. However, there is no Mac version. And this my lovely readers is why I have the task of dusting off the brick and reacquainting myself with the burden of carrying it around (I think the air has spoiled me a bit in that regard).
I'm not a mac fanboy by any stretch of the imagination, and a windows partition was always planned in to my original decision to buy a mac in the first place. On paper, I could have the best of both worlds: Mac for sleek, fast running professional things, and Windows for fun times and anything I couldn't get a mac version of. However, I underestimated my memory needs, and windows 7 is unreasonably large, leaving me caught with two equally unattractive options. Go through the painstaking process of installing windows xp on my mac and accept that the compatibility will only extend to old software created before about 2011, or fork ove the cash necessary to upgrade my hard drive. Money is a bit tight right now, but I don't want to go backwards, so I have resolved to take the second option as soon as it becomes viable.
Until then, I'll just have to make do with the brick and dream of the day when I will at last be able to play dragon age origins. Until then, NO SPOILERS!
Anyway this rant has sufficiently distracted my while my laundry runs and flash develop installs itself, So I must be getting back to work.
Before I go, I should mention that I have started a bare bones stratagem project in eclipse and will be tending to it as time allows, but it's all scaffolding with nothing operational just yet. Big things take a while to get moving. That's just physics.
Later!
Sunday 12 August 2012
Generation 2 Results
Hello again interwebs.
I'm a little tired but I wanted to do this while it was still fresh in my head.
The cards were largely a success and resulted in fewer invalid orders and less confusion, however the internal notation was still confusing and the slot arrangement created confusion about separation. The lower ease of use on the cards also artificially slowed gameplay. One suggestion was to replace the eight slots with 3 slots and then stack tokens inside them.
Symbolic order explanations were largely a dud, as were the token requirement lists, but these may be attributable to lack of explanation and no legend. I'll try it again with better documentation.
The lack of the film reel does not appear to be a problem. Players can understand the turn order as they arrange their own cards. In general the system now has a learning time of about 4 rounds.
The increase in the number of units (now 5 per team), the size of the board and the new order sets have made the game more playable and more interesting. Archers are now among the more powerful units, however infantry are still under powered. The shot saving system needs to be closely evaluated to avoid over stacking. It might be ok with better clarification, or it may need to be nerfed.
What definitely needs to be nerfed are the base damages for the archers. Originally I wanted archers to always be able to deal some damage, but now I think it may be wise to move both the base damages to 5 and force players to use larger bonuses to overcome armour. Speaking of which, bonuses are much clearer with the new cards. There has been some concern about the range of archers on a small board but I believe that the damage reduction should fix this and future versions should add more units to distract them.
The size of the board does keep coming up as a lingering problem, even with the increase to a standard chess board. However the amount of wall has made for an interesting defence against cavalry and in general, I think it actually adds to the depth of strategy. Also, a lot of the problems revolve around the archer's ability to hit the entire board in most cases, which will be less of a problem when archers are less powerful.
As mentioned before, infantry still seem to be a waste of space. They're getting more useful though (I saw a knight get shredded by clipping two threat zones before it had a chance to hurt anything. This seriously tilted the late game). The biggest waste with infantry right now is the ready order which adds only a tiny bonus to OOPs. Currently OOPS are always carried out after the attack of the unit, but a strong argument has been made that they would be more useful if the OOP went first. I think this will be the key point in the new ready order.
Cavalry stopping needs to be ironed out. Mostly its the case where the final slot is occupied that seems to be the problem. I think in this case, it will have to count as a block, unless the target unit would be terminated, in which case it's position will be freed for the cavalry to occupy.
You may have noticed that I'm talking more about strategic implications and game phases now. This is because these things are becoming major factors as the meta game begins to develop. And so far, the game appears to be even deeper than I imagined. I talked to one of the testers for almost half an hour about the costs and benefits of tactics on a small board and the ideal unit choices. There really is that much to talk about.
The two play throughs I'm basing these observations on were very interesting, and very different from each other. In the first, the person who seemed to be having more trouble understanding the rules during the explanation turned out to catch on faster than their opponent once the game started. In fact their opponent surrendered just 4 rounds in. I thought it was too early to call it and took their place claiming I could turn the game around in just one round, and that I did. It was still a great game though and it proved that experience and knowledge really do count towards a players success.
The second game showed the change in the game over time and also saw the first use of formation play. Cavalry were useful at the start, which made them high priority targets, but toward the end of the game, archers became the dominant units as a dwindling number of targets leads to a guaranteed het with a shoot unit order.
In general reviews were good. There's a lot of potential here. Everyone seemed to like the game, or at least find it interesting. Some people really liked it. If nothing else, I'm now sure it can find a market. Special thanks to Emily, Josh, Karen, and Wilson for playing.
Now the todo list is getting a bit clearer. The next prototype will definitely need a finished rulebook. I think I'll make that tomorrow's project. I also want to add the remaining game components: group orders, terrain, and cover. After that there's no excuse not to move to a digital prototype.
For now, there's enough information to start an implementation. It's definitely time to start outlining the back end. I've got a lot of work ahead on this.
But first, sleeping time. I can rest well knowing that today was a huge success.
P.S. Please comment. I know people are reading this from the statistics, but I have no certainty about who they are or what they think. I'm also very lonely. So please leave something. All I have right now is one from Nick G about my hair. that's just not enough for me anymore.
Okay, I'm done begging. Goodnight!
I'm a little tired but I wanted to do this while it was still fresh in my head.
The cards were largely a success and resulted in fewer invalid orders and less confusion, however the internal notation was still confusing and the slot arrangement created confusion about separation. The lower ease of use on the cards also artificially slowed gameplay. One suggestion was to replace the eight slots with 3 slots and then stack tokens inside them.
Symbolic order explanations were largely a dud, as were the token requirement lists, but these may be attributable to lack of explanation and no legend. I'll try it again with better documentation.
The lack of the film reel does not appear to be a problem. Players can understand the turn order as they arrange their own cards. In general the system now has a learning time of about 4 rounds.
The increase in the number of units (now 5 per team), the size of the board and the new order sets have made the game more playable and more interesting. Archers are now among the more powerful units, however infantry are still under powered. The shot saving system needs to be closely evaluated to avoid over stacking. It might be ok with better clarification, or it may need to be nerfed.
What definitely needs to be nerfed are the base damages for the archers. Originally I wanted archers to always be able to deal some damage, but now I think it may be wise to move both the base damages to 5 and force players to use larger bonuses to overcome armour. Speaking of which, bonuses are much clearer with the new cards. There has been some concern about the range of archers on a small board but I believe that the damage reduction should fix this and future versions should add more units to distract them.
The size of the board does keep coming up as a lingering problem, even with the increase to a standard chess board. However the amount of wall has made for an interesting defence against cavalry and in general, I think it actually adds to the depth of strategy. Also, a lot of the problems revolve around the archer's ability to hit the entire board in most cases, which will be less of a problem when archers are less powerful.
As mentioned before, infantry still seem to be a waste of space. They're getting more useful though (I saw a knight get shredded by clipping two threat zones before it had a chance to hurt anything. This seriously tilted the late game). The biggest waste with infantry right now is the ready order which adds only a tiny bonus to OOPs. Currently OOPS are always carried out after the attack of the unit, but a strong argument has been made that they would be more useful if the OOP went first. I think this will be the key point in the new ready order.
Cavalry stopping needs to be ironed out. Mostly its the case where the final slot is occupied that seems to be the problem. I think in this case, it will have to count as a block, unless the target unit would be terminated, in which case it's position will be freed for the cavalry to occupy.
You may have noticed that I'm talking more about strategic implications and game phases now. This is because these things are becoming major factors as the meta game begins to develop. And so far, the game appears to be even deeper than I imagined. I talked to one of the testers for almost half an hour about the costs and benefits of tactics on a small board and the ideal unit choices. There really is that much to talk about.
The two play throughs I'm basing these observations on were very interesting, and very different from each other. In the first, the person who seemed to be having more trouble understanding the rules during the explanation turned out to catch on faster than their opponent once the game started. In fact their opponent surrendered just 4 rounds in. I thought it was too early to call it and took their place claiming I could turn the game around in just one round, and that I did. It was still a great game though and it proved that experience and knowledge really do count towards a players success.
The second game showed the change in the game over time and also saw the first use of formation play. Cavalry were useful at the start, which made them high priority targets, but toward the end of the game, archers became the dominant units as a dwindling number of targets leads to a guaranteed het with a shoot unit order.
In general reviews were good. There's a lot of potential here. Everyone seemed to like the game, or at least find it interesting. Some people really liked it. If nothing else, I'm now sure it can find a market. Special thanks to Emily, Josh, Karen, and Wilson for playing.
Now the todo list is getting a bit clearer. The next prototype will definitely need a finished rulebook. I think I'll make that tomorrow's project. I also want to add the remaining game components: group orders, terrain, and cover. After that there's no excuse not to move to a digital prototype.
For now, there's enough information to start an implementation. It's definitely time to start outlining the back end. I've got a lot of work ahead on this.
But first, sleeping time. I can rest well knowing that today was a huge success.
P.S. Please comment. I know people are reading this from the statistics, but I have no certainty about who they are or what they think. I'm also very lonely. So please leave something. All I have right now is one from Nick G about my hair. that's just not enough for me anymore.
Okay, I'm done begging. Goodnight!
Saturday 11 August 2012
Generation 2 pt 2
Good morning/evening interwebs!
I thought I'd start my morning off with breakfast and blogging. What better way is there?
So it seems the UVic games club will be meeting tonight. This gives me a solid deadline for about 8 hours from now to have the prototype done. It's going to be tight, but I think I can make it.
I stormed up most of the order designs last night. They're slightly more complicated than the units were so I'm going to draw each one by hand rather than cutting them out. It's going to take time, but last time I was cutting out each piece individually, so I have only gained speed.
I spent 4 or 5 minutes racking my brain over how to do "swing", a new infantry order. The unit has to move then damage a set of tiles. The figure in the order image will be doing a vertical swing, because I can draw it in 2D even though it doesn't make sense.
I've also been developing a small library of symbols to describe which units can carry out an order, the effect of the order, and the function of the arguments. It's going to be a moot point without the written rules, but I hope it can help people keep things straight after the first reading.
I think I'm going to drop the white backing idea. Whatever table I'm playing on will have to suffice.
Well, it's 10:30, and I'm done my cereal. Time to get back to work.
Saturday 11:05
Ya gotta love the difference between the math of the morning and the math of the night before. After checking my numbers again, I actually needed 156 of the 1x1 guys. The backing for the film strip is definitely out. Anyway, just finished tracing out all of the argument pieces, which will henceforth be known as detail tokens. The next thing to trace out will be the order tokens. The name change is to spare the manual and future blog posts from the cards within cards confusion. An order card will have an order token and a number of detail tokens. Before I create the order tokens though, I need to go back to my notebook and finish their design.
Saturday 11:30
Oh boy! This part is going to be a bit more messy. The detail tokens were each single pieces, but an order token consists of four sections:
Saturday 12:20
That got it. I have traces of 56 cards and I only need 48. I'm a little worried that some of the side sections may be cramped, but I'm committed now. I may choose not to outline the smaller details and just leave the pencil versions. Of course I haven't actually done the pencil versions yet, but I have a good excuse. My pencil just ran out of lead. For the paper prototype creator, this is like getting splashed by a dolphin. It's a good thing. Between the patterns on the paper and my lack of lead, I'm getting that swelling "you're actually accomplishing something" feeling that I love so much. Also getting that "I'm hungry" feeling so I think I'm going to make a quick snack run.
Saturday 1:30
I have finalized the design for all the subsections. Now all I have to do is make 6 copies of every card. This is going to get a bit tedious, but the tension will be maintained by the fact that I have been unable to locate my backup leads. I have one pencil that still has lead, but I have no idea how much.
God is my co-pilot.
Saturday 3:05
Done tracing! By some miracle, that lead never gave out. As badly as I want to cut them out, I think the better move will be to take one of the spares, and use it to build the cards. The plan is for each token slot to consist of 4 slits large enough to hold the corners of the token in question. This shouldn't be too hard, but finding a good way to make a slit without having any edge to come in from poses a problem. Time to scour the house for a suitable tool.
Saturday 4:15
So after failing with a 4 slit slot, and finding that a single tab let go too easily, I found that the best system was to create 2 slits in a v which all comfortably allows tokens to be added and removed without easily falling out. Having made all six cards, a contiguous film real is not possible due to the size of the cards. I'm going to forgo the film strip for now and just see how order assembly goes with the card system in place. All I have to do now is cut out the tokens, bag them, and take them to the games club to test them with a fresh audience. I'll let you know how it goes tomorrow.
Till then, see you later.
I thought I'd start my morning off with breakfast and blogging. What better way is there?
So it seems the UVic games club will be meeting tonight. This gives me a solid deadline for about 8 hours from now to have the prototype done. It's going to be tight, but I think I can make it.
I stormed up most of the order designs last night. They're slightly more complicated than the units were so I'm going to draw each one by hand rather than cutting them out. It's going to take time, but last time I was cutting out each piece individually, so I have only gained speed.
I spent 4 or 5 minutes racking my brain over how to do "swing", a new infantry order. The unit has to move then damage a set of tiles. The figure in the order image will be doing a vertical swing, because I can draw it in 2D even though it doesn't make sense.
I've also been developing a small library of symbols to describe which units can carry out an order, the effect of the order, and the function of the arguments. It's going to be a moot point without the written rules, but I hope it can help people keep things straight after the first reading.
I think I'm going to drop the white backing idea. Whatever table I'm playing on will have to suffice.
Well, it's 10:30, and I'm done my cereal. Time to get back to work.
Saturday 11:05
Ya gotta love the difference between the math of the morning and the math of the night before. After checking my numbers again, I actually needed 156 of the 1x1 guys. The backing for the film strip is definitely out. Anyway, just finished tracing out all of the argument pieces, which will henceforth be known as detail tokens. The next thing to trace out will be the order tokens. The name change is to spare the manual and future blog posts from the cards within cards confusion. An order card will have an order token and a number of detail tokens. Before I create the order tokens though, I need to go back to my notebook and finish their design.
Saturday 11:30
Oh boy! This part is going to be a bit more messy. The detail tokens were each single pieces, but an order token consists of four sections:
- the order image, which identifies the order and provides a conceptual image of what it does.
- the order availability, which identifies which units can use this order.
- the detail token list, which lists the detail tokens needed to fill out the order.
- the order explanation, which uses a series of symbols o explain the order's functionality.
Saturday 12:20
That got it. I have traces of 56 cards and I only need 48. I'm a little worried that some of the side sections may be cramped, but I'm committed now. I may choose not to outline the smaller details and just leave the pencil versions. Of course I haven't actually done the pencil versions yet, but I have a good excuse. My pencil just ran out of lead. For the paper prototype creator, this is like getting splashed by a dolphin. It's a good thing. Between the patterns on the paper and my lack of lead, I'm getting that swelling "you're actually accomplishing something" feeling that I love so much. Also getting that "I'm hungry" feeling so I think I'm going to make a quick snack run.
Saturday 1:30
I have finalized the design for all the subsections. Now all I have to do is make 6 copies of every card. This is going to get a bit tedious, but the tension will be maintained by the fact that I have been unable to locate my backup leads. I have one pencil that still has lead, but I have no idea how much.
God is my co-pilot.
Saturday 3:05
Done tracing! By some miracle, that lead never gave out. As badly as I want to cut them out, I think the better move will be to take one of the spares, and use it to build the cards. The plan is for each token slot to consist of 4 slits large enough to hold the corners of the token in question. This shouldn't be too hard, but finding a good way to make a slit without having any edge to come in from poses a problem. Time to scour the house for a suitable tool.
Saturday 4:15
So after failing with a 4 slit slot, and finding that a single tab let go too easily, I found that the best system was to create 2 slits in a v which all comfortably allows tokens to be added and removed without easily falling out. Having made all six cards, a contiguous film real is not possible due to the size of the cards. I'm going to forgo the film strip for now and just see how order assembly goes with the card system in place. All I have to do now is cut out the tokens, bag them, and take them to the games club to test them with a fresh audience. I'll let you know how it goes tomorrow.
Till then, see you later.
Friday 10 August 2012
Generation 2 pt 1
Welcome interwebs, to a fabulous experiment.
I'm about to start work on the second version of the Stratagem prototype and I'm going to try to think out lout on the blog as I go. Admittedly this is somewhat moot as several sections of this will all be posted at the same time, but still. I'm looking to make this a bit more dynamic or something. With any luck a simple time stamp can keep the magic.
Everyone ready? I'll take that silence as a yes. Here we go:
Friday 9:30 (ish)
The first step is to plan exactly what I want to do with the two pieces of construction paper I brought home from the dollar store. I have one big black and one big white and no replacements, so this has to be right the first time. With that I shall sit and sketch. Brb.
Friday 10:00
After some sketching, with intermittent unrelated texting, and occasional drifting off, I have a short list of the things I need out of the paper I have. But the purpose of these pieces is worth a bit of explanation first. After looking at the paper prototype results, I have decided I need a way for users to assemble orders rather than conjure them out of thin air. I also need a construct that will clearly explain the turn order so that players will understand the decisions they are making in context. The plan is to create cards with slots for order cards, and their argument cards. For example: a move order for an infantry unit would consist of a move card and two direction cards indicating the path which the unit must follow.
I have an extra boost to my confidence in this idea as I had a chance to play "demon tournament" again recently. The game is major inspiration for the core mechanics of stratagem on a very small scale and seems to have a self evident UI design. That design uses single cards that represent complete orders on their own. For instance, a move left card will move your character one space left. When the player is creating their orders for a round, they are shown all the cards at once, and there is a small enough number that all cards can be clearly understood. While the basic operation of creating orders explains itself quite well, how the orders will be executed is largely unexplained. The user selects 3 cards to fill their 3 slots. They select the cards in order, which suggests their sequential execution, but it is not explicitly clear. What is completely unclear is how the enemy orders fit in. They do not show on the order creation display, leaving the user to learn at runtime that the orders alternate between them and the computer. And that the computer goes first. Always.
I want to do a more thorough post on my revisitation of demon tournament, but for now, I just wanted to touch on this issue.
My solution is to have an array of positions for the order cards to be placed face down until runtime. The array will have all 6 slots for a round and the players will place their orders in the even or odd slots respectively. The slots will be marked with the players colour before the orders are placed, so no one actually has to count. The problem with this is that I have no way to integrate it into a medieval theme right now, so I've decided not to try. Instead, the array will be made to look like a film strip with an arrow on one side indicating the direction of flow. Hopefully this will be a functional design metaphor.
Friday 11:00
I'm starting to realize just how much longer this takes when I keep stopping to write about it. Oh well.
I tracked down a tape measure and took the height and width of the papers I have. You'll have to excuse the units. My tape measure is American so everything is in inches. On the bright side, I won't be converting anything, so there's really no problem with using imperial distances.
Also it seems the paper manufacturer was also using inches as my tow sheets each measure 22x28. This gives me 616 square inches of each colour. I need 122 1x1 pieces to handle the arguments. That leaves me with 494 sq in to play with. An order needs at most 7 argument slots (in the case of a cavalry charge) and I can easily accomodate a 2x4 slot set on each card. I will need 6 of each of the 8 possible order cards and going with a square card design, I think I'll aim for the order cards to be whole 2x8 pieces. That knocks off another 384 sq in.
So now I have just 110 inches left. That should leave just enough white paper to put a backing behind each card slot on the film reel, but the white piece will not be a single piece as I was hoping. I'll have to settle for this though. It's better that what I got on my first estimate anyway.
Now actually getting the pieces out of my paper will be a bit of a knapsack problem. I think I'm going to leave that till morning. In the mean time, I'm going to start sketching the order designs. I doubt I'll have them finalized till tomorrow anyway, so I'm releasing this now. I also have to sleep at some point.
Stay tuned interwebs. I shall be back with another one of these tomorrow night.
I'm about to start work on the second version of the Stratagem prototype and I'm going to try to think out lout on the blog as I go. Admittedly this is somewhat moot as several sections of this will all be posted at the same time, but still. I'm looking to make this a bit more dynamic or something. With any luck a simple time stamp can keep the magic.
Everyone ready? I'll take that silence as a yes. Here we go:
Friday 9:30 (ish)
The first step is to plan exactly what I want to do with the two pieces of construction paper I brought home from the dollar store. I have one big black and one big white and no replacements, so this has to be right the first time. With that I shall sit and sketch. Brb.
Friday 10:00
After some sketching, with intermittent unrelated texting, and occasional drifting off, I have a short list of the things I need out of the paper I have. But the purpose of these pieces is worth a bit of explanation first. After looking at the paper prototype results, I have decided I need a way for users to assemble orders rather than conjure them out of thin air. I also need a construct that will clearly explain the turn order so that players will understand the decisions they are making in context. The plan is to create cards with slots for order cards, and their argument cards. For example: a move order for an infantry unit would consist of a move card and two direction cards indicating the path which the unit must follow.
I have an extra boost to my confidence in this idea as I had a chance to play "demon tournament" again recently. The game is major inspiration for the core mechanics of stratagem on a very small scale and seems to have a self evident UI design. That design uses single cards that represent complete orders on their own. For instance, a move left card will move your character one space left. When the player is creating their orders for a round, they are shown all the cards at once, and there is a small enough number that all cards can be clearly understood. While the basic operation of creating orders explains itself quite well, how the orders will be executed is largely unexplained. The user selects 3 cards to fill their 3 slots. They select the cards in order, which suggests their sequential execution, but it is not explicitly clear. What is completely unclear is how the enemy orders fit in. They do not show on the order creation display, leaving the user to learn at runtime that the orders alternate between them and the computer. And that the computer goes first. Always.
I want to do a more thorough post on my revisitation of demon tournament, but for now, I just wanted to touch on this issue.
My solution is to have an array of positions for the order cards to be placed face down until runtime. The array will have all 6 slots for a round and the players will place their orders in the even or odd slots respectively. The slots will be marked with the players colour before the orders are placed, so no one actually has to count. The problem with this is that I have no way to integrate it into a medieval theme right now, so I've decided not to try. Instead, the array will be made to look like a film strip with an arrow on one side indicating the direction of flow. Hopefully this will be a functional design metaphor.
Friday 11:00
I'm starting to realize just how much longer this takes when I keep stopping to write about it. Oh well.
I tracked down a tape measure and took the height and width of the papers I have. You'll have to excuse the units. My tape measure is American so everything is in inches. On the bright side, I won't be converting anything, so there's really no problem with using imperial distances.
Also it seems the paper manufacturer was also using inches as my tow sheets each measure 22x28. This gives me 616 square inches of each colour. I need 122 1x1 pieces to handle the arguments. That leaves me with 494 sq in to play with. An order needs at most 7 argument slots (in the case of a cavalry charge) and I can easily accomodate a 2x4 slot set on each card. I will need 6 of each of the 8 possible order cards and going with a square card design, I think I'll aim for the order cards to be whole 2x8 pieces. That knocks off another 384 sq in.
So now I have just 110 inches left. That should leave just enough white paper to put a backing behind each card slot on the film reel, but the white piece will not be a single piece as I was hoping. I'll have to settle for this though. It's better that what I got on my first estimate anyway.
Now actually getting the pieces out of my paper will be a bit of a knapsack problem. I think I'm going to leave that till morning. In the mean time, I'm going to start sketching the order designs. I doubt I'll have them finalized till tomorrow anyway, so I'm releasing this now. I also have to sleep at some point.
Stay tuned interwebs. I shall be back with another one of these tomorrow night.
Saturday 4 August 2012
The Results are in pt 2
Howdy interwebs!
I have no idea how long the paper prototyping phase is going to last, so I'm going to stop making additional parts to this episode. I have been able to learn a bit more about the game through the last two play throughs at UVic gamedev have given me a few ideas on how to simplify and improve the game and have also led to the first written changes to the rules.
Version 1 was imbalanced. Horribly. This isn't really a surprise as the original balance sheet was forgotten on my way out the door, so I had to throw a new one together before the first play throughs and I just kept using it. But now that I have recovered the original stats and have some data to compare them with I've made a couple changes. (Yay my first patch notes ever!!):
- Infantry orders have been restructured because they were enormously complicated.
- Raiders have had their HP slashed by 25% and their blade attack reduced by more than 50%. I hope they will no longer be stupidly overpowered.
- Archers have had their attack increased and their range doubled. This does mean that they can hit the entire test board at the start, but in game maps, which will be much larger, this should be less of an issue.
- Cavalry will no longer have attacks of opportunity against each other. OOPs are just an infantry thing for now.
- Archer's attack rules will be changed so that they all work the way "attack next" worked.
That's the gist of it. But there's something else I discovered in the prototype: I have accidentally created a foo strategy. What di I just say? Well, that might take a little explanation.
In every game with a multiplayer component, it is easy for newcomers to be overwhelmed by the complexity of the game at first. Often strategies will become popular with these groups which have a high ratio of power to effort/skill required. We've all come across foo strategies: the zerg rush, the noob tube, immediately grabbing the centre square in tic-tac-toe. Often these strategies can be countered by an experienced opponent and will fail if the newcomer is not able to adapt, but because the strategy exists, they can latch on to it and use it as a crutch while they learn the nuances of the game.
In stratagem, at the start of each order evaluation cycle, the first order will be executed before there has been any change on the board, giving it a 100% chance to hit. Cavalry (especially knights) can devastate a unit if they manage to hit them, often killing them in one shot. Their range also allows them to hit most units on the board. So on alternating rounds, each player has the chance to choose one enemy unit and easily destroy it. Thus far, this strategy has been a bit too powerful as the raider unit was overpowered. But with this fixed, I'm hoping that the first order cavalry snipe can become a manageable foo strategy for the time being.
Lastly, the prototype accomplished its most important goal: to find out if the game was fun.
It was.
So I'm moving ahead with development. I need to review my planned server architecture before I start coding, but I think I'm ready to start making a basic engine prototype.
Tata for now. I'd love to say more, but I have to go retrieve some laundry from the dryer. Such is life.
Au revoir.
I have no idea how long the paper prototyping phase is going to last, so I'm going to stop making additional parts to this episode. I have been able to learn a bit more about the game through the last two play throughs at UVic gamedev have given me a few ideas on how to simplify and improve the game and have also led to the first written changes to the rules.
Version 1 was imbalanced. Horribly. This isn't really a surprise as the original balance sheet was forgotten on my way out the door, so I had to throw a new one together before the first play throughs and I just kept using it. But now that I have recovered the original stats and have some data to compare them with I've made a couple changes. (Yay my first patch notes ever!!):
- Infantry orders have been restructured because they were enormously complicated.
- Raiders have had their HP slashed by 25% and their blade attack reduced by more than 50%. I hope they will no longer be stupidly overpowered.
- Archers have had their attack increased and their range doubled. This does mean that they can hit the entire test board at the start, but in game maps, which will be much larger, this should be less of an issue.
- Cavalry will no longer have attacks of opportunity against each other. OOPs are just an infantry thing for now.
- Archer's attack rules will be changed so that they all work the way "attack next" worked.
That's the gist of it. But there's something else I discovered in the prototype: I have accidentally created a foo strategy. What di I just say? Well, that might take a little explanation.
In every game with a multiplayer component, it is easy for newcomers to be overwhelmed by the complexity of the game at first. Often strategies will become popular with these groups which have a high ratio of power to effort/skill required. We've all come across foo strategies: the zerg rush, the noob tube, immediately grabbing the centre square in tic-tac-toe. Often these strategies can be countered by an experienced opponent and will fail if the newcomer is not able to adapt, but because the strategy exists, they can latch on to it and use it as a crutch while they learn the nuances of the game.
In stratagem, at the start of each order evaluation cycle, the first order will be executed before there has been any change on the board, giving it a 100% chance to hit. Cavalry (especially knights) can devastate a unit if they manage to hit them, often killing them in one shot. Their range also allows them to hit most units on the board. So on alternating rounds, each player has the chance to choose one enemy unit and easily destroy it. Thus far, this strategy has been a bit too powerful as the raider unit was overpowered. But with this fixed, I'm hoping that the first order cavalry snipe can become a manageable foo strategy for the time being.
Lastly, the prototype accomplished its most important goal: to find out if the game was fun.
It was.
So I'm moving ahead with development. I need to review my planned server architecture before I start coding, but I think I'm ready to start making a basic engine prototype.
Tata for now. I'd love to say more, but I have to go retrieve some laundry from the dryer. Such is life.
Au revoir.
Tuesday 31 July 2012
The Results Are In pt 1
Ola interwebs!
I would love to be telling you about how the paper prototype went. However the only thing I can say for certain is that engineers ata kegger are a less than ideal test group, and things being a little hectic, I only got one play through completed.
So the plan is to bring the prototype to the next gamedev club meeting and try it out when everyone is sober. Probably better for a strategy game anyway.
As it stands though, I did learn a bit from the one test.
The rules are not inherently intuitive. It's difficult for players to associate the orders a unit can carry out with the unit itself. The order submission is also unnatural, but partly because it is unique to this game. I think I can fix this in the digital version with a change in the UI metaphor. The order association is also easily fixed in the digital version where a mouse over is possible.
For the future prototype sessions, I need better rules documentation to explain the rules. I think I also need to establish set forms for the orders. I had hoped to base this form on the orders the testers created on their own, but a little bit of restriction could do a lot to lessen the confusion when the orders are being written. I think I'll let people free hand them at gamedev then narrow down the forms for the next test session. Next project is going to have to be a set of typed rules in a logical order.
I also think I need to alter the balance, but I think that's better left until after a bit more testing.
So that's the story so far. I'll have part 2 up after Thursday.
Later.
I would love to be telling you about how the paper prototype went. However the only thing I can say for certain is that engineers ata kegger are a less than ideal test group, and things being a little hectic, I only got one play through completed.
So the plan is to bring the prototype to the next gamedev club meeting and try it out when everyone is sober. Probably better for a strategy game anyway.
As it stands though, I did learn a bit from the one test.
The rules are not inherently intuitive. It's difficult for players to associate the orders a unit can carry out with the unit itself. The order submission is also unnatural, but partly because it is unique to this game. I think I can fix this in the digital version with a change in the UI metaphor. The order association is also easily fixed in the digital version where a mouse over is possible.
For the future prototype sessions, I need better rules documentation to explain the rules. I think I also need to establish set forms for the orders. I had hoped to base this form on the orders the testers created on their own, but a little bit of restriction could do a lot to lessen the confusion when the orders are being written. I think I'll let people free hand them at gamedev then narrow down the forms for the next test session. Next project is going to have to be a set of typed rules in a logical order.
I also think I need to alter the balance, but I think that's better left until after a bit more testing.
So that's the story so far. I'll have part 2 up after Thursday.
Later.
Saturday 28 July 2012
Good Morning pt2
Hey interwebs. I'm back.
I took that shower. Then a trip to the liquor store, a bus to cady bay and several hours to finish the project from last night.
So it's been longer than I meant.
Anyway, the project from last night was to build a paper prototype for sratagem to answer one simple question. Is this game fun?
I know this should be self evident, but as designers, we get attached to our own ideas and often don't sufficiently scrutinize them. This can lead to a situation that one of my colleagues has found themselves in. After 5 years of development, they are in the process of user testing and perfecting the tutorial and are only now starting to ask, with some underlying desperation, wether the game is fun and if and why someone would buy it.
The worst part is that the answers seem to be "kind of", and "probably not" respectively.
I don't want that to happen to me, so I am trying to answer the question now. To that end, I cut out about 24 pieces and threw together a grid and I have been able to start running test games with the other partygoers here.
I would tell you how it went, but I'm not done yet. So results to come in a future post. Bye for now.
Good Morning pt1
Good morning interwebs!
Admittedly not the morning from the last post, but hey, an entry is an entry. I'm getting it out there.
Last night was oddly productive. Especially for me. Thursday I had wrestled flash onto my mac and came to the conclusion that future users of flash should make a point of mentioning flex, the sdk that basically is flash from a programmers view. Anyway, the point is, I can now write actionscript programs on my mac from the command line and any text editor I feel like. That's a good day, but we're not talking about that day.
Getting back to last night, while zoning out in front of the national and the escapist and randomly googled "Ruby graphics" and just for good measure, appended "mac" (mac users will be familiar with that last step. It's usually mandatory). I came up with 3 promising hits: Rubygame, Gosu, and Shoes. Shoes showed itself more as a gui library and didn't have the level of documentation I was looking for. Rubygame was a nice idea, but it had some issues on mac with Rake and I didn't want another massive file hunt on my hands. This led me to Gosu.
The installation was pretty easy. Gosu is a gem, which means the Ruby gems system can handle the installation on its own. And that it did. It even cam with an example game as a tutorial. The whole game was in one file, ~3 pages (ish. I can only judge from vim scrolling time). I tried running it through the Ruby interpreter and presto! There it was.
Two thoughts occurred to me at that moment:
Firstly: God I love this language!
Secondly: God I don't want to figure out that example without a half decent IDE.
So part 2 of the project became the setting up of a Ruby plugin for a half decent IDE. I had eclipse handy, so I went with that.
Now when I did this with c++ it was kind of a nightmare, but the subsequent python install went pretty smoothly. So I had no idea how this was going to go. Consulting the internet, I found the plugin I needed was called DLTK. I have no idea what this stands for, but with all the batman hype lately, I choose to believe it stands for Dark Like The Knight. Anyway the Knight's installation was pretty smooth, save one exception. On of the things you rely on as a programmer is the standard out feed on the console for debugging purposes. This Ruby plugin's only problem was that where other programs printed something, it printed nothing. When a one line hello world program fails to print, it's a sad day. A little more research revealed that this was a unix eclipse bug and that it had been fixed in the next version. After I downloaded that it was a breeze.
Now there was only one hurdle left: get the tutorial file to execute through eclipse. I hit a bug on my first attempt to run it. But I didn't really look at the error message. I was instead focused on a mysterious point at which eclipse misread a '"' and proceded to colour the rest of the program as a string. A little trial and error, and I discovered that under the right circumstances, an escape character is needed for a '/'. Of course that didn't fix the error. The program was failing because the code was here and the images and sounds were in a media folder back in the gem, bu that was easily fixed. After that it worked perfectly. I'm almost waiting for something to go wrong.
But it hasn't yet and it didn't last night. I was up late working on a more important goal for today, but I'm saving that for another post. I think I'll type that one up after I get back from the shower.
Anyhoo, to sum up: Ruby awesome. Ruby on eclipse awesome so far. Ruby and Gosu on eclipse freaking awesome. Last night amazingly awesome. More posts to come. Soon
Until then, to paraphrase a more interesting man: "Stay bored my friends."
Admittedly not the morning from the last post, but hey, an entry is an entry. I'm getting it out there.
Last night was oddly productive. Especially for me. Thursday I had wrestled flash onto my mac and came to the conclusion that future users of flash should make a point of mentioning flex, the sdk that basically is flash from a programmers view. Anyway, the point is, I can now write actionscript programs on my mac from the command line and any text editor I feel like. That's a good day, but we're not talking about that day.
Getting back to last night, while zoning out in front of the national and the escapist and randomly googled "Ruby graphics" and just for good measure, appended "mac" (mac users will be familiar with that last step. It's usually mandatory). I came up with 3 promising hits: Rubygame, Gosu, and Shoes. Shoes showed itself more as a gui library and didn't have the level of documentation I was looking for. Rubygame was a nice idea, but it had some issues on mac with Rake and I didn't want another massive file hunt on my hands. This led me to Gosu.
The installation was pretty easy. Gosu is a gem, which means the Ruby gems system can handle the installation on its own. And that it did. It even cam with an example game as a tutorial. The whole game was in one file, ~3 pages (ish. I can only judge from vim scrolling time). I tried running it through the Ruby interpreter and presto! There it was.
Two thoughts occurred to me at that moment:
Firstly: God I love this language!
Secondly: God I don't want to figure out that example without a half decent IDE.
So part 2 of the project became the setting up of a Ruby plugin for a half decent IDE. I had eclipse handy, so I went with that.
Now when I did this with c++ it was kind of a nightmare, but the subsequent python install went pretty smoothly. So I had no idea how this was going to go. Consulting the internet, I found the plugin I needed was called DLTK. I have no idea what this stands for, but with all the batman hype lately, I choose to believe it stands for Dark Like The Knight. Anyway the Knight's installation was pretty smooth, save one exception. On of the things you rely on as a programmer is the standard out feed on the console for debugging purposes. This Ruby plugin's only problem was that where other programs printed something, it printed nothing. When a one line hello world program fails to print, it's a sad day. A little more research revealed that this was a unix eclipse bug and that it had been fixed in the next version. After I downloaded that it was a breeze.
Now there was only one hurdle left: get the tutorial file to execute through eclipse. I hit a bug on my first attempt to run it. But I didn't really look at the error message. I was instead focused on a mysterious point at which eclipse misread a '"' and proceded to colour the rest of the program as a string. A little trial and error, and I discovered that under the right circumstances, an escape character is needed for a '/'. Of course that didn't fix the error. The program was failing because the code was here and the images and sounds were in a media folder back in the gem, bu that was easily fixed. After that it worked perfectly. I'm almost waiting for something to go wrong.
But it hasn't yet and it didn't last night. I was up late working on a more important goal for today, but I'm saving that for another post. I think I'll type that one up after I get back from the shower.
Anyhoo, to sum up: Ruby awesome. Ruby on eclipse awesome so far. Ruby and Gosu on eclipse freaking awesome. Last night amazingly awesome. More posts to come. Soon
Until then, to paraphrase a more interesting man: "Stay bored my friends."
Sunday 22 July 2012
The Pitch and the Pitfall
Hello again interwebs.
I speak to you now, after a long day of cleaning with roommates and DnD with buddies. I meant to post something earlier this week and now my friends have been asking why nothing else has come through, so, seeing as how the couch is currently occupied and therefore unavailable for me to sleep on, I thought I should take this moment to level with you.
When it has come to my ideas for games in the past, I have tended to be tight lipped. I am constantly worried that anyone I tell could imitate the project, and hastily finish it faster than I could, and thus beat me to the punch. In software, this isn't an unreasonable fear. The industry moves fast. Often the first person to an idea will be able to get a better hold with their product during the short time during which they have a monopoly until a competitor gets a product released. This is part of the reason that Facebook and the iPhone are so established today.
So naturally, this fear has been in the back of my mind regarding this blog. I'm not so much that worried a triple A studio will run with the project (it would be WAY too risky), but more that a fellow wannabe like myself who was more motivated, more skilled, and have more time, and thus a better chance of realeasing the game. Long story short, I really don't want to have my game cloned before I can even get a demo out the door.
This leads to my current dilemma. I want the blog, and I want the game, but how much of the game am I comfortable sharing with the entirety of the internet. Do I share only the underlying programming and creation process? Or do I show the game I am trying to build on top of it and explain why I am building the systems I am? At first I was going to try to go the former route, but after talking it over with a couple friends, a few things became clear to me.
Firstly, the internet is REALLY big. My grandpa had a trick for when he was going into a coal mine and feared its collapse, since it could happen at any time. He simply reminded himself that he wasn't important enough for the mine to pick that moment to come crashing down. Likewise, my humble blog is unlikely to get the kind of attention that would be necessary for even one person with sufficient malice to pirate the entire project. And my ideas, as much as I love them, are not solid gold. There's no reason to think I have anything really worth stealing. I'm just not that important.
Secondly, a lot of designers are as attached to their own ideas as I am to mine. They have their own dream projects and aren't likely to drop them so they can steal mine instead. The passion just isn't there.
Thirdly, I can't really claim to have invented any of these mechanics. Other people have played the same flash games and strategy games that I have, and may have just as easily found the same inspiration as I did. Anyone still could. So treating them like I somehow own them doesn't really hold up.
Lastly, constantly trying to hide what I was creating would make my writing dishonest and really difficult. It's hard enough to describe things to someone who's never seen the game (which is everyone at the moment), but trying to describe making it without telling them what it was, that's just a headache. I want this to be fun.
So I've decided to take a leap of faith and take the second option. Here goes:
Stratagem (actual name pending) is intended as a medieval strategy game (which there are already plenty of) in which players will control a small squad of soldiers by submitting their orders concurrently, as in Diplomacy, then watching as the computer resolves the orders one by one. To be successful, a player will have to predict their opponents actions, and plan their own accordingly.
And that's the gist of it. I guess that wasn't so hard. I could go into greater detail, but it doesn't make much sense in this context. For now, I think it's best to just give out the details as needed, for brevity's sake.
That's all for now. I should have another post up pretty soon to talk about what I've been doing the last week, but I wanted to handle this separately.
And to you indie designers out there, this probably goes without saying, but please, don't burn me on this. I'm going out on limb here.
Anyhoo, the couch is finally free , and I'm dying to go to sleep. Night!
I speak to you now, after a long day of cleaning with roommates and DnD with buddies. I meant to post something earlier this week and now my friends have been asking why nothing else has come through, so, seeing as how the couch is currently occupied and therefore unavailable for me to sleep on, I thought I should take this moment to level with you.
When it has come to my ideas for games in the past, I have tended to be tight lipped. I am constantly worried that anyone I tell could imitate the project, and hastily finish it faster than I could, and thus beat me to the punch. In software, this isn't an unreasonable fear. The industry moves fast. Often the first person to an idea will be able to get a better hold with their product during the short time during which they have a monopoly until a competitor gets a product released. This is part of the reason that Facebook and the iPhone are so established today.
So naturally, this fear has been in the back of my mind regarding this blog. I'm not so much that worried a triple A studio will run with the project (it would be WAY too risky), but more that a fellow wannabe like myself who was more motivated, more skilled, and have more time, and thus a better chance of realeasing the game. Long story short, I really don't want to have my game cloned before I can even get a demo out the door.
This leads to my current dilemma. I want the blog, and I want the game, but how much of the game am I comfortable sharing with the entirety of the internet. Do I share only the underlying programming and creation process? Or do I show the game I am trying to build on top of it and explain why I am building the systems I am? At first I was going to try to go the former route, but after talking it over with a couple friends, a few things became clear to me.
Firstly, the internet is REALLY big. My grandpa had a trick for when he was going into a coal mine and feared its collapse, since it could happen at any time. He simply reminded himself that he wasn't important enough for the mine to pick that moment to come crashing down. Likewise, my humble blog is unlikely to get the kind of attention that would be necessary for even one person with sufficient malice to pirate the entire project. And my ideas, as much as I love them, are not solid gold. There's no reason to think I have anything really worth stealing. I'm just not that important.
Secondly, a lot of designers are as attached to their own ideas as I am to mine. They have their own dream projects and aren't likely to drop them so they can steal mine instead. The passion just isn't there.
Thirdly, I can't really claim to have invented any of these mechanics. Other people have played the same flash games and strategy games that I have, and may have just as easily found the same inspiration as I did. Anyone still could. So treating them like I somehow own them doesn't really hold up.
Lastly, constantly trying to hide what I was creating would make my writing dishonest and really difficult. It's hard enough to describe things to someone who's never seen the game (which is everyone at the moment), but trying to describe making it without telling them what it was, that's just a headache. I want this to be fun.
So I've decided to take a leap of faith and take the second option. Here goes:
Stratagem (actual name pending) is intended as a medieval strategy game (which there are already plenty of) in which players will control a small squad of soldiers by submitting their orders concurrently, as in Diplomacy, then watching as the computer resolves the orders one by one. To be successful, a player will have to predict their opponents actions, and plan their own accordingly.
And that's the gist of it. I guess that wasn't so hard. I could go into greater detail, but it doesn't make much sense in this context. For now, I think it's best to just give out the details as needed, for brevity's sake.
That's all for now. I should have another post up pretty soon to talk about what I've been doing the last week, but I wanted to handle this separately.
And to you indie designers out there, this probably goes without saying, but please, don't burn me on this. I'm going out on limb here.
Anyhoo, the couch is finally free , and I'm dying to go to sleep. Night!
Monday 16 July 2012
Day 1
Greetings interweb!
I feel there should be some kind of introduction to this thing, but I don't want to go into too much detail as to who I am. So here's a short rundown of my life at this moment:
I just cut my hair for the first time in over two years. I am still experiencing a phantom ponytail.
My roommates just got hitched (to each other). Much love to them.
I'm on a co-op making facebook games of no consequence to this blog, and I will be returning to UVic for another two years to finish my degree in Software Engineering.
But why am I starting a blog you ask.
Good question.
You see I am a middling game developer, and a small presence amongst the local gamedev seen at UVic and in trying to figure out my goals for the next year or so, I came to something of an epiphany this morning.
I have been trying to figure out when ad how I will go about learning/practising javascript, HTML5,HTML(not 5),CSS,MySQL, and the most recent addition to the herd, Ruby. I need them all to develop games in the future, but how will I learn them now, and which should I learn first. That is the conundrum.
Anyway this morning, the answer hit me right on the head.
The web based strategy game I have had on the brain in various forms for a couple years now (currently codenamed "Stratagem") would need all of these components to function properly, so why not just learn all of them as needed. And if Yahtzee, Notch, and my good friends at Gnar Games have taught me anything, its that every great game NEEDS a development blog.
So here we go. More details on the game itself and much more to come.
For now, I have only one more thing left. I mentioned that I cut my hair for the first time in ages and having done that, I feel it wasn't nearly the occasion it should have been. I hastily got it cut on Saturday morning because I had promised it would be short for the wedding that afternoon. So to make up for it, and to motivate me to actually finish this game, I pledge here, tonight, to you, my readers, that my hair shall not be cut again until "Strategem" is released. Hopefully that will be before I wind up looking like the wolfman.
Now I have to go. My fridge is empty, and it's WAY to hot!
I'm Lambwatt, and this is Day 1.
I feel there should be some kind of introduction to this thing, but I don't want to go into too much detail as to who I am. So here's a short rundown of my life at this moment:
I just cut my hair for the first time in over two years. I am still experiencing a phantom ponytail.
My roommates just got hitched (to each other). Much love to them.
I'm on a co-op making facebook games of no consequence to this blog, and I will be returning to UVic for another two years to finish my degree in Software Engineering.
But why am I starting a blog you ask.
Good question.
You see I am a middling game developer, and a small presence amongst the local gamedev seen at UVic and in trying to figure out my goals for the next year or so, I came to something of an epiphany this morning.
I have been trying to figure out when ad how I will go about learning/practising javascript, HTML5,HTML(not 5),CSS,MySQL, and the most recent addition to the herd, Ruby. I need them all to develop games in the future, but how will I learn them now, and which should I learn first. That is the conundrum.
Anyway this morning, the answer hit me right on the head.
The web based strategy game I have had on the brain in various forms for a couple years now (currently codenamed "Stratagem") would need all of these components to function properly, so why not just learn all of them as needed. And if Yahtzee, Notch, and my good friends at Gnar Games have taught me anything, its that every great game NEEDS a development blog.
So here we go. More details on the game itself and much more to come.
For now, I have only one more thing left. I mentioned that I cut my hair for the first time in ages and having done that, I feel it wasn't nearly the occasion it should have been. I hastily got it cut on Saturday morning because I had promised it would be short for the wedding that afternoon. So to make up for it, and to motivate me to actually finish this game, I pledge here, tonight, to you, my readers, that my hair shall not be cut again until "Strategem" is released. Hopefully that will be before I wind up looking like the wolfman.
Now I have to go. My fridge is empty, and it's WAY to hot!
I'm Lambwatt, and this is Day 1.
Subscribe to:
Posts (Atom)