Some tips for a beginner?

[shion561]

Hi! I was wondering if anyone would like to help me with the first steps of my 'little' proyect

I'm a complete beginner to both phaser and game developing. I'm studying multimedia engineering so I am indeed familiar with HTML5, CSS, JavaScript, among some more scripting languages, but I've never tried implementing something as big as a game before-

What I want to make is a virtual pet, (yeup. you read right), yet I intend to knock up the IA so the pet feels more natural, as well as some other features. It's basically an easily-expandable first proyect that I think will allow me to start with a very simple base and add layers of complexity as I get more experience. I chose to implement it using phaser and focus on a browser-game so It's easily accesible to the public and I can use the mobile phone for complementary actions in the long run- I still have no idea on how or what tools would be best to implement the user/pet database and gameServer.

All I have right now, it's a simple, general and conceptual web-responsive layout and the empty major game states (menu, the room, etc), so my web looks like this:

 

My major doubts are:
1. whether web-browser games usually work with this kind of layout or It'd be more beneficial to have the gamescreen (blue) covering the entirety of the viewport's size
2. Are the database and server coded first, or should I first focus on the different state's UI and work my way up to having the core mechanics roughfly implemented, then adding requests to the server?

3. I'd like to add some kind of system which allows me to read an external file, interpret it and place the game's dialog / calls for an event with the guide NPC / similar actions- something akin to what happens in some RPGs or in visual novels. I imagine this is done by designing my own 'dialog' structure in a JSON or XML file (which would be later on stored in my database for the client browser to download and cache) and parsing them? How it's this usually done?

 

My apologies if what I'm asking is very basic stuff, I really don't know where nor how should I start. I've followed several 'make your first game' tutorials on phaser's website, but they're nowhere near as complex as to help me understand the general workflow in a multi-state + actors + connectivity proyect.

[mattstyles]

7 hours ago, shion561 said:

My apologies if what I'm asking is very basic stuff, I really don't know where nor how should I start.

It is not, this is an incredibly ambitious project!

7 hours ago, shion561 said:

but they're nowhere near as complex as to help me understand the general workflow in a multi-state + actors + connectivity proyect

There's a reason for that! You should start much smaller, ignore connecting to a server altogether now and create a simple client only game, by all means add various game states and create a 'polished' game, but keep restricting your scope tighter and tighter (this is good practise for every project) so that you can focus on learning Phaser and some patterns that are useful in gaming. Having said all that, I'll try to comment on your questions:

7 hours ago, shion561 said:

1. whether web-browser games usually work with this kind of layout or It'd be more beneficial to have the gamescreen (blue) covering the entirety of the viewport's size

Either are acceptable.

In your diagram the edges are marked as banners, are they supposed to be UI elements for your games or advertising banners? If the former then yep, sticking UI left and right is fine, up to you and what your game needs. If the latter then don't worry about it, treat your game as the only entity on the page, whether that is full screen or inset into the screen doesn't matter (its dimensions matter, but its surroundings dont). Generally I'd say that if you want your game to be immersive make it full screen, of course, if you're selling your game to sponsors they'll want to plaster crummy advertising all over it, but you shouldn't want that as a developer, you just have to work with it if thats your chosen method of monetisation.

7 hours ago, shion561 said:

2. Are the database and server coded first, or should I first focus on the different state's UI and work my way up to having the core mechanics roughfly implemented, then adding requests to the server?

Coding DB and services first would be akin to a waterfall way of working. Nothing inherently wrong with that but that downside is that when you start on your UI you'll likely find you'd like things done differently, or data presented to you differently, meaning you could end up working on both sections simultaneously so why not start that way?

Both bits of work (service and client) need to get done, if you think about how they will communicate with each (the data structures you need, the interactions you need to handle etc) then it doesn't matter which is done first although I'd generally tend towards stubbing out the server bit first so that your client actually has some data to work with.

7 hours ago, shion561 said:

3. I'd like to add some kind of system which allows me to read an external file, interpret it and place the game's dialog / calls for an event with the guide NPC / similar actions- something akin to what happens in some RPGs or in visual novels. I imagine this is done by designing my own 'dialog' structure in a JSON or XML file (which would be later on stored in my database for the client browser to download and cache) and parsing them? How it's this usually done?

Chat-bots are all the rage at the moment, whilst some are (wrongly) heralding this as AI, its just the same simple tree branching decision space that you teach to 5 year olds, whether you store that in your code or load it in from a remote source at run time is up to you. The first approach (in code) is simpler and faster. The 2nd approach gives you more flexibility to change how they work without touching the client (although if you're caching stuff you'd need a cache-busting mechanism).

A dialog is simplest defined as a branching tree, complexities arising when a child node can reference back in to a parent node, which makes it a graph, likely with conditional edges. Storing trees as JSON/XML is easy but it would depend on the structure of each of your nodes, for example, say you have a conditional dialog option (maybe based on the Hunger level of your virtual pet), how would you represent that in a text (i.e. JSON/XML)?

The questions you ask aren't beginner questions at all, you should be worried about how to structure your code and focussing on best patterns. Why couldn't you change your game to be a client only game with a virtual pet? Target mobile only (makes design much easier) and you will probably want some persistence so use local storage for that. It sounds like you just want the backend services for persistence so there's very little shift here, but using local storage is so much easier, you'd just limit your game to one device per play but is that such a problem for you right now? (You mentioned something about using your phone as a control device? Thats awesome, leave it until your next game ).

Once you've created that game, if you finish (), then move on to worrying about a 'connected' experience.

[shion561]

Thank you very much for your time, dear!  I'm glad to see someone else sees how ambitious this protect really is, I'm sure most the teachers I've been asking questions to think it's just another virtual pet and that I've taken an easy route on my final project.

Let me go by bits:

2 hours ago, mattstyles said:

In your diagram the edges are marked as banners, are they supposed to be UI elements for your games or advertising banners? If the former then yep, sticking UI left and right is fine, up to you and what your game needs. If the latter then don't worry about it, treat your game as the only entity on the page, whether that is full screen or inset into the screen doesn't matter (its dimensions matter, but its surroundings dont). Generally I'd say that if you want your game to be immersive make it full screen, of course, if you're selling your game to sponsors they'll want to plaster crummy advertising all over it, but you shouldn't want that as a developer, you just have to work with it if thats your chosen method of monetisation.

Firstly: wow I hadn't even thought of the possibility of sticking the game's UI buttons on the banners! Right now I was thinking about the layout as a surrounding area in which to place ads and similar, more akin to what a frame is to a picture- I did try making the game take the whole space by using window.innerwidth and window.innerheight but then I starting having doubts about how to ensure the graphics look (and are placed in the room!) the same no matter with which device or PC you access the game, and thought it might be better to stick to an static window size for now.

2 hours ago, mattstyles said:

The questions you ask aren't beginner questions at all, you should be worried about how to structure your code and focussing on best patterns. Why couldn't you change your game to be a client only game with a virtual pet? Target mobile only (makes design much easier) and you will probably want some persistence so use local storage for that. It sounds like you just want the backend services for persistence so there's very little shift here, but using local storage is so much easier, you'd just limit your game to one device per play but is that such a problem for you right now? (You mentioned something about using your phone as a control device? Thats awesome, leave it until your next game ).

Once you've created that game, if you finish (), then move on to worrying about a 'connected' experience.

To be honest, structure and best practices are what I'm most interested in hearing advice for right now, but I asked those 3 questions first so I could adjust my layout, have a rough idea on where to start and see if the dialogue system falls into the 'advanced' section on my notes, I don't really want to start coding until I finish refining some details I have not quite fleshed out yet. Still, I'd really love to have some guidance on this topic for when I do start coding for real!

Considering what you told me, I imagine the best way I can tackle this protect is indeed make a 'pet 1.0' version that's only client-side and uses local storage (or browser cookies? I don't know if they'd be useful on this matter or just for current session) and work my way up from there.

And, well, if it weren't because this is indeed a final graduation proyect, I'd probably wouldn't have considered the DB and server for persistence, having the pet in only one device is totally fine by me, specially considering the (long long run) mobile features are complementary and I was not planning on implementing them just now. I could ask my teacher if ruling the database and server out and focusing solely on making the game interesting would still work out, but I imagine her answer will be negative.

Thank you a lot once again dear!

2 hours ago, mattstyles said:

 

[mattstyles]

13 hours ago, shion561 said:

and thought it might be better to stick to an static window size for now.

That sounds like a fine plan, certainly the simplest solution. If you want your project to run on desktop AND mobile though you'll probably have trouble picking a decent fixed size.

13 hours ago, shion561 said:

I imagine the best way I can tackle this protect is indeed make a 'pet 1.0' version that's only client-side and uses local storage (or browser cookies? I don't know if they'd be useful on this matter or just for current session) and work my way up from there.

Use local storage, it has a far better api than cookies and a much bigger storage space (local storage is ~5mb for all browsers, I think cookies are 4kb maybe, that might be per cookie though, not sure). I'd say start with client-side, get the hang on storing stuff in local storage and retrieving it later. Then work up to creating a simple server that has two routes, one to set data and one to retrieve (these will connect to your db so you store them on disk rather than memory, depending on your db and interface choice all that data will likely stay in memory so it'll be fast but it will be copied to disk so you have proper persistence too).

Working from local storage to using the server is conceptually the same, but there is one key difference: the local storage api is synchronous but using the server is async so you'll have to handle that in your code. If you're not clear how to handle async then it's tricky at first, hence I'd advise leaving that until your client-only version works, then work out how to add (technically this is bad advise because due to the whole sync/async thing it could mean some tricky changes, but I think in your case it will be best, getting stuck on async stuff and not producing anything for your final project is potentially disastrous).

13 hours ago, shion561 said:

I could ask my teacher if ruling the database and server out and focusing solely on making the game interesting would still work out, but I imagine her answer will be negative.

Yes, if this is a key part of the assessment then you'll have to start here (and ignore my earlier advice).

If you do early with the service integration then I'd say your main points are:

* work out how to identify a user

* grab data

* use that data to seed your game structures and continue to play the game

* when data changes fire-and-forget the state to the server to save it, ignoring failures

Grabbing data is a simple ajax (use fetch, all modern browsers support it and the api is better, I doubt you have to support old browsers) request, then create your game using that data. Sending data is a simple ajax put/post with the data, get your server to stuff it into the DB and forget about failures for now (unless part of the assessment is handling failure/error responses).

The potentially tricky bit is 'authenticating' a user, or, at least, associating a user with their data. I'd say the easiest flow would be:

* On client load look for a token in local storage

* - If found then use that token to get data

* - If not found then create a token on the client (a random ID is fine) and store in local storage for later retrieval

* - - Send that token with your request for data

* - - The server searches the DB for data related to the token you've sent, it always does this as it doesn't know if the token is new or not

* - - It will fail to find a token so should return default state, this could be an empty object

This flow does not create a new entry in the DB for a new token, that would come later when you try and save anything, you just pass the data to save and the token and the code stuffs that into the DB based on the token, either overwriting a previous entry or creating a new one.

There is a potential to overwrite someone elses data using this method but if your random ID creation method is strong enough (maybe use current time to help randomness) you're extremely unlikely to hit this case, even with millions and millions of users. You could create a new route to retrieve a new token generated by the server that could be guaranteed to be unique but it sounds like more trouble than its worth.

The above flow does NOT allow multiple device play as tokens are unique to clients and not shared. Your only option here is to implement some sort of authentication, i.e. a user would have to login to be able to associate themselves with the data you have stored, once they have done that once you can store it in local storage and proceed as normal, safe that the tokens you are now using across devices are the same and thus associated with the same data (of course, you could extend here to access and refresh tokens, but, again, sounds like more trouble than you need).