• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
fir

code flow (order) here

21 posts in this topic

Im tryin to alanyze this simple source 

 

https://github.com/tinkerlog/PongTime/blob/master/src/com/tinkerlog/android/pongtime/PongTime.java

 

https://github.com/tinkerlog/PongTime/blob/master/src/com/tinkerlog/android/pongtime/PongTimeView.java

 

there are just to files,

 

I would like to get know about code flow here - I mean the ordering in which will call the functions there (especially startup and then game loop) But though it is simple source i got a trouble to understand this code order flow

 

could someone maybe help wutht that and list the list of things and order in which tey would be presumably executed?

 

 - if so tnx

0

Share this post


Link to post
Share on other sites

Allright, tnx, I will answet to it toomorrow (need a bit of thinking)

but i could ask yet one thing i do not understand in meantime

 

in oncreate in activity there is a line (80)

 

pongView = (PongTimeView)findViewById(R.id.pongview);

 

 

                                                                                                                                                                     I do not understand this, pongView is an large object how you can just assign something to a large object - i would understand assigning something to a field of that but to a whole object - what is assigned here? does such assigning overvrite the left side, I mean previous state of an object - this line is strange to me; Can someone answer that?

 

 

(soory for font thuis changed after paste and i see no easy trick to change font tonormal - ok I changed that)

 
0

Share this post


Link to post
Share on other sites

as to code flow i will answer yet a bit later coz this is harder and more confusing, but here as to this assigning i can say what confuses me

 

PongTimeView is user defined large object has its own constructor and own user defined fields.. How it is possible to assign some thing taken from the resource into large user defined object - those two must be quite different type objects

 

also if you make such objects by such ssigning, what with constructor isnt it unused then at all? If it was used previously and setted some fields does the assigning of other object not overwrite it? (I would understand assigning something to a field of object - it can leave other user defined fields unchanged .. but assigning to whole object? Do it work also in such way? I mean it assigns only some base pointer and lefts other fields untached?)

 This is very strange

 

Also it is very hard to see for me where constructor is clled - is here this assign come before constructor and then constructor is called later or constructor is called previously this assignment later? Im much confuzed (abit angry, maybe as seen :c)

-1

Share this post


Link to post
Share on other sites

there is something like folder layout there and some file caled main.xml

 

https://github.com/tinkerlog/PongTime/blob/master/res/layout/main.xml

 

isnt it the layout thing?

 

Well this thing with hidden constructor was really strange imo.

Ps i treat it as a kind of logical puzzle/riddle, will try some of the tutorial but as a last resort, now i just want to try to understand it with to much external study (if possible)

0

Share this post


Link to post
Share on other sites

Oh, right, there was all the code. I only saw those 2 files on the first post and tought the rest was missing, and I was confused about the .layout extension. That's the layout file (main.xml), there's also the AndroidManifest.xml one in the root of the project that defines that PongTime activity is the activity that will be used when launching the app (action MAIN, category LAUNCHER).

 

 

 
ok, tnx for the info
in general this confusion with the hidden construction was maybe the bigger one, rest is maybe a bit less confusing
 
though
1) I do not udnerstand yet if this pongThread object nust be defined in the middle of the pongview? Wouldnt it be better to hold this in third file - when reading the source it brings the confusion.. are there some reasons to keep it in the middle ?
2) must be this surfaceHolder sent to both pongthread and pongview? if there is a call
 
     SurfaceHolder holder = getHolder();
 
does it mean that this getHolder is a global method or this is just a method of containing the view (probably the latter but there was also a littel confusion - if this is a method of the view why it is added to a view, this android oop java style of coding very weird)
0

Share this post


Link to post
Share on other sites

You can define classes anywhere you want to, and even if there are "good practices" it never is so simple as "this is the best solution in any project". At the end the only right answer that always work is "it depends", since what is better also depends on a lot of stuff. In this case PongThread is inteded to be used only inside PongTimeView, so for the writer the best place to put that code was inside PongTimeView.

 

About getHolder... That's not an Android weird thing, you can call methods without specifing the object in java. In this case, "getHolder" is a method of SurfaceView, a class from the Android API:http://developer.android.com/reference/android/view/SurfaceView.html#getHolder%28%29

 

Since PongTimeView extends SurfaceView, that line is calling the getHolder() method of the PongTimeView object that was inherited from SurfaceView. If you write a call to a function without specifying and object, the compiler always uses this rule:

1 - If "this" has a method that matches that call (considering also inherited methods), the line is interpreted as this.method(). If not...

2 - If the class has a static method that matches, the line is interpreted as Class.method().

 

If those checks fail the code doesn't compile. In Java you don't have global functions, you have static methods on classes, but to access a static method from another class you must import that class and write NameOfThatClass.method().

 

Alright the second was a little confusing as it looked as something like global method, but now i see

 

as to embeddong pong thread - will it be much difference if pongthread would be defined in third java file?

 

for me it seems that almost nothing will change, (though I am not sure) because visibility depends more on passed pointers not where definition lies

 

If it would lay in seperate file

 

1) acces from pong thread to pong view would be harder?

or

2) from pong view to pong thread would be harder?

 

would there be a need to revrite something?

 

as it shows the embedded pong thread is also accessible

just they use

 

import com.tinkerlog.android.pongtime.PongTimeView.PongThread;

 

 

I am not really sure what change if its embedded (if some acceses are easier or harder and which one

0

Share this post


Link to post
Share on other sites


I am not really sure what change if its embedded (if some acceses are easier or harder and which one

 

In this example, I think the difference would be minimal.

 

One advantage of inner classes is access to private fields of the containing class, so you could potentially write less lines of code.

 

I'm not a fan of huge inner classes like the one in the example though, makes the code harder to overview, that one maybe should have been a separate file IMO. 

If it only should be accessed within the view, it could be made private in the package, and you could only use it from within other classes in the same package. (though I don't think this is a huge issue?)

 

But for small classes that need access to private stuff of your class, and should not be used from outside, then inner classes are very useful.

 

As noted, its all convention and preference, nothing cut in stone.

2

Share this post


Link to post
Share on other sites

That's an Android game, so you must know a little about Android activities to fully understand it: http://developer.android.com/guide/components/activities.html#Lifecycle

 

When an Android application is started an Activity is created and started. Which activity is created is specified in the Android manifest (an XML file that's not present there, but should be present in any Android project), but only one of those is an activity so it's the only option for a starting point. I'm not saying that Android assumes that, the activity MUST be specified in the manifest.

 

Activities on Android have a lot of functions that you have to implement for different events. When the activity is created "onCreate" is called, so that's the first thing that will be executed. That function creates all the components that will be displayed.

 

Android has "layouts" to control the screens, those layouts are composed by components and one component is SurfaceView. When the layout is loaded in the onCreate method, a PongTimeVIew component is created and the method surfaceCreated from PongTimeView is called and the thread is started.

Alright took a little time and now i see it ..now its much more clear to me..

 

There is yet a confusion what surface is - What view is I probably

understand - view is some rectangle area (like 'sticker', somethink like "virtual paper" cards)  where you could present graphics (and also manage this views just like paper cards )

- but what is surface - is this just a surface (something like pixel contents) of the view ? is view to surface 1-1 relation, I mean each view has its own surface and thats all?

Is here in that app only one fullscreen view that has one fullscreen surface and that all is here?

 

Yet one strange thing - it seem to me that i noticed that in some conf files this app is setted to android 3 and above, regardless that it is easy (basic GDI like, as i could call it with my win32 experience) and probably should run in older androids too (at home I gos old HTC wildfire phone, and it has 2.4 or 2.6 android 

(i dont remember), does it seem 1) that it will not work when trying to download it from android market 2)if i will just change in confs expected android to 2.4 and compile it myself to device then it will work? Why the man putted 3 here?

0

Share this post


Link to post
Share on other sites


There is yet a confusion what surface is - What view is I probably
understand - view is some rectangle area (like 'sticker', somethink like "virtual paper" cards)  where you could present graphics (and also manage this views just like paper cards )
- but what is surface - is this just a surface (something like pixel contents) of the view ? is view to surface 1-1 relation, I mean each view has its own surface and thats all?
Is here in that app only one fullscreen view that has one fullscreen surface and that all is here?

 

Yes, you've got views right, they are higher level, used to layout content, and implement callbacks from buttons and such.

Surface is a handle to the buffer where the actual drawing takes place, and you draw to it using a canvas.

SurfaceView is a special view that help you do lowish level drawing onto the surface. (lower level would be direct pixel access).

 

Its not a strict 1:1 relationship, in a "standard" UI app you have a hierarchy of views defined in xml which layout pictures, text and buttons, and the framework makes sure to draw them into the surface for you, and you don't have to worry about the surface at all.

 


Yet one strange thing - it seem to me that i noticed that in some conf files this app is setted to android 3 and above

 

Probably not much thought behind it, you'd have to go through everything used to know for sure, but that example looks like it would run on a pretty low version indeed. You should be able to just change it. If you use eclipse, I think it will warn you if you try set the version too low.

2

Share this post


Link to post
Share on other sites

 


There is yet a confusion what surface is - What view is I probably
understand - view is some rectangle area (like 'sticker', somethink like "virtual paper" cards)  where you could present graphics (and also manage this views just like paper cards )
- but what is surface - is this just a surface (something like pixel contents) of the view ? is view to surface 1-1 relation, I mean each view has its own surface and thats all?
Is here in that app only one fullscreen view that has one fullscreen surface and that all is here?
 

 

Yes, you've got views right, they are higher level, used to layout content, and implement callbacks from buttons and such.

Surface is a handle to the buffer where the actual drawing takes place, and you draw to it using a canvas.

SurfaceView is a special view that help you do lowish level drawing onto the surface. (lower level would be direct pixel access).

 

Its not a strict 1:1 relationship, in a "standard" UI app you have a hierarchy of views defined in xml which layout pictures, text and buttons, and the framework makes sure to draw them into the surface for you, and you don't have to worry about the surface at all.

 

 

 

this more confuses than explains, is the surface 1:1 to a views or it is something more related to one physical screen device ?

I looked somewhat in android docs api but do not manage to understand it 

0

Share this post


Link to post
Share on other sites

You could say it's one step away from the screen.  Its a buffer that is managed by the screen compositor, which is responsible for composing any visible surfaces onto the screen.

You won't be allowed closer to the screen then that, as an app smile.png

 

Usually you have only one fullscreen surface in your activity, and then all your views in that activity (as defined in the xml-file, or created and added in code) are drawn onto the same surface.

But you could have multiple layes of surfaces. Content like video and non-fullscreen gl will be drawn to their own surfaces and composed by the screen compositor.

 

SurfaceView is special, it the only view that has its own surface, and is the one you use if you need to implement views that need their own surface... Most views don't.

 

Hope that clears it up a bit

Edited by Olof Hedman
0

Share this post


Link to post
Share on other sites

SurfaceView extends View. All SurfaceView's instances are also Views, but more classes extend View, so it's not a 1:1. Any of the next classes are also Views:

 

A View is a rectangular component that can display something and detects user input. SurfaceView extends a View, so it does the same things and more. It means a SurfaceView is also a rectangular component that can display something and detects user input, but it provides methods to manipulate what is being drawn.

 

Do you know about inheritance? It looks like you get lost in basic concepts every time. I'll keep recomending you to learn more concepts and more about Android before reading that code (or from any other finished game). You can learn all those stuff a lot quickier with tutorials and guides, it doesn't make sense you try to guess things. Code is not a puzzle or a riddle, it's not a mathematical problem or a logic problem that you can "decipher" or "solve", it's more like a recipe that the computer follows.

0

Share this post


Link to post
Share on other sites

SurfaceView extends View. All SurfaceView's instances are also Views, but more classes extend View, so it's not a 1:1. Any of the next classes are also Views:

 

A View is a rectangular component that can display something and detects user input. SurfaceView extends a View, so it does the same things and more. It means a SurfaceView is also a rectangular component that can display something and detects user input, but it provides methods to manipulate what is being drawn.

 

Do you know about inheritance? It looks like you get lost in basic concepts every time. I'll keep recomending you to learn more concepts and more about Android before reading that code (or from any other finished game). You can learn all those stuff a lot quickier with tutorials and guides, it doesn't make sense you try to guess things. Code is not a puzzle or a riddle, it's not a mathematical problem or a logic problem that you can "decipher" or "solve", it's more like a recipe that the computer follows.

I come from say about 5 years in procedural c world so some ground basic concepts of android and of oop may be (and are) not presn in my knowledge but at least O got some ground up in "general procedular programming" so i got confuzed but hopefully not so heavy as absolute baginners

(you know what im saying)

 

This "logical puzzle" approach works quite good - you know i focus on enumerating things i dont know and on memorizing, trying to understand .. its not so bad..This is more ZEN way (as it is based on contemplation, wink  ) but it somewhat works - now i understand much more with not losting, to much energy.. 

 

I will try to recapitulate the things to understand what is most unclear yet, but again need a little of time

Edited by fir
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0