Game Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »

Unormal: Nov 16, 2004; Mod sass? This evening?! But the cakes aren't ready! THE CAKES!; Fun Shoe

SlightlyMadman posted:

It's not the fact that it's attached to a GameObject, so much as that it all has to be in a single function in a single script. I'd prefer to split things out into separate scripts by function, so I have one script for UI, one script for terrain generation, one script for AI, etc.

edit: Unless you're saying it doesn't? I was replying to xyzzy's suggestion of "putting an empty in your game world and attaching a script to it, putting all your logic in the Update() function."

It doesn't. You're free to build whatever giant software system you want, however you want. You essentially just need a game object somewhere to instantiate your management system during OnAwake (or whatever) to at least be notified when a new frame happens via Update (or whatever) and pass that fact along to your management system. A "blank" game object like people describe just serves as your portal into the notifications/events that unity exposes. You can just put a monolithic script in there, or use it to just call delegates on/post events to your MASTERWORKSYSTEM, or something in between.

Unormal fucked around with this message at 18:01 on Apr 12, 2013

# ? Apr 12, 2013 17:59

Adbot: ADBOT LOVES YOU

# ? May 12, 2024 05:12

Chunderstorm: May 9, 2010; legs crossed like a buddhist
smokin' buddha
angry tuna

So I've got my senior project coming up for next year and decided to form an indie team rather than jumping on the large team project. We've settled on an RTS, so I was wondering if anyone has used the Fury Framework plugin for Unity. It seems impressive and has built-in networking :woop:

but I wanted to know if there were any hitches I should know about or plan for before I drop 100 bucks on it.

# ? Apr 12, 2013 18:20

SlightlyMadman: Jan 14, 2005

Unormal posted:

It doesn't. You're free to build whatever giant software system you want, however you want. You essentially just need a game object somewhere to instantiate your management system during OnAwake (or whatever) to at least be notified when a new frame happens via Update (or whatever) and pass that fact along to your management system. A "blank" game object like people describe just serves as your portal into the notifications/events that unity exposes. You can just put a monolithic script in there, or use it to just call delegates on/post events to your MASTERWORKSYSTEM, or something in between.

Right, I get that, my problem is that I'm not instantiating the Script1.cs object, so I have no idea how to access it from another script. The only way I can think of doing so is with a singleton class since I can use static methods. I thought there must be some way to have one script reference another script, but it sounds like you're all saying that most people just cram every single line of code into one update function, so I guess there's not.

I was hoping there was something like "Script1 s1_instance = UnityEngine.GetInstance(Script1)" but if there's not then I'll just use a Singleton and move all of my business logic out of the gameobject scripts.

edit: To be more clear, here is one very specific example:

Let's say TerrainGenerator.cs has an array called "GameGrid".
I have a script InputController.cs that handles mouse clicks.
On a mouse click event in InputHandler, I want to reference TerrainGenerator's "GameGrid" array so I can switch a bit inside it, but I can't figure out how to access the TerrainGenerator object that Unity created from within my InputController object.

The only solution I can think of is to create a "GameSingleton" class that stores the GameGrid property, so in InputController I'd just call:
"GameSingleton.GetInstance().SetGameGrid(x, y, 1)"

If I were using PyGame or something else code-based, I'd have created the TerrainGenerator and InputHandler objects from a parent class that handles everything.

SlightlyMadman fucked around with this message at 19:10 on Apr 12, 2013

# ? Apr 12, 2013 19:03

devilmouse: Mar 26, 2004; It's just like real life.

SlightlyMadman posted:

Right, I get that, my problem is that I'm not instantiating the Script1.cs object, so I have no idea how to access it from another script.

You can split the difference and have a singleton gameobject / script which extends the normal MonoBehavior stuff so you can use the usual functionality of update() and the like.

Note: This is in Haxe, but it's pretty straightforward to turn in to C#.

Here's a snippet of the relevant stuff from our Dispatcher:

code:


class ServerDispatcher extends MonoBehaviour {

...
  private static var m_instance:ServerDispatcher;

  function new() {
    super();
    // initialze stuff
  }

  public static function getInstance() : ServerDispatcher {
    if (m_instance == null) {
      var gameObject:GameObject = new GameObject("ServerDispatcher");
      m_instance = cast( gameObject.AddComponent("ServerDispatcher"), ServerDispatcher);
    }
    return m_instance;
  }

  private function Update():Void {
    // Process stuff
  }
    
  public function dispatch(request:ServerRequest, immediate:Bool=true) : Void {
   // dispatch stuff
  }
...
}

Then in any other script, we can call:

code:

ServerDispatcher.getInstance().dispatch( new ServerRequest(ServerFunctionThing, []) );

edit: NM - you edit'd while I was writing this and said the same thing!

# ? Apr 12, 2013 19:17

SlightlyMadman: Jan 14, 2005

I also just found this:
http://docs.unity3d.com/Documentation/ScriptReference/index.Accessing_Other_Game_Objects.html

That should help me do the same thing as well, so I think that's enough for me to go on.

# ? Apr 12, 2013 19:18

SuicideSnowman: Jul 26, 2003

You can call {scriptName}.{method} to access a method from another Unity script.

# ? Apr 12, 2013 21:09

SlightlyMadman: Jan 14, 2005

SuicideSnowman posted:

You can call {scriptName}.{method} to access a method from another Unity script.

Huh, I'll try that tonight. Are you sure that's not just for static methods? The only way I could see that working is if Unity does some sort of preprocessing before it compiles, since that shouldn't be valid c# syntax.

Either way, the link I posted above has tons of techniques for accessing other scripts or game objects, so I should be all set. I figure I'll have a single primary game script, but store most of my persistent data in a library class that has some singleton access so it can be polled directly if needed, but my miscellaneous scripts can mostly just call back to the primary game script with GetComponent()

SlightlyMadman fucked around with this message at 21:51 on Apr 12, 2013

# ? Apr 12, 2013 21:44

SuicideSnowman: Jul 26, 2003

My bad, I'm not positive that it works with methods but it does work with variables (as long as the variable is public).

# ? Apr 12, 2013 21:49

SlightlyMadman: Jan 14, 2005

SuicideSnowman posted:

My bad, I'm not positive that it works with methods but it does work with variables (as long as the variable is public).

Hmm, if it's standard c# code it shouldn't unless the variable is also static. Maybe it's a javascript only thing?

# ? Apr 12, 2013 21:52

Bondematt: Jan 26, 2007; Not too stupid

You'll need to cache the script before you can call it.

so say you have a class called Wind on an object named WindObject.

if you just want the script, then in the script you want to be able to access from:

code:


public class Class {
   public GameObject windObject;

   Wind wind;

   void Start () {
      wind = windObject.getComponent<Wind>();
   }
}

Then you can access all public members and public variables from anywhere in that class. By just using wind.whatever

Edit: And you'll need to set windObject in the editor for this method, you can also use GameObject.Find to get it as well.

Edit2: You can also just set the script in the editor too:

code:

	public Wind wind;

Then you just drag whatever has the Wind script onto that, and Unity will handle getting the script.

Bondematt fucked around with this message at 22:03 on Apr 12, 2013

# ? Apr 12, 2013 21:57

Suran37: Feb 28, 2009

Torch Dexter posted:

Obviously the draw order isn't working quite as expected - in my experience with unity (using my own Sprite implementation, not 2D toolkit), in order to get sprites to always draw in the correct order you should be drawing sprites using a shader that has ZWrite turned on. This looks like the results you get when you try and draw close together sprites with a shader that has ZWrites turned off (as most of the standard unity shaders do). As your floor is solid - if you set that to work with a shader without transparency that might fix the issue as well - I've only ever seen it occur where two semitransparent objects overlap.

This draws transparency over the floor making it so the "blue space" of the background draws where the player should be transparent. Anyway I messed around with splitting up the atlases and using different render queues and that seems to have fixed it.

# ? Apr 12, 2013 22:02

SlightlyMadman: Jan 14, 2005

Bondematt posted:

You'll need to cache the script before you can call it.

so say you have a class called Wind on an object named WindObject.

if you just want the script, then in the script you want to be able to access from:
code:
public class Class {
   public GameObject windObject;

   Wind wind;

   void Start () {
      wind = windObject.getComponent<Wind>();
   }
}
Then you can access all public members and public variables from anywhere in that class. By just using wind.whatever

Edit: And you'll need to set windObject in the editor for this method, you can also use GameObject.Find to get it as well.

Edit2: You can also just set the script in the editor too:
code:
	public Wind wind;
Then you just drag whatever has the Wind script onto that, and Unity will handle getting the script.

Yeah, the link I posted above is very useful. There's apparently all sorts of different ways of doing it.

# ? Apr 12, 2013 22:05

Azazel: Jun 6, 2001; I bitch slap for a living - you want some?

SlightlyMadman posted:

Yeah, the link I posted above is very useful. There's apparently all sorts of different ways of doing it.

I typically attach all my non-object specific game scripts to the main camera instead of an empty, just because that camera is typically always in your scene by default anyways, and has a handy shortcut reference. I then do stuff like the following from any prefab objects that need to access the global scripts:

code:

using UnityEngine;

public class Whatever : MonoBehaviour {

  private MyGlobalScript myGlobalScript;

  void Start() {
    myGlobalScript = Camera.main.GetComponent<MyGlobalScript>(); // cache the script reference
  }

  // do whatever you need to in this object's methods, or Update, or whatever

  void Update() {
    myGlobalScript.DoSomething();
  }

}

Edit: Blah, just repeating things people have said or are that link. Ah well.

Azazel fucked around with this message at 14:59 on Apr 13, 2013

# ? Apr 13, 2013 14:44

Flownerous: Apr 16, 2012

If some of your scripts have order dependencies this is really useful: http://docs.unity3d.com/Documentation/Components/class-ScriptExecution.html

I usually only go manual update methods if it's for performance reasons or if I need one script to be updated in the middle of another.

# ? Apr 13, 2013 15:04

Orzo: Sep 3, 2004; IT! IT is confusing! Say your goddamn pronouns!

Shalinor posted:

Render #1 and #2 to an off-screen buffer. #1 is the base layer, write / no z / no alpha. #2 is blended over the top of that additively. Then take the composite buffer and render it over the regular scene buffer multiplicatively. Make sure that the composite buffer is double-buffered - which would lag your lighting a single frame, but keep you from trashing perf with a dependent render.

seiken posted:

You probably don't need Layer 2 either depending on what you're doing. Unless your light sprite is really complicated you can probably do this without needing to render to an intermediate 'light' texture. Just calculate the value directly in the shader and multiply. If your light sprite is really complicated such that you actually need multiple passes to render it then you can use an off-screen texture, I guess.

Jewel posted:

Oh yeah what the heck you don't need to render a black rectangle on top with alpha cutout, I'm being an idiot. Apply a postprocess shader to the render target with this and that's basically it.

Alright, I took a shot at implementing this last night. I definitely don't have too much experience with graphics programming beyond rendering quads and writing a very basic pixel shader, so this was definitely new stuff to me.

Anyway, I have it working. I ended up using a 'light' texture because it seemed like a cleaner implementation to me and it allows me to do goofy arbitrary shaped lights without worrying about writing the math in the shader.

I wanted to make sure what I was doing wasn't completely backwards, so can you folks take a look at my steps and make sure I'm not wasting time or doing anything silly? This is DX9.

1. In setup, create a Texture ('lightTexture') of the same size as my normal backbuffer, with the Usage.RenderTarget flag set.
2. Pass this texture reference into a shader, 'std.fx'
3. For each frame...
4. Set the device render target to the texture surface.
5. Clear the device to the ambient light color (this could also be done as a constant in the pixel shader, but whatever)
6. Device.BeginScene()
7. Render all light sprites using an shader 'lights.fx', which is a simple pass-through filter.
8. Device.EndScene()
9. Set the device render target to the original backbuffer
10. Clear device to whatever color
11. Device.BeginScene()
12. Render all non-light sprites using another shader, 'std.fx', which multiplies pixels by sampling the variable set in step #2 (lightTexture).
13. Device.EndScene() and Present().

Is there a simpler way to do this? (Not complaining, as this is actually pretty simple) It works perfectly, just wanted to check before making it un-hacky code. Additional question: Let's say I want a HUD layer that's on top of all of this and doesn't care about lights. Would I implement that with a third render target?

# ? Apr 13, 2013 16:46

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Orzo posted:

Is there a simpler way to do this? (Not complaining, as this is actually pretty simple) It works perfectly, just wanted to check before making it un-hacky code. Additional question: Let's say I want a HUD layer that's on top of all of this and doesn't care about lights. Would I implement that with a third render target?

For the additional question, I'd say "almost certainly not", unless you're thinking the HUD layer is mostly static so you'll just render it once and then use it as a texture from then on. If you mean to render it every frame, just clear the Z-buffer (or switch off z-buffering if you don't need it within the HUD) on your screen render target, and render the HUD elements straight to the screen after everything else.

# ? Apr 13, 2013 17:09

Orzo: Sep 3, 2004; IT! IT is confusing! Say your goddamn pronouns!

I don't use z-buffering, I draw layers in order. But the HUD layer would be drawn last, so yeah, what about just switching to another shader that ignores lighting and then rendering?

# ? Apr 13, 2013 17:20

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Orzo posted:

I don't use z-buffering, I draw layers in order. But the HUD layer would be drawn last, so yeah, what about just switching to another shader that ignores lighting and then rendering?

Yes, that. I should have been clearer, change all the parameters then render your HUD.

Definitely better than doing an extra off-screen render target. What would you gain from doing that? You'd still have to change all the parameters for that off-screen render, then you'd just end up rendering it again onto the main screen, now with a bonus big lump of VRAM in use for no reason.

(Again, unless your HUD is going to be mostly static and only re-render when something changes, in which case it might make some sense to be able to just render it in one call onto the screen. Though even then you'd still need to turn off all the fancy shaders and stuff.)

# ? Apr 13, 2013 17:47

Orzo: Sep 3, 2004; IT! IT is confusing! Say your goddamn pronouns!

Thanks.

One more quick question: I am noticing a fairly dramatic drop in performance if I have a lot of overlapping lights (which are in additive blend mode) rendered to the lights target texture. Before I spend too long getting into this, is there some kind of common error people make when doing this stuff? The problem definitely scales with the number of lights, and additionally with how much they overlap.

It seems like the number shouldn't matter really (beyond typical overhead of adding more sprites, which is very small, this starts dominating the graphics card at ~10 overlapping lights) since I'm still only doing two passes no matter what.

Edit: This might be a non-issue, turned on DirectX debug mode (I have to get into the habit of doing this more frequently) and I'm getting all sorts of warnings, gotta solve those first...

Orzo fucked around with this message at 01:26 on Apr 14, 2013

# ? Apr 14, 2013 00:40

seiken: Feb 7, 2005; hah ha ha

Yes, it definitely sounds like something is wrong. You're not really doing any extra work compared to one light, and rendering 10 alpha-blended sprites shouldn't kill your graphics card.

The fact that overlapping makes it worse is kind of weird, too. I can't think of an immediate explanation.

I don't know DirectX, but I know OpenGL has hint parameters when you create a texture to indicate how often you're going to modify the texture. If DirectX has something similar it could be you've told it "I'm never going to write to this" so it's stored it somewhere where writes are terribly inefficient.

# ? Apr 14, 2013 01:29

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

seiken posted:

I don't know DirectX, but I know OpenGL has hint parameters when you create a texture to indicate how often you're going to modify the texture. If DirectX has something similar it could be you've told it "I'm never going to write to this" so it's stored it somewhere where writes are terribly inefficient.

Slowness would also be caused if you're doing ANY render operation with that texture as a source between your light renders.

So, like:

Render Light A To Light Texture
Render Scene With Light Texture
Render Light B To Light Texture
Render Scene With Light Texture
Render Light C To Light Texture
Render Scene With Light Texture
Render Light D To Light Texture
Render Scene With Light Texture

Will be MASSIVELY slower than:

Render Light A To Light Texture
Render Light B To Light Texture
Render Light C To Light Texture
Render Light D To Light Texture
Render Scene With Light Texture
Render Scene With Light Texture
Render Scene With Light Texture
Render Scene With Light Texture

Even worse if you're doing something like:

Render Light A To Intermediate Light Texture
Render Intermediate Light Texture To Light Texture
Render Scene With Light Texture
Render Light B To Intermediate Light Texture
Render Intermediate Light Texture To Light Texture
Render Scene With Light Texture

Note that you don't even have to do a full "Render Scene With Light Texture". If you're, for instance. locking the Light Texture? God help you.

(my guess is that you're doing something like the above, and blowing cache... which will destroy perf super, super fast)

# ? Apr 14, 2013 02:08

Orzo: Sep 3, 2004; IT! IT is confusing! Say your goddamn pronouns!

Thanks for the help everyone. Pretty sure I sorted out my issues, I turned on more verbose warnings for DirectX and sorted them out, something about clearing the device's
cached textures before writing to the light texture again.

Here's a video of the results. Not the prettiest lights in the world yet, but I should be able to do some cool stuff with them once I'm making something besides a tech demo.

https://www.youtube.com/watch?v=BXgs22SCXXk&hd=1

# ? Apr 15, 2013 01:34

Yodzilla: Apr 29, 2005; Now who looks even dumber?

Beef Witch

Just out of curiosity, and I was only thinking this because I was playing Anodyne yesterday, what is the math behind jumping in a Zelda-esque game?

# ? Apr 15, 2013 01:38

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Yodzilla posted:

Just out of curiosity, and I was only thinking this because I was playing Anodyne yesterday, what is the math behind jumping in a Zelda-esque game?

If you mean the 2D ones where you can jump off of ledges, it determines your landing spot before you jump and I'm pretty sure any repositioning effects will either have no effect until you land, or the collision will be based on your landing position (so your new landing spot will always be valid).

If you mean Link's Awakening where you can free jump, free jumps don't change your map elevation, they just prevent you from falling into pits while in the air.

# ? Apr 15, 2013 02:08

Orzo: Sep 3, 2004; IT! IT is confusing! Say your goddamn pronouns!

Yodzilla posted:

Just out of curiosity, and I was only thinking this because I was playing Anodyne yesterday, what is the math behind jumping in a Zelda-esque game?

Right, I haven't done the 'jumping off ledges' thing yet like OneEightHundred said, although I'm going to get to that eventually.

The jump is implemented visually as a y-offset, nothing more. The 'Player' entity is decomposed into several child entities, for example the 'body' (which would also have accessories, etc--basically anything that jumps) and the shadow (which is not affected by jumping).

My engine has a sort of state-machine implementation for entities. The code relevant to jumping is this:

code:

... //Stuff in update for 'Standard' state
else if (Input.Pressed("B"))
{
    Entity.SetState("jumping");
}

...which will lead to:

code:

private void JumpingInit(InitArgs obj)
{
    _body.Control(
        new Sequence(
            new Range(ControllerMode.ZigZag, .6f, new FloatInterp(FloatProp.Z, 0, 30, CurveType.EaseIn)),
            new Execute(() => Entity.SetState("standard"))), "jump", ControlReplaceOption.Ignore);
    Entity.AddCollisionCategory("air");
}

So basically, move the 'z' propery from 0 to 30 and back down again over a span .6 seconds, and when it's done, set the state back to standard.

Collision is simple. If you check out this old post and the related video, you'll see how I can use collision categories to control behavior. I add a collision category 'air' when the jump begins (code for the Standard state removes it). Then, in enemy code, collision with the player is configured such that 'hoppable' enemies like the 'spike' can be set up like this:

code:

behavior.Collide(new CollideBehavior(Collide, new List<string> { "player" }, new List<string> {"air" }));

First parameter is the callback function, second is a list of collision categories to hit, and third is a list of collision categories to exclude. So, in English, the spike collides with anything tagged 'player', as long as that thing isn't also tagged 'air'.

# ? Apr 15, 2013 02:35

Yodzilla: Apr 29, 2005; Now who looks even dumber?

Beef Witch

Ha! Yeah that's about what I was thinking, I didn't know if it was any more complex than that. Thanks for the clarification.

# ? Apr 15, 2013 02:40

Rottbott: Jul 27, 2006; DMC

Orzo posted:

1. In setup, create a Texture ('lightTexture') of the same size as my normal backbuffer, with the Usage.RenderTarget flag set.
2. Pass this texture reference into a shader, 'std.fx'
3. For each frame...
4. Set the device render target to the texture surface.
5. Clear the device to the ambient light color (this could also be done as a constant in the pixel shader, but whatever)
6. Device.BeginScene()
7. Render all light sprites using an shader 'lights.fx', which is a simple pass-through filter.
8. Device.EndScene()
9. Set the device render target to the original backbuffer
10. Clear device to whatever color
11. Device.BeginScene()
12. Render all non-light sprites using another shader, 'std.fx', which multiplies pixels by sampling the variable set in step #2 (lightTexture).
13. Device.EndScene() and Present().

For future reference, you don't have to use EndScene/BeginScene between render targets. In fact the documentation suggests that it may cause a performance hit. Just use them once per frame.

# ? Apr 15, 2013 10:26

Orzo: Sep 3, 2004; IT! IT is confusing! Say your goddamn pronouns!

Rottbott posted:

For future reference, you don't have to use EndScene/BeginScene between render targets. In fact the documentation suggests that it may cause a performance hit. Just use them once per frame.

Excellent, thanks. You're right, I removed it and everything still worked.

# ? Apr 15, 2013 14:36

Yodzilla: Apr 29, 2005; Now who looks even dumber?

Beef Witch

For any of you interested the recently Kickstarted 2D skeletal animation tool Spine released their Unity and generic C# runtimes today. I'm not entirely sure how to use it and if it's possibly to integrate into Futile but I'm drat sure going to try.

# ? Apr 15, 2013 14:41

Paniolo: Oct 9, 2007; Heads will roll.

Hey QBasic guy - saw you featured on Gamasutra (saw QBasic in the headline and immediately knew what game it was.) Congrats on the exposure, game is looking great.

# ? Apr 15, 2013 19:57

Surprise T Rex: Apr 9, 2008; Dinosaur Gum

I dunno a whole lot about various languages really, is there a specific reason nobody writes games in QBasic? Is it just that it's a fairly old language that hasn't really kept up with the times or something?

# ? Apr 15, 2013 20:45

Zereth: Jul 9, 2003

The OP hasn't been updated since 2007, what would I want to go get to mess around and try to put together a game in?

# ? Apr 15, 2013 20:48

Orzo: Sep 3, 2004; IT! IT is confusing! Say your goddamn pronouns!

Zereth posted:

The OP hasn't been updated since 2007, what would I want to go get to mess around and try to put together a game in?

That's a pretty open ended question. Do you at least know what type of game you want to make and what platforms you want it to be available for? Desktop, console, mobile? What is your experience level with programming?

# ? Apr 15, 2013 21:30

Zereth: Jul 9, 2003

Oh hey yes that information would be necessary, wouldn't it.

Desktop, not much, and uh. Probably some sort of turn-based RPG type thing to start with but I'd like to branch out into other things later.

# ? Apr 15, 2013 21:39

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Surprise T Rex posted:

I dunno a whole lot about various languages really, is there a specific reason nobody writes games in QBasic? Is it just that it's a fairly old language that hasn't really kept up with the times or something?

QBasic's main limits are a very limited standard library and inability to load any sort of extension (i.e. it never got the ability to interface with DLLs), so it's REALLY hard to get it out of the MS-DOS time capsule. I knew someone who was really good at it and could do faster draws, interface with joysticks/mice, and play PCM sound by poking around memory addresses directly, but that only really works in DOS or a DOS emulation environment, a modern OS won't let you touch the hardware in user mode and forces you to do everything through the drivers, which of course QBasic can't load.

OneEightHundred fucked around with this message at 21:45 on Apr 15, 2013

# ? Apr 15, 2013 21:41

Suran37: Feb 28, 2009

Yodzilla posted:

For any of you interested the recently Kickstarted 2D skeletal animation tool Spine released their Unity and generic C# runtimes today. I'm not entirely sure how to use it and if it's possibly to integrate into Futile but I'm drat sure going to try.

The Kickstarter specifically says it will work with Futile and 2D Toolkit.

# ? Apr 15, 2013 22:07

Wolfsbane: Jul 29, 2009; What time is it, Eccles?

Zereth posted:

Oh hey yes that information would be necessary, wouldn't it.

Desktop, not much, and uh. Probably some sort of turn-based RPG type thing to start with but I'd like to branch out into other things later.

In 2D, I would go for Flixel or FlashPunk (Flash game dev libraries). Really easy language to pick up, and you can get something on screen quickly (which I find is very important for keeping motivation up if you don't really know what you're doing). In 3D, Unity is far easier than anything else you're likely to find. You can put a simple game together with very minimal programming, and go from there.

# ? Apr 15, 2013 23:08

Yodzilla: Apr 29, 2005; Now who looks even dumber?

Beef Witch

Suran37 posted:

The Kickstarter specifically says it will work with Futile and 2D Toolkit.

It'll worth with it but there will have to be work done on Futile's part which is more what I meant. From Futile's creator on the release:

quote:

Yes! This is definitely something I want to integrate. I'm not exactly sure how much work it'll take to turn that generic runtime into something Futile can use, but I don't think it'll be that bad.

If he's stoked then so am I. :v:

# ? Apr 15, 2013 23:15

Suran37: Feb 28, 2009

Yodzilla posted:

worth with it but there will have to be work done on Futile's part which is more what I meant. From Futile's creator on the release:

If he's stoked then so am I.

Oh I misunderstood you. I'm excited to try it out, but it crashes on launch for me at the moment.

# ? Apr 16, 2013 00:43

Adbot: ADBOT LOVES YOU

# ? May 12, 2024 05:12

Pseudo-God: Mar 13, 2006; I just love oranges!

I have always wanted to make a game, and I believe I am ready to start, but I don't know which technologies will make my life easier. I want to start with a Worms-like clone, with multiplayer. I am decent at C++, but I am willing to learn other languages in necessary. However, I would prefer a Linux release in addition to the PC. Can you guys point me to libraries, frameworks which would make my life easier? I would prefer not to start from scratch, as I will get delayed by at least a year.

# ? Apr 16, 2013 01:03

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »