Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Grimshaw

Member Since 03 Jan 2011
Offline Last Active Nov 19 2014 08:50 AM

#5123672 Know a game developer without a degree?

Posted by Grimshaw on 14 January 2014 - 03:09 PM

I am a game developer , I don't have a degree, but I am still starting (about to release my startup company first game). Don't know If I can be useful or not :)




#5118221 In the Deep - FREE ... FOREVER!

Posted by Grimshaw on 19 December 2013 - 02:39 PM

I want to be totally supportive to your cause, but the countless language mistakes in that card is stopping me.. Please don't show that to any more people before correcting it.. Just so many mistakes...

 

Other than that, good work, wish you the best luck :)




#5114878 This is why Modern Tomb Raider Games aren't good...

Posted by Grimshaw on 06 December 2013 - 09:55 AM

I really don't agree the old games were better than the new ones, especially the latest one. The difficulty argument is not really valid because kids will never have the same ability to beat a challenging game as an adult. I remember finding these games difficult when they came out, but now I don't share my old opinion. Design wise, I don't think the older games were that much harder than the current ones.

 

What made them difficult were the horrible controls. The older games had controls difficult enough that you would fail a single part a lot of times because you couldn't control your character properly.

 

Of course, in the latest games, you see the "paths to victory" easily in your head, they were designed specifically for that. Game design evolved over the years and one of the lessons learned was to NOT frustrate the player. Challenging is ok, being stuck is not ok. You see older games had game design flaws you don't see these days. And in today's reality, you can't really expect people to take those too-hard games seriously, when they're used to a different kind of difficulty. Tomb Raider developers are just following the society and industry standards, and doing a pretty good job at it.

 

I would appreciate if Tomb Raider developers tried to mix the best of both worlds but the expectation on that IP is pretty high these days, and they can't just make something most people will not want to play. The industry is having a hard time surviving even with these little design tricks to get a bigger player base. They need to think about all kinds of players, not just the ones that were there for the first Tomb Raiders and liked it insanely :D

 

You also might be biased by nostalgy when talking about Tomb Raider, since it marked most of our childhoods so much. I agree on the part of over-tutoring the player, but thats also the result of game design evolution, and its something we really can live with.. Who haven't ever ditched a game for bad controls / bad explanations? I did, a lot.




#5114439 Looking to Hire a Team

Posted by Grimshaw on 04 December 2013 - 07:08 PM

After all the great answers in this topic, from all these honorable people, I have nothing to add, except to give a humble piece of advice, on top of theirs:

 

You want to make a game that fulfills you, that makes justice to the game you dreamed of, and yet you know very little about game development. My advice here would be to use some of your budget to pay yourself for some time while you dive into this world. Learn to program a bit, learn about some programming techniques, so you are aware of what is doable these days, and how much manpower does it take to achieve them. Then play around with some engine editors, get to know the workflow of this kind of tool. Also, try writing some drafts of design documents for smaller, simpler games. Even if you don't become a guru in game development, you will have an idea of what is happening and how to control your own people.

 

It is very hard to lead a big project like the one you want, without knowing (potentially) a lot about game development first. You might end up being just the leader throwing in ideas that aren't doable or will delay or make the project not achievable within the time span. Once you feel confident about your knowledge, and you think you know what does it take to actually lead these programmers, artists and designers into working together to achieve your game, then by all means start it. Until then, I really recommend a self-development phase! 

 

If you skip this part, you will probably have to get someone to lead for you, and consequently you will have a smaller role in the process of making this game, influencing it less with your own ideas because of it. 




#5113490 Android NDK Development - Would like feedback

Posted by Grimshaw on 01 December 2013 - 09:18 AM

Yeah, I think you convinced me into not changing to native activity. I don't see a single advantage to it, from my current work state. For a newcomer to android development, perhaps, but I am too far into this race already to feel the need to touch this part of the program anymore.

 

I wrote a "standard" Java activity using GLSurfaceView and then replaced some parts of the Java Code with preprocessor tokens, for customizability. Then, I run my own sort of preprocessor on this Java source and template APK, and generate on the fly a fully ready APK for the new project.. The Java part already gives me access to sensors, vibration, assets and all, then callbacks the c++ for events / rendering and updates, which is really all the c++ part needs to run well. 

 

With this approach, I was able to integrate ad networks like AirPush in no time before. That said, I don't need to touch java in ages, and when I need, the work needed to be done is really not hard because its just a standard use of the standard API, like integration of Facebook or Ads.

 

In this situation, I don't think I would benefit at all from a native_activity. Not for performance and not even for usability. One downside I find myself having was to be able to call opengl commands only from the rendering thread, which blew my plans to load textures in a parallel thread for the loading screen.. I thought native_activity and custom egl context initiialization could go around this issue, but as far as my research went, and from friend's opinions, it can't be done in android..

 

So yeah, I think I will indeed publish my games as they are now. 

 

Keep up the good work with the tutorials ^^




#5113383 Android NDK Development - Would like feedback

Posted by Grimshaw on 30 November 2013 - 06:19 PM

The part II still only touches the surface of  the problem, but its again pretty well written and clear. 

 

As far as my research goes, using native_activity will give you a little more control on things like opengl contexts and frame rendering frequency, but on the other side cuts access to many useful things. In terms of performance, it should be about the same, since those are two regular java activities both running native code underneath.. I don't think there is a significant difference.

 

I know you can still use Native Activity with java stuff by inheriting the java class, but if you do that, whats the point anyway of using it.. If you don't do java at all, I think you can access many things from c++ but the JNI code will look horrible.

 

I will just publish this game I am working on as-is, with normal java activity callbacks and see how it goes. I am sure many people did this too before and had no major problems :D 




#5113302 Android NDK Development - Would like feedback

Posted by Grimshaw on 30 November 2013 - 12:36 PM

Well, its a start! It looked good but just when it was about to get juicy, the part 1 ended ! I was just looking for more :P

 

If you keep this series going, I would love to read more on how you can achieve using native_activity on the c++ side along with a NativeActivity or NativeActivity inherited class in the Java side, and still use Android SDK stuff to integrate ad networks easily.

 

My approach is currently having the old glue code in regular Java activity and communicating with a c++ engine. I use a GLSurfaceView with it, and it all works fine, but I hear that native activities have lots of advantages over regular glue code. Can you elaborate on that? What's the pros and cons of each approach? In my case, I am interested in very little Java API's. I only use the basics and then its all made in c++. Only In-App billing, ad networks and very few other things will be useful to me.

 

Thanks!




#5098353 Football Manager - Where do i Start.

Posted by Grimshaw on 02 October 2013 - 03:09 PM

Python should be an okay choice.. An heavily UI based like that might be hard to pull of tho...especially if you are alone and know nothing yet..




#5088460 Which Gaming Engine/Level Editor Should I Go With?

Posted by Grimshaw on 23 August 2013 - 01:18 PM

Try them all :D




#5051576 Printf acting weird

Posted by Grimshaw on 09 April 2013 - 01:48 PM

Please allocate retVal before using it!

 

= malloc(sizeof(cbuf));

 

You re accessing a random memory position, which is undefined behavior. The printf not working is simply one of the many possible effects, thats why it is called undefined! :)




PARTNERS