So far, our games have been lacking a major feature: interaction with other players. This kind of thing is extremely important, especially the kind of player to player interaction that creates competition. An experience where you are isolated can be nice, but even a crappy game can do well if it correctly utilizes a competitive player base! Thus, Pongfinity shall have high scores.
Kongregate provides a nice little API that can be used to update statistics that they track for you. It is relatively easy to implement, although somewhat restricted in what you can do with it. However, all we need is some simple high score tracking, and this does the trick quite nicely. A little Javascript, and suddenly our game becomes much more enjoyable, because you get the opportunity to compete with other people.
In the finished game, the goal is to have high scores for each difficulty level, and then an overall high score. We may also keep track of "low scores", or the worst scores that occur as a sort of fun-factor. We'll also be implementing achievements into the game that correlate with completion of milestone scores and defeating difficult challenges.
Thursday, March 1, 2012
Wednesday, February 29, 2012
Weekly Update 1: 2/26/12 - 3/3/12
These weekly updates are going to be a regular thing from now on, so hopefully you can look forward to some more regular updating from us!
Yes, the use of the word "us" is important: it is now officially two of us here at Syntactic Sugar Studio! Brenner Remund is the current business manager (who may also do some minor code, and participate in design). We're very excited about our new partnership, and to be at the head of something that will hopefully come to fruition.
The first big item of news is that we are currently working on incorporating. We want to be a true blue LLC, and that is Brenner's first big project. Turns out that even though there is quite a bit involved in creating a company, it can be done without legal counsel relatively easily. We hope to have finished the incorporation process by the end of March, at which point we'll have some sort of celebration to mark the event.
The second big news item is that Pongfinity, our first major production, is coming pretty close to completion. I've been re-working a lot of the code, and tweaking a lot of the balance. So far, Unity and Kongregate have been playing well together in a way that is extremely pleasing. We're beyond excited to see that finished product up on a public website where people that we didn't refer can play it, and it can then spread by word of mouth. In all, it's a very energetic time for us, and mostly because the labor we've put in is finally showing us some real results.
The last item of news is that we are looking for artists. We need some professional looking logo art, something that will help to set us apart from everyone else. If you know or are someone who might be interested in this, please let us know either here in the comments, or email us at the email provided in our about section. Just know that we are pretty poor at this point, so it won't pay well (if at all), but we'd love to credit you in game and spread around your work.
Thank you to everyone who reads this, and have a fantastic week!
Yes, the use of the word "us" is important: it is now officially two of us here at Syntactic Sugar Studio! Brenner Remund is the current business manager (who may also do some minor code, and participate in design). We're very excited about our new partnership, and to be at the head of something that will hopefully come to fruition.
The first big item of news is that we are currently working on incorporating. We want to be a true blue LLC, and that is Brenner's first big project. Turns out that even though there is quite a bit involved in creating a company, it can be done without legal counsel relatively easily. We hope to have finished the incorporation process by the end of March, at which point we'll have some sort of celebration to mark the event.
The second big news item is that Pongfinity, our first major production, is coming pretty close to completion. I've been re-working a lot of the code, and tweaking a lot of the balance. So far, Unity and Kongregate have been playing well together in a way that is extremely pleasing. We're beyond excited to see that finished product up on a public website where people that we didn't refer can play it, and it can then spread by word of mouth. In all, it's a very energetic time for us, and mostly because the labor we've put in is finally showing us some real results.
The last item of news is that we are looking for artists. We need some professional looking logo art, something that will help to set us apart from everyone else. If you know or are someone who might be interested in this, please let us know either here in the comments, or email us at the email provided in our about section. Just know that we are pretty poor at this point, so it won't pay well (if at all), but we'd love to credit you in game and spread around your work.
Thank you to everyone who reads this, and have a fantastic week!
Thursday, February 16, 2012
A Sprint Day
I wanted to see what I could accomplish in a short period of time with Unity3D. So I did.
First, let me say that Unity is not my favorite way to program. However, it is absolutely fantastic for creating games. We've had a real love/hate relationship, but we're working things out. The more I practice with it, and the more I get used to its way of doing things, the more I like it. I'm especially ecstatic about the speed with which I can get things working, and how fast I can see results.
So today, I decided to make a pong clone. I've tried this before with Unity, but I went about it in such a way that made it very difficult. Now, especially with all the practice I got from the GGJ, I had a better idea of how to do it. The major problem I had before was with controlling the pong ball itself. I ended up settling on a kinematic rigidbody, and manipulating the ball movement using only vectors. For those of you interested, the formula for a reflection is: r = i - (2 * n * Dot(i, n)), where i is the incident vector, and n is the normal of the vector being reflected off of.
Without further ado, play the result here: http://www.kongregate.com/games/Bloodyaugust/pongfinity
Note: that this was posted on 2/16/12, so things may have changed by the time you read this. Heck, the link may not even work.
Happy gaming all! :D
First, let me say that Unity is not my favorite way to program. However, it is absolutely fantastic for creating games. We've had a real love/hate relationship, but we're working things out. The more I practice with it, and the more I get used to its way of doing things, the more I like it. I'm especially ecstatic about the speed with which I can get things working, and how fast I can see results.
So today, I decided to make a pong clone. I've tried this before with Unity, but I went about it in such a way that made it very difficult. Now, especially with all the practice I got from the GGJ, I had a better idea of how to do it. The major problem I had before was with controlling the pong ball itself. I ended up settling on a kinematic rigidbody, and manipulating the ball movement using only vectors. For those of you interested, the formula for a reflection is: r = i - (2 * n * Dot(i, n)), where i is the incident vector, and n is the normal of the vector being reflected off of.
Without further ado, play the result here: http://www.kongregate.com/games/Bloodyaugust/pongfinity
Note: that this was posted on 2/16/12, so things may have changed by the time you read this. Heck, the link may not even work.
Happy gaming all! :D
Sunday, January 29, 2012
Global Game Jam Post-Jam Write Up!
Fun. It's all about fun. In the end, fun is what was had, and fun is what I looked forward to. I met people, I learned new things, and above all, I had FUN!!!
This has been a fantastic experience over all! It differs from LudumDare, in that I was able to really expllore the social aspect of a game jam. Indeed, it brought the entire dev experience to an entirely new level for me. This has been my first major experience with a team that included non-programmers, and was larger than two people. Overall, just a great experience!
AS far as takeaway goes, PLEASE UNITY FOR THE LOVE OF ALL THAT IS HOLY LET SUBVERSION DO ITS JOB!!!!!!! In other news, a great team lead really makes things come together, and we certainly had one. The only major screw-up we had was to do with Unity, so not really our fault.
I'll post a link to the game soon...
This has been a fantastic experience over all! It differs from LudumDare, in that I was able to really expllore the social aspect of a game jam. Indeed, it brought the entire dev experience to an entirely new level for me. This has been my first major experience with a team that included non-programmers, and was larger than two people. Overall, just a great experience!
AS far as takeaway goes, PLEASE UNITY FOR THE LOVE OF ALL THAT IS HOLY LET SUBVERSION DO ITS JOB!!!!!!! In other news, a great team lead really makes things come together, and we certainly had one. The only major screw-up we had was to do with Unity, so not really our fault.
I'll post a link to the game soon...
Sunday, December 18, 2011
LD48 Post Competition Write-Up
This LudumDare, I didn't have *nearly* the time or focus compared to the last one. I had family pictures, a huge family party, EATING, etc. I think I probably got in 20 hours of solid work, minus about 6 that didn't get used. Here's the broken down takeaway:
1. DO NOT START PROGRAMMING BEFORE PSEUDOCODE/DESIGN IS DONE. This caused me to lose a MASSIVE amount of time. Had I done about an hour more of design and planning, I would've moved right past my first implementation, and would have gained 5 hours of time. My entry would've been much more complete.
2. DO NOT TRY TO MIX GAME TYPE/CONCEPTS. It is great for long term development, but it just can't be done in 48 hours.
3. KISS. "Keep it simple, stupid" should be the tagline for the entire competition.
4. DO PLACEHOLDER ART FIRST. Trying to do artwork before coding an engine, and really the entire game, is BAD.
5. Don't go to family Christmas parties.
In all, I wrote 994 usable, end product lines of code. The one thing I did really well this competition was HAVE ALL MY USEFUL CODE IN A FRAMEWORK. That was spectacular, and saved me tons of time.
Download the game here, or in the downloads page.
Happy gaming!
1. DO NOT START PROGRAMMING BEFORE PSEUDOCODE/DESIGN IS DONE. This caused me to lose a MASSIVE amount of time. Had I done about an hour more of design and planning, I would've moved right past my first implementation, and would have gained 5 hours of time. My entry would've been much more complete.
2. DO NOT TRY TO MIX GAME TYPE/CONCEPTS. It is great for long term development, but it just can't be done in 48 hours.
3. KISS. "Keep it simple, stupid" should be the tagline for the entire competition.
4. DO PLACEHOLDER ART FIRST. Trying to do artwork before coding an engine, and really the entire game, is BAD.
5. Don't go to family Christmas parties.
In all, I wrote 994 usable, end product lines of code. The one thing I did really well this competition was HAVE ALL MY USEFUL CODE IN A FRAMEWORK. That was spectacular, and saved me tons of time.
Download the game here, or in the downloads page.
Happy gaming!
Thursday, December 15, 2011
The Wonders of Collision Detection
Up to this point, collision detection has been a point of much internal dialogue for me. For instance, per-pixel collision tests are as accurate as it gets, and they provide a wonderful amount of positional information useful for many different purposes. However, it can get to be extremely expensive on the processor and GPU, so in most cases it isn't really an option.
For a while, I thought that rectangle based collision was the holy grail. It's fast, it's easy, and there's still vital mathematical information to be easily gleaned. Just try rotating your rectangles though, and you'll quickly realize that existing methods purely for rectangles will be broken.
After that, I moved on to circles. Circles are wonderfully inexpensive, and absolutely the easiest to implement. Even after parenting and otherwise layering them though, you still get pretty inaccurate collisions in a lot of cases, such as objects with sharp angles. This can be minimized, but it takes a large amount of effort and can end up negating the speed gained over other methods.
Finally, I am where I am today. Convex polygons, as of this week, are my favorite method. I spent hours poring over different sites and their explanations of the Separating Axis Theorem. I looked at source code, I performed tests, I even looked in my Calculus textbook for help (no dice). Eventually it clicked for me, and it works wonders.
Still, there are grounds that have to be given up. SAT only works for convex polygons, which can be a bit of a hassle. You can represent any concave shape with multiple convex ones, but that is beside the point, and automagically creating multiple convex shapes from a concave source is something I have yet to understand. Also, while this method is relatively fast, it still isn't anywhere near as fast as its circle counterpart.
It is obvious to me at this point that compromises will have to be made with any method of collision, and even programming as a whole. Unfortunately, that doesn't keep it from bugging me...
For a while, I thought that rectangle based collision was the holy grail. It's fast, it's easy, and there's still vital mathematical information to be easily gleaned. Just try rotating your rectangles though, and you'll quickly realize that existing methods purely for rectangles will be broken.
After that, I moved on to circles. Circles are wonderfully inexpensive, and absolutely the easiest to implement. Even after parenting and otherwise layering them though, you still get pretty inaccurate collisions in a lot of cases, such as objects with sharp angles. This can be minimized, but it takes a large amount of effort and can end up negating the speed gained over other methods.
Finally, I am where I am today. Convex polygons, as of this week, are my favorite method. I spent hours poring over different sites and their explanations of the Separating Axis Theorem. I looked at source code, I performed tests, I even looked in my Calculus textbook for help (no dice). Eventually it clicked for me, and it works wonders.
Still, there are grounds that have to be given up. SAT only works for convex polygons, which can be a bit of a hassle. You can represent any concave shape with multiple convex ones, but that is beside the point, and automagically creating multiple convex shapes from a concave source is something I have yet to understand. Also, while this method is relatively fast, it still isn't anywhere near as fast as its circle counterpart.
It is obvious to me at this point that compromises will have to be made with any method of collision, and even programming as a whole. Unfortunately, that doesn't keep it from bugging me...
Wednesday, December 14, 2011
Pathfinding (And Resuscitation)
Okay, so it's been a little while since anything went up here.
A long while.
Now that admissions of guilt are over, to the future! For the past couple of weeks I've been preparing for LudumDare #22 (click the link for a description if you don't know what that is), working out some problems that afflicted me last time, trying out some new concepts, getting better at commenting my code, and just generally practicing. I can't tell you how excited I am! No really, I can't. My motivation is a little bit gone at the moment, I've been quite sick this week.
Regardless, I *will* be participating, and I'll force myself to like it if I have to.
Today, I managed to implement some relatively simple pathfinding in a node-based system. Essentially, you split your playing map into nodes. You assign each node a list of neighboring nodes. After giving the system a starting node and an ending node, it determines which neighboring node has the shortest distance as the crow flies to the ending node, then makes that node the current node. This process is repeated, adding every node that has been visited to a "closed" list that it will not re-visit. Once the ending node is reached, the closed list becomes your path!
My system will *always* find a path if one exists (which is possible that it doesn't, considering some nodes are "unwalkable"), although it will not always be the shortest. It works well enough to satisfy me though! Especially since I spent all of my waking day throwing my currently broken brain at this problem, and all I've got is a barely working algorithm that is some 50 lines of code long... XP
Anyways, thanks for reading, and look for more posts from me soon!
A long while.
Now that admissions of guilt are over, to the future! For the past couple of weeks I've been preparing for LudumDare #22 (click the link for a description if you don't know what that is), working out some problems that afflicted me last time, trying out some new concepts, getting better at commenting my code, and just generally practicing. I can't tell you how excited I am! No really, I can't. My motivation is a little bit gone at the moment, I've been quite sick this week.
Regardless, I *will* be participating, and I'll force myself to like it if I have to.
Today, I managed to implement some relatively simple pathfinding in a node-based system. Essentially, you split your playing map into nodes. You assign each node a list of neighboring nodes. After giving the system a starting node and an ending node, it determines which neighboring node has the shortest distance as the crow flies to the ending node, then makes that node the current node. This process is repeated, adding every node that has been visited to a "closed" list that it will not re-visit. Once the ending node is reached, the closed list becomes your path!
My system will *always* find a path if one exists (which is possible that it doesn't, considering some nodes are "unwalkable"), although it will not always be the shortest. It works well enough to satisfy me though! Especially since I spent all of my waking day throwing my currently broken brain at this problem, and all I've got is a barely working algorithm that is some 50 lines of code long... XP
Anyways, thanks for reading, and look for more posts from me soon!
Subscribe to:
Posts (Atom)