Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

1204 Excellent

About JBourrie

  • Rank
  1. I recently shipped Smash and Dash using the Soomla libraries for MTX purchases, and highly recommend it.  Took less than a day to integrate, handles your currencies and shop items in an elegant way, and is cross-platform in case you ever do an iOS port of your game.
  2. JBourrie

    Stopping the "Too many projects" syndrome

    I differentiate "projects" from "prototypes": I will build any number of prototypes, but each one is in a very specific timebox (usually 5-15 hours of work total).  Once I have a prototype that screams "this needs to be finished", it's much easier for me to focus on that as my "one project" until it's ready - then, back to prototyping mode!   My recent project Smash and Dash was initially built as a 3-hour prototype.  It turned out really fun, so I decided to build it but I strictly timeboxed it as an 80-hour project, which let me finish and release it in the same month!  Doesn't mean the game is "as finished as it will ever be" - just that it's finished enough to release version 1.0, and I can continue with it as I see fit.   So for me, very strict timeboxing coupled with a "lots of prototypes lead to one project" mentality helps me keep Too Many Projects Syndrome at bay.
  3. Update: It's now available on the iTunes App Store!
  4. Thanks!   Built in Unity, using Soomla for microtransactions, RevMob for advertising, and the Google Play Services API for Achievements and Leaderboards.  I definitely recommend Soomla (makes microtransactions super-easy) and Google Play Services + Unity allowed me to add Google+ support, 22 Achievements & 2 leaderboards in about 10 hours of work.   Jury is still out on RevMob, I'll need more users before I can make a judgement on them.
  5. Hey guys, it's been a long time!  I was very active in these forums about 8 years ago when working on my last indie game Rumble Box - since then, I've been working for "the man" and kind of fell out of indie work...   Well - now it's time to give it another try!     I just launched my new game Smash and Dash for Android and it's up on Google Play.  It was a sort of "personal game jam" project built in 81 hours, and now it's starting to pick up some steam.  Check out the trailer below, and if you like what you see please give it a download, a rating & a Like on Facebook.   Thanks everyone, and I look forward to seeing you on the leaderboards!   Joe Bourrie Syncoplay Games   -----------------------------------------------------------------       Trailer   Google Play Store https://play.google.com/store/apps/details?id=com.Syncoplay.SmashAndDash   iTunes App Store https://itunes.apple.com/us/app/id859234769?mt=8   Facebook Page https://www.facebook.com/smashanddashgame
  6. JBourrie

    "Opportunity to design our game."

    "[color="#1C2837"]To J, I think you should look up the word "idealistic" in a better dictionary, because it absolutely doesn't apply here." [color="#1C2837"]You're right, I misused the term. The point, however, is the same. [color="#1C2837"][color="#1C2837"]Artists work very similarly. If you walked into a restaurant that was $500 a plate on average for a full meal and said to your waiter "Hi, I only have $50, but give me the $500 meal instead", they'd either not serve you at all (an artist not agreeing) or tell you to order something cheap if they want your money (get you to cut down the detail and work that goes into a piece). [/quote] [color="#1C2837"]Both of those outcomes are the artist setting the expectations: educating the designer on what is possible. Both of them are good outcomes, because some of the worst issues in game development come from improperly-set expectations. [color="#1C2837"][color="#1C2837"] "Putting your name on something special" doesn't pay any bills, so why should you expect the motivation for that?[/quote] [color="#1c2837"]If the guy paying the bills expects that motivation, then "Putting your name on something special" absolutely pays the bills. All I'm saying is that I'm of the mindset that if I'm paying the bills I expect motivation and engagement. [color="#1c2837"][color="#1C2837"]Your proposal assumes that devs are actually smart enough to realize they have to pay for a consult. They're not. It's not on the artist to tell the dev what the dev should buy from them, it's up to the dev to ask.[/quote] [color="#1C2837"]This sounds shady. An expert being asked for their services is expected (at least in the world I live in) that they will treat you fairly and not use "well, I didn't tell you because you didn't ask" as a cop-out after an underwhelming delivery. I would interpret anything else as withholding information from a business partner. [color="#1c2837"][color="#1C2837"]How many devs pay artists per hour, instead of per piece? If it was a matter of paying per hour, then an artist could let you know easily how many hours something takes and give it to you.[/quote] [color="#1C2837"]I would hope that when estimating a piece, you would calculate how many hours you plan to spend on it. You don't have to give that info out to the person hiring you, but when you do that inevitable estimate, that's when I suggest that you add the buffer time. [color="#1C2837"]I think we are coming from very different places, but we both seem to be talking from personal experience. Obviously you've felt screwed in the past by a development team who you felt expected too much for too little. I have also felt screwed in the past, by outsourcers who expected full payment for delivering base mediocrity: a bait-and-switch tactic that dragged on for nine painful months and ended in an amazing game being canceled. I'm definitely bringing that experience into this conversation, both consciously and unconsciously, in the hopes that people realize that the people hiring you trust your expertise. They trust that you are an expert at making your part of the game the best it can be. And when your goal is counter to that, such as "no time to iterate or improve, just get the job done quickly so I can move on" then it hurts the whole project. [color="#1C2837"]Anyway, different experiences, different expectations. I don't think you're wrong (in fact, I've experienced first-hand that you're right in many cases), I just don't believe its the way things should be: a team is a team - not just a collection of people. The tone of this thread struck a sore spot with me, because while the goal was pure, it was framed in a way were it basically was saying "expect and accept an unengaged artist unless you want to pay a premium". I don't accept an unengaged team member, so matter what his role.
  7. JBourrie

    "Opportunity to design our game."

    [color="#1C2837"]Agreed - game development is [s]hard tedious[/s] 90% tedious, 10% the most fun I've ever had with my clothes on.
  8. JBourrie

    "Opportunity to design our game."

    Sorry for the double post, but something just occurred to me: maybe part of my problem is that we are referring to "artists" and "developers" as if they are different people. They're not. "Artists" and "Engineers" are both developers, or more accurately they make up the Development Team. Nobody's special, and yet everybody is. We all have to make the same types of compromises, and I encourage engineers to plan "buffer time" for iteration and team engagement just as I encourage artists to do the same.
  9. JBourrie

    "Opportunity to design our game."

    Agreed - game development is hard. Revisions late in the project are very hard. So plan time for them, that's all I'm saying, because iteration is the key to quality. If you don't iterate, your game won't be as good... guaranteed. Plan for additional time on top of your art for iteration and team engagement, and scope your art accordingly. Unless, of course, your team is in "damn the torpedoes, lets just get something out the door" mode. Then all bets are off, my whole argument falls apart, and quality goes out the window. I've been on those projects too, and they are the most depressing times in my career.
  10. JBourrie

    "Opportunity to design our game."

    You're right, my post was idealistic. I'm the first to admit that I am an idealistic person: in fact, I am proud of it Also note that your posts are idealistic as well: they're just supposing a different ideal. --------------- My Ideal: When I hire somebody to work on my game, my expectations are that they make the game better. That I'm not hiring a monkey to do monkey's work, but that I'm hiring somebody with motivation to put their name on something special. What this seems to sound like to you: I expect absurd amounts of overtime working on things other than your typical art. I don't, by the way. --------------- My interpretation of your ideal: Developers paying below a certain amount should just let you create whatever base content they ask for, and be happy with whatever they get. What your ideal sounds like to me: If I order a steak, and the restaurant agrees to give me a steak, and then I get a burger patty smothered in ketchup, I'm going to send it back and ask for a steak. --------------- My proposed solution: Scheduling for the time spent being engaged: iteration time, team discussions, etc. If Dev X is paying you for 50 hours worth of work, plan your pieces so that they will take 40 hours to complete. You might have to compromise some of the details, but that extra 10 hours becomes team-time. It becomes the time that you can really get invested in what you're doing, talk to the designers to find out how to improve the game, etc. I schedule for 5-hours of "real" work per day: very few people on our team schedule for more than 6, because we know that there is a bunch of "non-real" work to do each day as well. Then the project you're working on gets scoped accordingly. If the dev you're working with doesn't understand this logic, you always have the right to not take the deal. This means you might have to spend 10 hours on that piece that you planned to spend 15 on, + 3 hours iteration based on team feedback + 2 hours buffer. The loss of detail will only be noticeable to you, I guarantee it. Most artists I know are perfectionists about their work, and it looks "shippable" long before they actually call it done. --------------- So what I'm saying is that I agree that you should not be asked to do more than you're being paid for. I'm saying that many developers think they are paying you for engagement, not just for art. Maybe you should ask this up-front, and if they're looking for more than just art you should schedule that into your time.
  11. JBourrie

    Unity 3D - Worth Learning?

    Personally I avoid JavaScript in Unity like the plague. I find it harder to learn, easier to write bad code, and generally less powerful than using C#. Sure, there are a few places where C# code is slightly more complex than the JS counterparts, but overall I think it's alot better. Plus, C# is more widely adopted as a scripting standard, so moving from Unity to other engines you can take that knowledge with you.
  12. JBourrie

    So you want to be a real programmer?

    Why? I feel like most people says this but that language actually makes a lot of jobs easier. Sure there are a couple of things in Java thats 'weird', but I wouldn't go to say that java sucks. Its actually isn't thaaaat bad as people display it out to be. Maybe you can show me why exactly java sucks? Is it all the libraries it provides? Or the automatic garbage collection? Or all of the exception safety it has? Or all the libraries it provides? or all the libraries it provides? Or is it because its not manly enough? [/quote] I think all of the Java-hate out there is mainly by C# users, because C# (in most cases) is a better designed and more effective programming language for the "average" application. Of course, even then it's only sucks relative to C#. In fact, it's a pretty decent language with good performance, support across nearly every platform in existence, and C# wouldn't even exist if Java didn't. Even though I try to avoid using Java whenever possible (I try to stick with C#), I'd favor it over lower-level languages (like C++) or script-like languages (like Python) for most applications.
  13. Flash is very different than C++ programming, but no more complex. It does require a somewhat different way of thinking, though. 1) Flash is much more limited in how you engineer your program: there are certain patterns it is designed for, and others that it really doesn't like. If you try to bend Flash to your will, you will fail. If you play nicely with Flash and work within its constraints, you'll do ok. 2) Flash "logic" feels really messed up if you're used to working in a function-oriented language. It's basically a big timeline, and game logic happens by jumping around between frames. It's a holdover from the fact that Flash started as an animation tool, and in my opinion it makes any game development in Flash feel like a dirty hack... but hack or not, that's how it is. Overall, learning C++ was alot harder than learning Flash will be. My experience has been that I tried using Flash and just felt like using it to build a game was like trying to fit Shanghai into a shoebox, but your results may vary
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!