Results 1 to 15 of 15

Thread: Gunrunner: an experiment in UGC and phased release

  1. #1

    Gunrunner: an experiment in UGC and phased release

    Hi guys,

    I was thinking about a simple game to develop, instead of another unfinishable mammoth project. Now when I start to design, it still has a tendency to develop into something complex, however I think this time I may have come up with a solution to that. I'm interested in what views you guys have on the subject.

    The game premise is simple enough. Your planet is attacked by a huge fleet of spaceships. Knowing that it's a suicide mission, you decide to give them hell before you go. The game is a topdown shooter in which you control a single spaceship and the player can move 360 degrees. Now the further the player moves away form it's home planet the stronger the enemy ships will be.

    I was thinking about this and I figured it would be nice if the enemy ships would be downloaded from a server. Say I start out with a few enemy ship designs in cache. These designs have been rated from 100 to 300 in strength/difficulty. Now the player moves away from the planet and it should encounter enemies in the range 400 to 600. The game has anticipated this by requesting these designs from the server. This would allow me to have a huge range in enemy strength. This would be a project on it's own, but it gave me another idea. Inspired by the Spore Creature Creator I thought, why not create a Ship Creator? Players can design and upload their ships, which get rated by the game through a rating system.

    This would make the game a pretty big project, but I'm thinking about developing them in phases. First I create the editor and release it, so players can start uploading their designs to the database. While they're creating designs I can work on the core game which I can release later on. This allows me to have a database of user generated content while the game ships.

    So I'm interested in what you guys think of this. Do you see any pitfalls or advantages to this approach? I've also posted a more in-depth post on this idea on my blog.

    Update
    build1
    build2
    build3
    build4
    build5

    latest and greatest
    build6
    Last edited by TOdorus; April 29th, 2012 at 01:32 PM. Reason: newer build

  2. #2
    1,391
    posts
    Registered User
    first, although i think that user generated content is appealing - i don't think that anyone will be interested (other than a few friends perhaps) in taking the time to develop designs without being able to 'use' them immediately in a game. so my *opinion* is that it would be better to have your editor within the game itself, after it's mounted.

    second, be careful not to make your game 'dependent' on UGC - it must be able to run on its own.

    third, you'll need a wide variety of 'parts' defined within your system to make the editor interesting enough to garner appeal and provide the 'randomness' of making the UGC viable. if you don't design parts that can be implemented within your engine, you'll have people trying to make 'squirting glue cannons' (lol) that your system doesn't know what to do with, and don't act as expected by the user.

    finally, it seems that this is even a more complex and difficult endeavor than building a stand-alone game, i fact you'll need create 'more' content and systems to handle it, in order to make it successful than in a 'regular' game - if you goal is to define a game that is possible to produce, then i would seriously reconsider your direction here.

    these are just my opinions, i don't mean to discourage your project or concept.

  3. #3
    I appreciate the input cbeech. I have thought about the points you make. The main philosophy is that I can always cut one of the systems (except the game itself ofcourse ) and fall back on the ones that are still there. Now to reply to your points in a less abstract manner:

    Quote Originally Posted by cbeech View Post
    first, although i think that user generated content is appealing - i don't think that anyone will be interested (other than a few friends perhaps) in taking the time to develop designs without being able to 'use' them immediately in a game. so my *opinion* is that it would be better to have your editor within the game itself, after it's mounted.
    This is a valid point. There are some other motivations for me to go about this as well, like generating some buzz around the game. A good tool will also mean that I can recruit a partner to create content a lot easier, as he/she can get started right away.

    Quote Originally Posted by cbeech View Post
    second, be careful not to make your game 'dependent' on UGC - it must be able to run on its own.
    The server may not be avaible for some reason, so I've thought of fallbacks. The game comes with a filled cache of enemy designs. The UGC just adds to that.

    Quote Originally Posted by cbeech View Post
    third, you'll need a wide variety of 'parts' defined within your system to make the editor interesting enough to garner appeal and provide the 'randomness' of making the UGC viable. if you don't design parts that can be implemented within your engine, you'll have people trying to make 'squirting glue cannons' (lol) that your system doesn't know what to do with, and don't act as expected by the user.
    The way the editor is designed now is that a user can upload images and draw polygons to define the collision borders. Each hull is made up out of one or more of these polygons and can have turrets attached to them. The turrets are predefined and cannot be created by the user. As your example demonstrates, this would be far to complex. Battleships Forever is a huge inspiration for this system.

    I always have the possibility of only giving the players pre-defined hull parts which I or a partner have designed. In that case I have the tools I need to create these parts, so they can be easily added and managed. This also allows me to more easily recruit an artist if the editor doesn't prove popular, as he/she will have acces to some solid devtools.

    Quote Originally Posted by cbeech View Post
    finally, it seems that this is even a more complex and difficult endeavor than building a stand-alone game, i fact you'll need create 'more' content and systems to handle it, in order to make it successful than in a 'regular' game - if you goal is to define a game that is possible to produce, then i would seriously reconsider your direction here.
    The different systems is exactly the reason why this project is more managable. The different parts can be developed mostly independent of each other. There is the editor, the backend for the editor, the game and the backend for the game. I estimate I need about a month for each system to develop. This makes it easy for me to use a SCRUM approach to this project, with sprints lasting a month (this is in my spare time after all).

    A final note is that this is a stepping stone to a sequel to Dawn of the Hulker. Gunrunner has pretty much most of the elements of the battle engine I wanted for that sequel. If it also delivers content for the game, I'll only need to expand the AI just a bit and concentrate primarely on the meta-game. This makes Gunrunner a lot more worthwile.

  4. #4
    1,391
    posts
    Registered User
    awesome - sounds like you've got a good plan

    i think (again, opinion lol) that a variety of pre-designed hull parts would be better than having users upload their images - part of the reason would be that then you may get into a system of 'moderation' where people might upload objectionable content, for instance: "myBig****Ship" (lmao) - you may spend most of your waking hours after launch 'approving' uploaded content. but if you do allow it, you may be able to parse the bitmap and plot the poly set without the need for the user to do so - reason may be this: i build the ultimate fighter, and give it the smallest hit area possible - or none at all - or the wrong shape, etc. additionally, if your going to use a physics engine, these shapes are going to play a role in the environment beyond collisions. perhaps a 'snap-together' system might give the most flexibility of design with the least amount of parts necessary.

    i recently (this spring) built a UGC system that runs in physics environment, but the editor is in-game and limited to building levels (tracks and content), rather than vehicles, that you can 'share' with other users - i can tell you, it was complicated (especially under deadline) - but has also had pretty good success with around 1M plays (single site)

    i think there is nothing wrong with your approach, however my experience is that it is far easier to develop within limited bounds of a basic concept, some of the all-time most popular games (casuals) are very simple in nature, it's about the mechanic, and not necessarily the content - additionally, one can build the best editor in the entire universe with awesome graphics, but if the game is not 'fun' to play, it will go nowhere. we always want to build the 'coolest game ever' (guilty), but if you want to get it done, one has to limit the scope - you can always expand it later, or with a sequel.

    just my two cents

  5. #5
    Yeah I was thinking about when I would see the first, ahum, fallus shape appear. I've also looked into tracing the polygon, but damn, that's a tough algorithm. You're right that this would bring to much moderation into the equation. I was hoping the community would be mature enough, but then I remember the complaints of immature behavior bieng one of the biggest annoyances in multiplayer.

    I'm going to take your suggestion on snapping parts. This actually solves the problem of which parts are siblings to other parts. This is so that if a parent is destroyed, all of it's siblings are destroyed to avoid 'floating' parts, when the part linking it to the ships core is destroyed. I do see some technical hurdles to take on detecting which edges to snap to though. Not to mention polygon overlap. I'll have to look into that before I continue. Maybe some kind of hard point system can work there.

    Once again thanks for the input cbeech, sometimes you just need to hear it from someone else, even if it is just on a forum. I'm curious about your UGC game, btw. I like to see how you solved some UGC related problems.

  6. #6
    1,391
    posts
    Registered User
    LOL! yeah it's impossible to know who will be using the game, especially if it will be mass distributed - even when not (site locked), it's not a super idea to rely on the community to 'do the right thing' - some may just think they're being funny.

    think i might work it on a grid system, where you could snap the registration point to any intersection, although this limits design potential somewhat, it ensures that parts are placed in particular locations that 'work' together in some way. if your using WCK (i saw that in the other thread here you'd mentioned) then BodyShapes will act as shape definitions within the parent, so overlap shouldn't be an issue - additionally you could break them apart when a ship is 'destroyed' as part of a blast effect.

    you're quite welcome - i'm just throwing some thoughts out there for ya to chew on

    well... in the game i mentioned, there are a few situations that are very similar to yours here - it does use the WCK, and includes parsing bitmap on the fly, which i wrote a routine for - i needed to be able to stockpile a lot of designs for the base tiles that were built mostly from curved forms, and additionally be able to make quick adjustments in the IDE to any given tile's shape at will. in order to be able to quickly defined the tiles simply by 'drawing' them with a graphic shape, rather than attempting to define each with shape defs or math, i developed a routine to parse them, so that in the end i could add a new tile or change one and simply throw it into the system - think we settled on 68 tiles (?) can't remember - slept since then...

    so in this situation, the UGC aspect was also not the graphics, but a completed 'track' made from a variety of 'parts' that we provided - however one can also place static graphic decorations on multiple layers, as well as physical bodies - plus change the general overall 'look' of each tile via a fill.

    i also chose to use a grid based snap system for the editor rather than a 'drawing' system, this took out all of the issues related to moderation by controlling the possible content, as well as making a general system that is uniform and can actually function in the environment.

    so... HERE it is - interested to hear what you think

  7. #7
    Moving into a new appartment with your gf and no internet connection (as of yet) doesn't really help somebody in replying promptly to a thread. Anyways, glad I can now.

    I looked at your game and liked how you made it really, really simple to get going right away. Just dag and drop. I was considering a similar approach, but now that I've seen it in action I've settled on it. Simplicity is key. Or as some say 'useability', which has to be the vaguest term next to 'making it more sexy'. I want a snapping system, but not let it snap to a grid. I rather want parts to snap to other parts, to allow for some original shapes/design and to solve the sibling problem (which parts are sibling to what part?).

    I've created a few mockups to help me envision this and keep focus.

    Snapping parts together to make a frame
    Snapping a thruster to the frame
    Snapping a turret to the frame

    The thruster idea is making things more complex. First, I need to write an algorithm which checks which thruster configurations should be used for steering left and right,moving forward and backward. This is easy. Now the hard part is, that each ship can have parts shot off. If thrusters are only allowed on the outside of a part, these are pretty vulnerable in most designs and can make ship go 'limp' when a critical thruster is shot off. Now this is cool when you're fighting the AI and you can shoot of a part of it, but it isn't much fun when it's happening to you as a player. A design can fight this by adding armor around thrusters but I think this may be to restrictive. I can think of a few solutions like: repair powerups, thrusters between parts (like a multistage rocket), escape pod. All of these add to the complexity of bieng a fast shooter, so I may decide to allow thrusters on inner hardpoints anyway.

    Luckily I'm almost finished with the frame parts creator so I can quickly create new parts to try out. Hopefully I'll finish the frame parts of the ship editor that the player will use this weekend so I can try some stuff out.

    ps Kick Buttowski? Nice one! One of my favorite shows on the Dutch Nickelodeon.
    Last edited by TOdorus; September 21st, 2011 at 02:54 PM.

  8. #8
    1,391
    posts
    Registered User
    no worries

    yeah - simplicity is key, was really going for that in the system for KB - in this case the grid system helps define what the users are allowed to do, but is also used at runtime as a mechanism for instantiating the tiles and removing them, keeping the fewest possible objects on the stage for processing speed

    i dig the methodology you've got going here in your mockups, i think you're on definitely on the right track, and it should be really cool to 'break apart' the ships when fired on. i also think that part of the 'fun' of the game will be in designing a ship that can 'take it', even on the player side of things, if the ship is not performing because of the placement of elements... well that's part of the challenge of the game right - lookin good

    ps - yeah, was a great client to work for, this is my second version for them, and a lot of fun to work with their asset packages - here's hopin for another iteration next season

  9. #9

    first build

    build1

    This is more of a dev build but it shows a nice proof of concept. Drag a part from the menu on the left and drop it in. The button in the top of the menu is for loading additional parts, from a file, so you can ignore that. The squares in the top left corner are for mirroring, the one in the bottom right corner for removing.

    I see some room for improvement, as the snapping can be a bit wonky. What happens, is that you drag a part in snapping range and it snaps into the new position. If you are still moving your mouse cursor (which is pretty probable) it could snap again in the newly rotated position. This can occur a few times before the part settles in some situations. I'm thinking of having a small delay on dragging when snapping, but I'm yet to experiment with this. Any feedback on that would be most welcome.

    I've tried out some designing with just these parts and I found out my thruster worries weren't that legitimate. I could get some designs which had places for thrusters and backup thrusters while offering them protection. I found it wasn't that hard and added to the design challenge for a player.

    Just ordered a vps as a development server, so I can continue on some backend stuff while I think about how to improve the usability of the shipcreator.

  10. #10
    I've been in less than perfect health the last couple of days, so I've only looked at some possible backend services, namely GamerSafes LevelVault and Parse which is used by Playtomic (interesting api btw). Too bad none of these live up to my standards, which are pretty high because I can build a webapplication of my own. Parse had the addition of having a cost per request and data entry, which is a really weird pricing model. To redeem the costs per play of that service I'd have to use the highest volume subscription and I can host a pretty high end vps for that kind of money (damn those things are cheap these days).

    So today I did a little actual development and upgraded the ship creator a bit. Now it should properly show which slots are still available. There is an exception to this, but I've only been able to produce it once, so I guess that's a bug I can live with. I've also marked the 'master part'. For those of you who won't read the designdoc: every part of the ship must be (in)directly linked to the master part. You can let parts overlap, but I'm gonna let that slide. I don't see a way to exploit it to the point that it would be cheating. If no one else can see a way for that, I'm not gonna let it restrict creativity.

    So without further ado:
    build2

    And for anyone interested enough to look through a few pages here's the semi-permanent link to the designdoc: linky

  11. #11
    The creator is almost finished. I decided to use compositing for turrets and thrusters, so now everything is considered a framepart. Difference is that some parts have a turret, thruster, armor or a combination. This immediatly gave me a problem. Why not make a ship which is nothing but thrusters, armor and guns? So I added the rule that a turret/thruster part does not link other parts to the main part.

    Now, since I've got the weekend off and I just figured out how to setup Starling and a good way to connect all of this to a physics engine and my ship format by using VO's... I'm going to add my View to the editor by using Starling for rendering. Heck I'll probably be able to support zooming! Flash11 brings out the little kid + candystore in me. Let's see how far I'll get.

    So I'm off to find out some temp artstyle and a pipeline to easily push art to a Starling game. I got some prototyping to do.

    Oooh candystore!

  12. #12
    I ever hold the conception of exclusive gift the players pre-defined diplomat parts which I or a partner hit premeditated. In that sufferer I score the tools I pauperization to create these parts, so they can be easily superimposed and managed. This also allows me to statesman easily starter an artist if the editor doesn't evidence common, as he/she give possess acces to several solid devtools.





  13. #13
    I opted for ND2D instead of Starling. According to my speedtest ND2D uses a little more memory than Starling, but unlike Starling ND2D isn't built on another framework meant for mobile (well, we all know how that's working out for Adobe). I also love the opensource approach of ND2D. I had to get acquinted to GiT, but man, why did I work without that before? I'm trying to get this introduced at work as well.


    So Blasting Forever (yes Gunrunner has a name now) now uses a combination of Stage3D/ND2D and Stage/Flex to render. The polygons of yonder build are now used to dynamicly draw textured parts and I've created a pipeline to easily add premade images for those special parts like turrets,thrusters and beautification (cockpit, radar dish). And less interesting, I can exclude polygon edges from having connection slots. The result, with some borrowed temporary art, is a whole lot sexier than it was. I wanted to get some more skinning & polishing done this weekend, but hey, gotta get up for work tomorrow





    Enjoy,


    build3

  14. #14

    Finally!

    build5

    Changes
    • You can testdrive your ship! (arrow keys to control)
    • Top slots
    • Dislocaters
    • Animated parts
    Well, I had to put in some good hours at work the last few months, learning the Android framework while building an app for a customer who knows what he wants is taxing. It's also rewarding, as I've delivered a pretty lean and mean app. I can't wait 'till it hits Google Play. This did took away any dev time I had on Blasting Forever for a good few months.

    Also, optimizing a steering solution with just thrusters is damn near impossible. You have to do almost everything perfect in order to make that happen. After a month of trying I decided to kill my darling. Instead of thrusters there a now "dislocaters". A dislocater can add forward, backward and side thrust as well as torque, depending on the type, but it can be placed anywhere on the ship. That made stuff A LOT easier for the AI to handle The dev build features a rotation and a forward/backward dislocator.

    Anyways I added top slots. These are there to place dislocaters, modules (shields, energy generators), turrets etc on. At the moment there can be only one top slot per part. I may remove this limit in the future, but I'll first try how this balances out.

    I've also experimented with dynamic music waaay back, but the prototype is promising. I can now switch between music loops without skipping, by directly adding the bytes to the soundbuffer. The idea is to have a musical score with loops that vary in intensity, so the games score can always match the intensity of the gameplay. In other words: if the gameplay gets more frantic, so does the music. I'll have to find someone to write me some cool music though. I'm no star at that.

  15. #15

    Asteroids 2.0



    You can finally blast in Blasting Forever. But what fun is blasting if there's nothing to blast? Them 'roids look mighty blastable.

    build 6: Asteroids 2.0


    And of course, spacebars are for pulling triggers.

    New features
    • Blasting!
    • Object spawning
    • Camera
    And for those interested: pressing 1 and 2 will bring up nape debugging and a profiler respectivily

    Next build will be a pretty uninteresting one. I'm going to take a good look at the editor and the prerendering pipeline (I'm just pushing a new texture for every object, hardly optimized). I'll use any complaints or feature requests regarding the editor posted here as a starting point for the editor.
    Last edited by TOdorus; April 29th, 2012 at 01:35 PM. Reason: typo & link

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Home About kirupa.com Meet the Moderators Advertise

 Link to Us

 Credits

Copyright 1999 - 2012