Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 12 Sep 2000
Offline Last Active Oct 19 2016 03:13 PM

#4946797 My Long-term goal is to make a Pro Wrestling Game. What would that entail?

Posted by on 06 June 2012 - 10:31 AM

For any general wrestling move, the technique of authoring the entire move is going to be one of considering how to start the move (how to bring the characters together in order to do the move), how to do the move and how to end the move (which is really going to be how the characters separate OR how to transition to the next move).

Any of those stages is going to be a combination of authoring direct playback animations and then adding other blends, dynamic controllers (inverse kinematics and/or physics), meta data and potentially additional tween animations in order to fit that animation to the wider range of circumstances. Generally you just start with the simple direct playback and then add all the improvements in as necessary to cater for the required variety and to smooth things out. It’s not simple, but also not as hard as it sounds it’s more effort driven than anything and the success of it will largely be based on the variety of tools you have to help you meet the end goal. You see, all these controllers and other animations really are just tools to selectively apply in helping you to get the best result. Best to have many tools and use the best tool for the job then.

I should add that all that is going to be solved by the work of at least an animator AND a programmer (who is likely going to develop a very flexible animation engine but also supplement some of what the engine is doing with special case logic).

I don’t know names of specific moves, so I had to look powerbomb up. That move sounds like from a certain point the move could be a direct playback of two sequenced animations on both characters with some minor dynamic adjustment based on the sizing of the characters. Probably the biggest point of complexity in authoring that move is one of getting the characters to that point in the first place, which is largely a general problem for all moves as indicated above.

Assuming the move is actually possible given the location of the two wrestlers, it’s likely the AI will select a given animation (likely there is one or more that best suits that location) and then either use some level of AI to add additional blends and controllers to better fit that animation or sequence to the situation. This can be logic that is hard coded, which takes a lot of work but generally it’s best if the logic is driven by metadata that comes along with the animation – hints to the logic about what it should be doing if you like.

I should add that the most basic level (and fallback) of intro to move sequence is going to be walking to a specific position. That will work, but it will look crap. So again generally you start with basic intro moves and then add more specific ones in to make them look better.

When that animation is complete, the two players would in theory be in place and can playback a more synchronized animation specific to the technique. If your wrestlers are all the same size then there’s likely little else to do as you won’t have to cater for differing sized players, but if not you may have some blending and controls to take into account. You may also want to do that anyway just to add variation so if you replay the move over and over again it doesn’t look the same.

After the move is complete you’ll process animations to either separate the characters or start animations that blend or tween the wrestlers to link up with the next intro phase of the follow up move.

One thing to take into account is that depending on how you are implementing this, there may be parts of that animation that are driven solely by animation, inverse kinematics and other meta data…or there could be a physics controller to take into account too. It’s not uncommon for an animation to be largely driven by the animation data at various points in the entire cycle, but at other times acknowledge physics processing and take that as an input and control. A simple example of this would be picking someone up and throwing them – which could be fully animated until the point the throwing character ‘let’s go’.

Hope that helps. It might give you a better idea of what authoring and processing animation for any specific move might be.

You both want to make better wrestling games it seems - nothing wrong with that it's very honorable and well intended I might add. One of the reasons you might not be satisfied with the games you are seeing is because this stuff is very hard to get right. It’s very difficult for a game based on needing to animate to cover all corner and edge cases without applying constraints that affect the gameplay and even with dynamic input blending to animation there’s a limit to how much influence that can have/how many corner cases it can eliminate.

To understand this more…probably a good thing to look at is older wrestling or combat games (even 2D ones because they show the constraints quite well). Many of those games relied on playback only – no blending or dynamic control whatsoever. Hence why in many cases, you could only perform certain moves if you were in a specific position and you couldn’t always follow up one move with any other move. Combos or follow ups were quite often restricted to moves that were either authored specifically for or were just simply compatible with the current ‘state’.

That was just the state of the art at the time, but it also explains why those games had flaws that today wouldn’t be acceptable. Some of those games weren’t bad with those flaws or constraints of course and there’s probably some inspiration or a lesson to be drawn from that too.

#4946617 Help about design a Render Class

Posted by on 05 June 2012 - 07:26 PM

There is not necessarily any encapsulation problem. You don't have to switch to this for example:

int main()
	GenericGeometryClass object;
		  //Pseudo of drawing object
	 return 0;

I actually didn't comment on where to put those calls, although really it's a very similar problem and solution.

Something that has a vertex buffer, an index buffer, possibly references to textures, shaders and so on is a Model of some sort. I would create a Model class therefore to at least hold the data.

From there on you can create a function which takes the model as input and makes those calls. If you wish, you could wrap this into a modelrenderer type of class.

There is another solution too. We have suggested you stay away from the old 'each object is responsible for drawing itself' architecture. This problem is largely because the net result is often a hierarchy of objects derived from one abstract base class with a function override in each of the children. This is largely what we are looking to get away from then, but personally I have no issue with there being a Draw() or Render() function in a Model class, providing it isn't virtual or otherwise designed to be overridden unless there is an absolute need.

This might appear like your Draw() function and there are similarities. But I think there's also a big difference between asking every instance and class type to draw itself and simply asking each Model. One is clean and has one render function in one place. The other has render functions in every single class of a hierarchy.

Wherever you do put that function bear in mind you don't need to do this...

if (obhect_type == Sprite)
	 Sprite* sprite = (Sprite*) this->object_data[i]
	 //Implentation is here setvertexbuffer, index ,etc....
else if (obhect_type == Text)

There is absolutely no need for a render or draw function to know what it is rendering. It really only needs to know that it has been asked to render a vertex buffer, index buffer with references to textures, shaders and so on. If you do wrap all that information into a Model class, then all it needs to know is that is has been asked to render a model...and you'll provide some function like GetVertexBuffer on the Model to get at the data.

Either way, just make the render function flexible enough to render a model that has one or more vertex buffers, potentially an index buffer, 0 or more texture references, a shader and so on. If you make it so that it doesn't have to work with a fixed number of these things it will render anything you throw at it.

#4946246 Help about design a Render Class

Posted by on 04 June 2012 - 04:29 PM

The whole ‘every object can draw itself’ type of thing can seem like a good thing to do I think because a lot of C++ tutorial and books show us that type of architecture in order to demonstrate a language feature. In that sense, it can seem familiar or warm and fuzzy if you like which makes us think it’s a good thing. But I would urge you to consider just how much responsibility you’re putting into the Draw function and how much of that is going to be common to each of your renderable types. Anything common is better off in a common place, outside of draw and anything specific may not be specific to drawing at that point.

Common functionality

All of the object types you have listed, shape, text and sprite are ultimately rendering triangles. That’s what is really drawing here, so I would try and refactor that functionality outside of the draw function and into a common place. Anything more specific to each type of object can remain specific, but bear in mind that whatever is left may not be specific to Draw(). Personally that’s a good thing in my opinion because it will help justify the need for a specific object type, or make such a thing obsolete. We’ll talk about that in a minute anyway.

Really, what I’m suggesting here is that you consider setting up lower level data structures to represent the triangle data and move that outside of renderable. As Goran says, I wouldn’t wrap that in classes I would just present that in plain old data structures. In many cases you aren’t going to be doing much other than rendering that data, so it’s entirely appropriate to have that in a structure, not a class and just pass it to rendering functions. This might also help you decide a little about your rendering architecture – what you describe as you real problem above.

In my case I simply have structures that represent points, line lists, line strips, triangles, triangle fans and triangle strips – what is really being drawn. I have a renderer or renderdevice type class which has two functions (amongst many others) that draw these primitives – one handles indexed primitives and one handles non-indexed primitives. I should add that I really only pass the type and size of primitive with this function call. This means I have other SetVertexBuffer, SetIndexBuffer calls that point my render object to the actual data.

This means I can do something like this

RenderDevice rd;
rd.SetVertexStream( 0, pVertexBuffer );			  // where first # is a vertex stream index
rd.SetVertexStream( 1, pNormals );
rd.SetIndexStream( pindexBuffer )
// also things like SetTexture( x, texture), SetShader( shaderprogram ), etc
rd.DrawIndexed( TRIANGLE_LIST, num_triangles );		 // where triangle list is an enum

Bear in mind there is some implied knowledge in that example that I’m always passing in two vertex streams. In reality, I also have a SetVertexFormat type of function and I can pass in any amount of vertex streams, some of which have vertex and normal data interleaved.

This maps quite well to a number of differing rendering architectures so it’s quite portable. Can you see however, that I don’t really need a Draw function at that point…I just need a function that pulls out model data from your renderable class. Something like this would work:

pModel = pRenderable->GetModel();
rd.SetVertexFormat ( 1, VERTEXNORMALINTERLEAVED );			 // one stream, stream data has both vertex normal interleaved
rd.SetVertexStream( 0, pModel->GetVertexBuffer );
// etc

Renderable/type specific functionality

After I’ve done all the above, what do I need Renderable and various derived types of Renderable for?

The only unique things I might have in the equivalent of your rendering classes at this point would be things very specific to that renderable. That helps to justify a concrete class for that object or not. For example:

sprite.SetXY( x, y );
text.SetXY( x, y );
shape.SetPosition( x, y, z );
text.SetText( “Hello World” );

The four functions collectively represent a function common to two of the objects (SetXY), a function common only to a 3D object (SetPosition) and a function specific to a text object. That would imply an architecture for your renderables as
  • Base class Renderable
  • class Text possibly deriving from Renderable, but possibly also Sprite.
  • A Renderable3D derived from Renderable.
  • A Sprite also derived from Renderable.

i.e kind of what you have now. Only I would further remove the text class and make this a special texture. Every sprite is going to have a texture or bitmap, so there is common functionality which means in this example a special type of text renderable isn’t justified. I’d probably also remove the sprite class and just have a Renderable2D, which with a SetTexture or SetBitmap function would suffice for both sprites and text.

The goal – try and avoid the whole ‘everything can draw itself’ thing and minimize your Renderable class hierarchy.

#4946202 My Long-term goal is to make a Pro Wrestling Game. What would that entail?

Posted by on 04 June 2012 - 01:45 PM

So in the long-term, a pre-existing engine is preferred?

There is no easy or conclusive black and white answer or preference. When people ask this in this forum usually they are starting from scratch now with nothing and the advice to not 'roll your own' is very good in that regard. In your case if you are to begin this several years down the line, you may have amassed quite a bit of knowledge to the point where that same advice might not be so good, or at least you might have the knowledge by that time to better determine the answer more personally.

To some extent you see, the answer is often personal - depending on where you are at and what you want to achieve.

In your case, I wouldn't worry too much about what is right for the long term. For right now, I would still focus on using a pre-existing engine. You don't need to be distracted by the 'so many other things' to learn, but also you may find an engine lets you focus on areas that are important to your goal, such as animation (explanation coming)...

Beyond that I haven't done much else, but would like to know what other things I could do to improve/prepare.

Wrestling games often have a very strong pipeline for animation. What I mean by pipeline is really everything from authoring the characters themselves in addition to how they move, to the playback and control of the same data in game. Wrestling characters are often modeled with quite complex rigs that define an incredible amount of metadata to the run-time and so the animations involved are very rarely just simple replays of what was authored, as they often can be in other games.

A simple example of this would be the definition of 'grip points' on one wrestler - basically positions the other wrestler is trying to grab. The wrestler doing the grabbing will more than likely be animating via several blended animations and supplemented with dynamic animation via inverse kinematics in order to do that - no simple 'replay' going on there.

So in answer to your question as to how best to prepare this is something I'd try to cover learning about such things, including animation (authoring and run time), animation blending and inverse kinematics at the very least. The latter is definitely not a beginners topic though do beware.

Incidentally, the ability of an engine to do this sort of thing will likely influence the choice of engine for a wrestling game. There are many engines with quite powerful authoring pipelines and run-time engines as far as animation is concerned. For Wrestling, I would wager however that even if you do use an off the shelf solution that for the complexity of wrestling you'll have to enhance both the authoring pipeline and the run-time.

One of the nice things about animation systems though is that they are mathematical, which in itself offers a standard. Often for an off the shelf solution - if it is not up to the task of animating to the level you need will often expose that standard math. It is common to find that animation is one of the easier areas of an engine to add to, enhance or even replace as a result. Not always true, but common enough.

#4944708 Compiling with NDK without stuffing C++ code in JNI folder?

Posted by on 30 May 2012 - 09:49 AM

Is there any way to do this?

Yes, you can.

From the root of your NDK directory look at the /docs/IMPORT-MODULE.html (<ndkroot>/docs/IMPORT-MODULE.html) documentation which describes this process in detail. The gist of it is to make sure your NDK_MODULE_PATH environment variable is set up so that it considers the new directories. Setup an Android.mk for these new modules and then insert a "$(call import-module,modulename)" at the end of your original Android.mk (the one for the project/jni directory).

Alternatively, you can also build your external source into libraries and use the method described in <ndkroot>/docs/PREBUILTS.html.

I do believe there are other ways too. All is covered in the NDK docs, but these are the only two I've tried and can speak to. Apologies because I was going to post a basic example. Only one of the other programmers has made it so that it is no longer so 'basic'.

Do read those documents over several times both before and as you set it up. It it is in theory quite straightforward, but getting it to work at all and then to work well is a little more difficult. I had to keep going back to the docs and every time that I did previously overlooked or seemingly unrelated information became more relevant.

Bear in mind all the documentation is linked from '<ndkroot>\documentation.html'. Because this can be a little cumbersome, I would suggest reading over many of the documentation pages linked from here, in addition to the two I've pointed out above. There are many clarifying nuggets buried in a lot of these other pages, including the one that covers setting up the Android.mk (<ndkroot>/docs/ANDROID-MK.html).

#4942633 Broken Game as an Anti-Piracy Measure

Posted by on 23 May 2012 - 11:20 AM

I'm curious about these example you mention. Can you name any such DRM success stories?

Two of the Football Manager games contained quite friendly approaches one year after the other and this was generally thought to have been done quite well. Even if you google you can probably find (as I did when I was following it) positive reactions, debates where even naysayers are defending it and even comments along the lines of 'I hope they do it this way for next years release'. People actually asking for DRM was quite unprecedented.

Alpha Protocol from the same company did an even friendlier implementation of the same, however by that time the solution (and I can't remember the name of it) had been cracked. Alpha Protocol was therefore cracked quite quickly and the nice DRM was really overlooked, which is a shame really because it could have set quite an example for the industry. However the original Football Manager that used this didn't have a crack for several months. There were 'cracks' out there...but they didn't work that well and you can imagine how much interest that result generated.

Either way, these are examples where the limits of the DRM were quite reasonable and nobody was 'punished' as people like to say. The solution was based on 'online' but there was also a workaround for those who didn't have an internet connection. Sega even removed the DRM when it was deemed to have done it's job, which is a really good attitude to take considering online DRM because it means the games can be played 10 years down the line.

Good DRM is possible but it really requires taking the legitimate customers needs into account in full and it requires effort and a good attitude from those enforcing the DRM. Most DRM has just overlooked this, hence why it's just a bad word nowadays.

#4942369 Handling Collisions Between Rectangles

Posted by on 22 May 2012 - 04:52 PM

Also...I've tried to give you a more or less complete solution there, but keeping it as simple as possible in explaining it. Those two goals sort of work against each other, so feel free to ask for clarification.

Also bear in mind many platformer collisions just don't use anything accurate (or don't need to). I once did a platformer almost exclusively using one point on the character for collision - generally between his feet but when moving...the front of the feet. I would support this with a point at the top of the head when jumping and if I knew I was walking against a wall, then I'd reach out beyond the feet...at least to a point representing the extremity of the character (but still out from the feet/along the floor).

#4942367 Handling Collisions Between Rectangles

Posted by on 22 May 2012 - 04:38 PM

Using a circle vs a box, yes if that is programmed correctly it should result in a player sliding off the edge of a box. There are games where this is a very desired effect though.

Unless there is some absolute need to use four bounding boxes for your player, I would reduce this to one and solve the idea you need to know which side is being hit by another method. It will at least be easier to debug with one box and get all your box collision working very robustly that way first. You can scale up to 4 if you really need that when all is good.

I’ve done pure box collision like this and I’ve done it both badly and very accurately with predictive as well as moving/overlap then rewind methods…and a mixture of them all.

My preferred simple method checks for overlap first (after the box has moved) between my Box A and other box Box B. If there is no overlap, then there is no collision…nothing more to do.

If there is overlap though, I know I should be spending the extra time doing more detailed calculations. As such, I move Box A back to where it was and cast lines out from the corners in the direction of movement, sized by the amount of movement in order to see which one hits which side if Box B first.

I don’t do unnecessary calculations, so if I am moving down and right I only cast lines out (in the direction of movement) from the top-right, bottom-right, and bottom-left corners of the box A and I only test against the top and left sides of Box B.

I would also focus on the bottom-right corner first because in theory, if that corner hits first then the others I don’t need to worry about because that was the ‘leading corner’. Testing the line from the bottom right corner of box A against the top and left sides of B tells me which side of Box B I hit (if any) and should slide along.

Again, note that I don’t test against the right and bottom sides of Box B in the moving down and right scenario. They are on the other side of the box so I can’t possibly hit them without hitting the near side first. I don’t cast lines from the top left corner of Box A for the same reason.

If the leading corner did not hit the top or left side of box B, I then check to see if the other two corners that might have. This would occur if bottom right leading corner of Box A might have gone below the left side of Box B (missing the side) or past the right side of the top of Box B (again, missing that top side). It’s entirely possible for the non-leading corners to be the point of first contact so this is why you do this.

Note that using lines is effectively a ‘sweeping’ technique…you won’t miss collisions by moving past them if you only use lines, because you’re checking along the line of movement and will hit anything in the way. If you use the box overlap first as I suggested above, you may still get that problem though, which will arise if Box A moves past Box B entirely – there’ll be no overlap, so you’ll not bother doing the sweep.

In that case you could sweep a box over the entire region of movement…or just use a box that encompasses the start point of the box and the end point. I’ve also just used a bigger box for the overlap detection too and all that does is make sure I undertake the sweeping line tests when there might have been a collision.

You may find that you collide with multiple objects in all these scenarios, particularly those that involve some sweeping…so you have to find which is the nearest. A lazy way of doing this is of course to just test against them all and always keep the results of whatever the current nearest candidate is as you iterate through all possibilities.

The other thing to watch out for…boxes of different sizes. A large box can pass over a box of a smaller size without any corner intersections. This may show up as a potential collision when sweeping a box…but your more detailed line intersection tests may still fail. There are a number of solutions to this…an easy one involves doing line casting checks not from the corners, but from part way along the sides.

What you will see from above is that good collision detection usually involves a number of techniques mixed and matched.

#4941247 point me to the next step please~

Posted by on 18 May 2012 - 12:55 PM

To prevent a character from walking through a wall you will want to develop collision detection and response functionality. It's doesn't have to be 'physics' as such - it can just be a case of mathematics to detect the collision and then to calculate the correct position the character should be in had the character not walked through the wall. A modern game will do much more than this, including adding more physics calculations in but this is how games generally were once upon a time and it's best to start out simple.

The simplest form would be to consider a point where the characters feet are and how (when the character moves) the two places this point moves between form a line. From there, line vs polygon intersection tests will detect the collision and help you figure out how to correct. This is very basic...you'll partially clip through walls, floors and there’ll be a whole load of other problems but it’s simple and outlines simple principles that a more advanced solution solves on a larger scale.

A more elaborate implementation would be something like http://www.paulnettl..._Ellipsoids.pdf which would take you to a more advanced level without things getting too complex. Again, this would be somewhat representative of a common technique used in games and and I once put this exact thing into a PS2 game.

But I don’t bring this up for the purposes of a history lesson, its more the case that I think this paper describes a number of concepts and considerations that you might be interested in. Certainly if you read that paper you’ll begin to get a greater understanding of the many things involved with moving a character around and you'll begin to appreciate many small concepts that are still relevant in even more advanced solutions.

As for that more advanced solution…most people do solve this via general purpose physics engines nowadays. You can author your own but libraries like bullet physics might also interest you if you don’t want to do that.

#4940941 What I should know / learn to pursue a career in Programming?

Posted by on 17 May 2012 - 08:54 AM

GKANG you mention you are interested in programming. Forgive me if I missed it, but I don't notice you mention game development so I am assuming that at the very least you're considering regular non-game programming.

Have you thought of taking advantage of your music background with regard to game development? I say this because you obviously have at least had a passion for that in the past and you may not have to throw it all away.

You don't have to combine this with programming either, although if you do a very technical musician who can also program is nowadays a much rarer find in game audio departments and one quite a lot of people would value.

Just a thought.

#4940545 C++ - do you use STL in your game?

Posted by on 15 May 2012 - 04:59 PM

Which is better...that part of Standard C++ formerly known as STL or your own?

This is a common query and I doubt anyone has the definitive answer because what was once known as STL covers quite a wide range of concepts. Likely any one individual has only a very limited use for and knowledge of a subset of it, even if that's a large subset. I don't think it's possible for anyone to really be an expert across the entire STL because I doubt any single person has used every single feature.

It's important to understand this...because people should expect quite a varying range of opinions and you need to consider the subset of functionality that is relevant to your own work. For game development, we’re really only talking about a few specific types of containers that are relevant to run time. Tools are fair game for a much wider range of needs.

Once upon a time, at least to settle this query for my own purposes I considered the subset that I would use normally, discarding concepts I would never use and features I would never really be interested in during my life as a game developer. I looked deeply into the implementations I was interested in and tried to see if I could improve on them performance wise.

What I found was that most implementations were quite well developed and were quite efficient - at least as much as they could be. There was very little room for direct optimization, which wasn’t even worth the effort. For the optimizations that were possible...typically they'd be related to the deployment/use and as such would also be necessary if you were to take the ‘rolling your own’ containers option anyway or the optimizations were possible only by removing features to allow corner cutting.

The latter were more interesting to me because clear performance (and memory) wins were easy and possible via this route. This should surprise no one though…because the outcome of removing features is a more specialized case and as we all know, specialized cases will generally be more performant than generic ones. I actually don’t find too much fault with STL for being generic and flexible either – that’s kind of the point of it. I should also add that programming IMHO is often about making trade off decisions and sometimes generic/flexible is just a better choice anyway.

Unfortunately, this result did give me the excuse I needed to continue using and maintaining my own containers because I don’t need to give clock cycles away anyway. However, before the haters applaud I will also add that while such exercises do provide measurable gains at the instruction level please bear in mind that the % of time your program counter is iterating over such instructions is very minimal. The gains you’ll see to your frame rate by such techniques are often not going to be as noticeable.

I should also add that while I do use my own containers, that wasn’t an excuse for me to throw STL containers away. I still use them actually, particularly in code that I share with others or in code that needs to be more flexible.

A TL/DR version, which is also roughly the takeaway from my own research
  • In rolling your own it’s easy to make performance gains, but you’re not really optimizing STL – you’re removing features and making something else. Apples and oranges don’t really compare.
  • I did make some memory gains too, as I briefly hint at above.
  • The more features you add, the more the gap will close on any gains you made - the more pointless having your own will be.
  • If you can live without those features the performance gains are worth it at the instruction level.
  • The same performance gains have limited worth overall, largely due the time your program counter is in these so called problem areas. Or…there should be bigger fish to fry when you look at your performance profile.
  • It is possibly worth using your own to gain maximum performance for your run time regardless (as I say above…why thrown cycles away).
  • Rolling your own is an interesting exercise, particularly if you do look at the existing implementations. You’ll learn a lot about them and I think make wiser decisions for having that knowledge.
  • Rolling your own with the intention of supporting all the same features is pointless. Things will exist in your version for the same reason they exist in vendor versions, which have already been optimized as they are. You really will be reinventing the wheel here and you’ll do that via creating a less optimal wheel at least in the first instance.
  • Where you don’t need performance, the only possible need to use your own might be for reasons of consistency and not using two different types of containers.
  • It’s my opinion that your tools/pipeline and generally your higher level code are better off using STL/standard C++ library containers though. Why?…
  • They are more flexible and this sort of code generally needs to have that benefit
  • The same code will be more maintainable due to using something more flexible
  • Because they are standard and everyone should know them. Not everyone will be aware of the nuances of your own version, even if it’s a version shared amongst several people.
  • The advantage of the alternative has no place here.
YMMV of course.

#4940485 Gaming Platform question for iOS (and possibly Android) Game

Posted by on 15 May 2012 - 12:48 PM

So suggest me only other alternatives.

Here are a bunch of options. I’ve excluded Unity from this list due to what you’ve said about that and I don’t think I’ve repeated others you’ve already mentioned:Some of these are API level SDK’s/frameworks and some are more the IDE type you’re looking for.

I know you’re looking for more of the IDE type with more drag and drop solutions, but you might find something even slightly lower level offers a better support structure for you. Development is all about trading one problem for another thus some of the options above may not be exactly what you are looking for but you might find the community and 3rd party tools available make up for whatever is lacking. Some of these options do have tools or simulator solutions that might help alleviate your need for hardware, at least for the short term.

I don’t think cocos2d is for you but I’ve listed it because I think you might benefit from reading about various options to understand the entire range. Knowing the extremes will help you to zone in on the correct solution.

My question about costing is also derived from the same - given that when I chose an IDE that does produce an iOS code for me, how much will it charge me for the licensing?

Best to look up licensing fees for SDK’s from the websites as they are all different. Bear in mind some are free, some are typically free in specific circumstances and some have varying licensing costs depending on your success. Beyond the cost of the Apple SDK, you won’t have to pay a licensing fee to Apple or Google, they will however take a cut from any revenue your app generates.

But somehow I feel that developing for Android initially will not give me the 'required' boost to be a fulltime game developer, that's why I have chosen iOS path first.

You really should either get that Mac then, or try and set up a hackintosh as Frob suggested.

If either of those aren’t for you then it is likely Android for you.

There is also another option of just developing on Windows/for Windows (to prototype and further the idea) and porting to iOS later when you think you’ve made a hit game and are more prepared to spend the cash on a Mac.

At the same time I do not want it to fall big time, I need some returns for sure.
In any case, tell me if you differ on this - but I don't really smell success here.

It’s not unreasonable to want returns, but I’d be cautious with expectations. Many people get $0 back for their mobile games. It’s only ‘risky’ and you will only ‘lose your shirt’ if you’re throwing a lot of money at it, but you’ll need to be prepared to lose at least your time either way. Spend only as much as you’re willing to lose, in terms of both time and money because there is no guarantee but also bear in mind that success if often brought about by persistence. Many people put an app out there, have no return quickly and give up there and then. This will generally fail but persistence on the other hand does still not provide any assurance of success and will at least require more time (if not more money) well beyond an initial release.

Really, the best reason to do this is not success or money, but fun. If you need more than that I would at least think twice before parting with any cash.

#4940470 Gaming Platform question for iOS (and possibly Android) Game

Posted by on 15 May 2012 - 11:33 AM

a) What is the best IDE to go for, which will require me to do minimal coding, and the app will be ready with just some drag-drops and event handlers?

To be completely honest, you'd likely have to say a little more about the app you wish to make in order for anyone to give you an idea about whether any particular game development suite or ide is going to be suited towards towards creating that game. There are quite a few options, some of which won’t meet your needs and some of which might be overkill.

Just as an example...gamesalad is aimed at doing minimal coding via drag and drop game creation and thus given what you’ve said it might fit your needs. But without a little more info on your app I couldn't tell you whether it was appropriate or not.

IMHO…you'll be best off just furthering your trials of the various options to the extent where you actually try to put at least a part of your game together. This will tell you much more about what the best solution is for your needs than any subjective answer on a forum.

b) Will this IDE allow me to create
- iPhone app on my windows box - if not, how much is the minimum cost to get it done?
- android app on my windows box

I think there is one solution that does allow you to create an iOS app on your windows box. Unfortunately I can’t remember the name of it and even a google hasn’t helped. I wouldn’t actually recommend it anyway because every time people have discussed it on another forum I subscribe to - the feedback has been generally quite negative and this has been from professional game developers who I trust.

So…if you wish to develop on windows you’ll likely be targeting Android first and then porting it to iOS at a later date, or developing for both targets side-by-side. You’ll naturally want to have a solution that supports both platforms well then.

Again, I’ll be up front with you. If you really want to target iOS you should just get a Mac and an iOS device. Why?
Well, first…if you want to create a game for both platforms it’s best to trial the platform specific support for each solution. However, in your case because you do seem to want to stick to Windows based development I really would suggest you evaluate the full workflow of developing on Windows for Android and then switching across to Mac/iOS. Bear in mind you may wish to evaluate switching targets regularly as you might in a scenario where you develop for both platforms side-by-side and/or you may want to consider evaluating for the workflow of developing the game in its entirety on one platform, then porting to the other.

If you really do want to avoid getting a Mac now and cannot evaluate this 'feature', I would personally just stick with a known entity like Unity for now. This might be overkill for your app though.

Incidentally, there is absolutely nothing wrong with doing everything for Android in a Windows environment. But bear in mind that even if you don’t evaluate the multi-platform support now you’ll still need a Mac and iOS setup eventually regardless.

c) What is the total cost involved including hardware, licensing and publishing?
- considering iPhone as the only target
- considering iPhone + Android both

4GB Mac-mini (So mac-mini @ $599 + 2GB of extra RAM OR Mac-mini @ $799 which already has the RAM)
SDK licensing @ $99.
Minimum iOS hardware (8GB iPod touch) @ $199.

Read: you can get in to iOS from scratch for about $1000

That is a minimum but also sufficient. I wouldn’t recommend going for the $599 mac-mini without getting the extra RAM - do not be tempted by this..yes it will work, but you need the extra RAM to get sufficient speed from the development environment for your workflow.

The iPod touch is also a minimum but also quite/more than sufficient unless you want to target specifically or optionally support a tablet or you’re using features that would only be in a phone (such as GPS).

To add Android to this I assume you already have a windows box given your comments about sticking to that OS as your development host. So your cost here is really going to be the cost of a tablet or phone (the SDK is free). A decent-ish tablet will run @ $399 although there are deals to be had here and there. A phone can be much less or the same (mine was $150 although I don’t use it for development as it’s Android 2.2 and not very powerful – I stick to the tablet devices instead). Bear in mind performance and features vary somewhat wildly and you'll likely at least want something supporting at least Android 2.3 at this stage.

If you are looking to develop cheaply on tablet you could also consider a Kindle Fire. Some people do use these for development, although they require a small modification to .ini files on your PC to work for that (takes about two minutes) and personally I don’t think they are the best for development. As such I would only recommend this for the lower end apps, but some people do indeed development more than lower end with this. Cost of Android SDK is free.

If you want to make it even cheaper, then you could try not buying any hardware and using the emulators/simulators. This would also reduce your iOS SDK cost too. You could try this, but I would generally advise that you’ll likely (depending on your game) meet the limits of these very quickly and end up needing the target hardware either way. You would obviously need an IDE or SDK that supports this if you took that route. Again, I would steer you away from this in general…I only mention it because it has some validity as a solution if you have a limited budget. If you are interested in this, I would at least suggest you consider it only an interim solution.

Some people might say you need a more powerful Mac. So…I’ll mention that incidentally, I am developing an fps game via porting a PC engine to both iOS and Android. I’m doing something that would generally be considered higher end and I am using the $599 mac-mini with extra memory and an iPad 2 for iOS and a Windows 7 PC with a Motorola Xoom and a Kindle Fire for Android. Prior to the company buying the tablet hardware I actually developed for iOS using my own iPod touch.

Bear in mind...all costs quoted here are based about getting a development environment set up. If you're doing all the work yourself, there will be no other development costs unless you have to pay for an IDE. If you need others to do some work, there will be additional costs to pay those people.

It also doesn't cost anything to put an app out there for sale but bear in mind that your app may need a cash spend to assist it have even some small success. Therefore publishing can include costs for marketing and promotion, which still don't offer any guarantee. What you spend on this (if anything) is really up to you though.

#4926456 (UK) College, A-Level's, Btecs, and it seems i've made a fatal mistak...

Posted by on 29 March 2012 - 03:29 PM

Writing games in your spare time such as Windows or Symbian is a good way to practice your skills, as well as something to talk about in your interviews. On the flip side, in my interviews they seemed more concerned about good academic qualifications than actually looking at any portfolio I'd made...

That's my worry.... Did they look long and hard at where you got educated first before even touching your portfolio?

Bear in mind they'll do that if you have no prior experience other than hobbyist. Hence why coming in from a sidestep route, or by a self-improver/foot in the door route such as QA can be a good one for design.

#4926453 (UK) College, A-Level's, Btecs, and it seems i've made a fatal mistak...

Posted by on 29 March 2012 - 03:26 PM

Semiz, if you don't mind me asking how old are you and where are you at with regard to choosing/starting/completing your degree? It sounds like you are still deciding what degree to take, but from your posts I’m not too sure.

Either way, bear in mind there is no defined degree for game design. There’s no defined degree for game programming or game art either, only more generally accepted routes. But there really is even no generally accepted route for design, so don’t be too worried about your past choices just yet.

Generally, most designers I know of took one the following routes:

Computer Science Degree -> Game Programming - > sidestep to Game Design
Art Degree –> Game Art -> sidestep to Game Design
Game Degree -> Game Design
Seemingly Random Degree -> Game Design
Seemingly Random Degree -> QA -> Game Design
Off the street -> QA -> Game Design

You can mix these up a bit. Most would have got into some sort of hobbyist game design at some point (such as modding for example) and would have had something to show for it. Make sure you do that.

The seemingly random degrees…I’ve known people who’ve taken English, History, Film and Media types of degrees, all of which might be held up to have had some relevance to the eventual career path. An English degree for example, where the person has plenty of talent for creative writing is entirely relevant and useful...if you can show it as such.

Without knowing your exact position, but knowing you don’t want to program or do art…have you considered going through the ‘foot in the door’ routes such as QA? There’s a lot of competition down those routes, but those who are good at QA, demonstrate a knack for game design and are keen gamers do generally make it through to either junior production or design jobs, even if it takes quite a few years.